Unpacking Taiko's Based Boosted Rollup Architecture

Transcript

welcome back to the rollup High Roller Community as always nothing on the rollup is to be ConEd as Financial advice we are just an Educators in the defi space toss us a quick like give us a share a repost send it to a friend who may want to watch this and finally give us a sub or a follow it means the world to help support credibly neutral educational content in def5 we're here to educate Empower and enrich you and let's jump in [Music]

o [Music] [Applause] [Music] let's talk some more boist rollups again yes welcome Brett welcome to the rollup I guess where did you find this picture Brett oh so like when I made like my tur threat uh like like two months ago or something I I created like a couple of like these logos using Ai and uh I I yeah I mean some I think AI

should generate some some good ones uh but yeah on Twitter I use like the the most dumb one and this is still like a pretty dumb one but it's also like nice nice and dumb one uh so I just use this for the presentation I still have a couple of more like uh you can expect more of these logos to to pop up in in the future hopefully more memes from the tier team big memes I have a bag lock so be prepared let's on the uh yes congrats on the test it uh for Tao looks great I know a lot of people were excited about that um and yeah man yeah yeah thanks uh they at least like two two days of up

time now and hopefully it stays working as expected and yeah y also the we don't fight any like big troubles or something uh so this is kind of like the final release except for like some some small modifications for like the main at that uh but yeah exciting time but also exciting booster rollups uh which is what we be working on uh the next couple of months uh well I guess like let to see like how long it will take but let's say this is kind of like expected maybe yeah one year-ish uh year out or something before uh we get like everything up and running to kind of like switch to this design uh I'm also like optimistic a lot of the times so we have to see like when it will actually

drop it uh I think that's kind like a good time frame uh for us to to work against uh but yeah so which rups what's kind of like what's the problem that we're trying to solve like what's kind of like the design like how do we solve it what's kind of like the pros and the cons uh I'm going give some some more uh details of like how we will actually uh try to try to do this okay why why we think this kind like good solution um and like What problems will it solve what problems that doesn't solve um so yeah so so the ethereum road map is kind of like okay we have like the L1 on etherum like ethereum is L one and then we have like the rollups that kind like plug into the eum um and uh and then way

we can actually scale and that's kind like a good system because but now it's having like some some kind of like let's use the the the fancy word and shrin anything uh there's actually like different like rollups that can experiment and kep like try different things out try to like scale things in like the best way possible so it's kind of like a very nice road map where like people basically L2 teams can do whatever they want uh and they can like experiment with stuff and then see like how it goes uh and then we'll see like what ends up winning uh but instead of like ethereum team itself like saying like this is kind of like the way to do L uh it's like a very open design space uh so that's that's cool to see but yeah what what's kind like the the but not

the downside but like one result is that yeah there are like multiple l2s now and each L2 also has like a limited like throughput or like capacity to actually uh process transactions and like stuff um so then you have like the L1 then multiple l2s and then each L2 has like some applications available maybe you have like your smart wallet on like one L2 but there's like an application that you want to use on the other L2 uh and then you have to do like slow bridging or your bridging depends on like liquidity Bridges um to to get there which like will be more costly than just being will to needed be brid and there's also like yeah um like there will be some delays in most cases uh so that's kind of like yeah how do we solve this like fragmentation problem although it's

kind of like yeah fragmentation a loaded term uh but it is kind of like fragmented in like different silos that kind like Alber like um on their own without directly working together um so yeah and the other thing is also like with the l2s they have like their own like sequences pipeline so that's Al like what I could tries to do like we like a base roll up so we use the L1 validators to to basically like sequence the blocks um or at least like decide what blocks get into the ethereum chain uh and so that's where also like a lot of like benefit is because if you want to do like transactions on multiple rollups then yeah being a to go through like the base system there is actually

somebody that can build blocks for both l2s at the same time so so they can actually include your transaction for both outs um so that's kind of like the setup so we have to scale eum as good as possible l2s also have like scalability um ball necks so how how do we kind of like uh work around that to still have like something that users can interact with uh as as if it's kind of like a single chain or at least that's kind of like the and because yeah from like a user uh perspective that would be like the ideal case um so yeah so how does bridging normally work and also like on our current typ uh is a yeah basically you write something on one L2 uh and

then on the r L2 you wait on like the other the The Source L2 to kind of like uh finalize and also like be fully verified and then when the ll2 knows the block hash of your Source uh of your Source robot then you can use like Yeah The Block hash contains like the state Ro and you can actually go through that block hash to to be able to see like okay yeah this thing actually happened on the source chain so for example I Pro that I burned like one eth on there then on the destination chain I could say like yeah this guy like burned like one eth on there uh now meant me one e on on this roll up that that I'm currently on um so that's kind of like a good system for like a synchronous bridging because

you can do like fully trustless because as long as the block has is verified and you can show like this miracle proof that this thing happened on Source chain then this is like a fully trustless uh process so it's cool but the downside is that okay you have to wait on the z l Bo or some other proving system to can like uh finalize your like the source L2 block hash and then you still have to put like this meracle proof onchain for like some something that happened in the past uh and this is kind like also quite expensive um so yeah that's kind of like how most like trustless Bridges currently work without using like Prett deeris so um so yeah that's kind of like the current state of like okay what what

kind like happens when you have like a single l tool then you have like on the L1 you have like a single smart contract there you have like also use it as like a bridge in some way and then the L2 kind like has like a a similar like setup where there like also like a bridge contract uh and so if you want to do bridge in this case yeah it kind of like works because you bridge from L1 to L2 there's only like L1 L2 so that's fine you do whatever want and then if you want to get out you kind like Bridge back to the one so this set makes a lot of sense if there's only like one L2 Now problem is if you have like multiple outs to scale even more then yeah if you kind of like do the naive way then all

these different rups have their own Bridges and then all the L2 you also have like these bridges that depend on like their L1 specific Bridge so if you want to go like okay you're on like one L2 and you want to do something on another L2 yeah you have to go through the L1 basically because you're like for example if you want to transfer one E from one L2 to the other then the bridge contract on L1 will store that one e so if your one e is now for another rollup that one e somehow has to move from this in a smart contract one to the other smart L1 so that cap like is a transfer on L1 which will be expensive uh and also like a slow progress because you have to go through like all this like verification mechanism that I so this is

like a very inconvenient way to actually uh scale with l2s if you have like multiple L um so you can approve on this so for example if instead of like different L1 smart objects with like different L1 Bridges or um that kind of like store all the funds you just have like the one uh and then all l2s kind of like hook up into like the single Bridge uh so that's also like much more convenient already because now if you do transfer like one East from one L2 to the other uh you don't actually have to do any transfers on a w because all the l2s use this like share bridge and that one East will be at the crank Bridge even if you go from one L2 to the other so that's kind of like a good system but if you still depend on like storage Poes directly

it's still like a synchronous so you do have to write something on one L2 wait on things to finalize and then on the other al2 you have like to prove it so it's still like it could take a while before we can actually Bridge um and then like it then the Improvement on top of that is like instead of like asynchronous uh so you have to wait you can actually do like synchronous uh bridging from one L2 to the other uh and so one thing that was previously uh like proposed there was like Shar validity rules um sorry I forgot like the company that proposed it but yeah it's a umra umra research I think uh but I could be wrong so they propos like using like a smart contract on like the al2 to say like okay instead of like um writing

something to S like some smart contract on one L2 and then reading it on the other L2 it's kind of like part of like your validity rules of all the l2s so um you would say like okay there's like this bus contract and on both l2s you kind of like have to do like okay there's one e that needs to be transferred both need to kind of like write something to it and then you can say like okay for this L2 to be valid both l2s need to have written this data to like this this special cult and that way you can actually solve like any as synchronous problems and you can make it like fully synchronous but it does have like problems because now for example each L2 doesn't have like its own validity rules because writing something to a Smart L2 can be valid uh

for the L2 itself but now we also depend on like this opposite L2 where you did the bridging from or to to also have done that right and otherwise if that didn't happen then you didn't follow the rules of like this syn like the synchronous bridging so that means that yeah this L2 block is valid for the for the L2 itself but it's not valid it in C like this whole uh system O2 so this block would still need to be like reverted or ejected even though the transaction was actually executed correctly so that's kind of like the the downside of this uh and yeah that's why I say here that if you actually want to do this system in like uh a way that doesn't depend on like some

optimistic um um again mechanisms or have like everybody required to run notes for all the l2s uh you would have to depend on okay I run like a note for one specific L2 but I can actually depend on very cheap to verify proofs for all the other l2s so I don't have to run notes for those I just have to check the proofs for those and then for my own Ro okay I can actually check everything is correct myself so this kind of like depends on like get false proofs basically so if you like propose a transaction a propos like these blocks that kind of like are in connected then you kind of like enforce this kind of like requirement of okay if I want to keep things fast and like mostly like trustless um then oh

yeah fully trust this if you have like lots of proves there uh then you can actually make this like very well so but yeah this does depend on like trust proofs and ziky proofs are pretty fast already uh but we're not as fast as necessary to actually make this as like rock proposer time because like ideally you can actually create these boovs in like like get one a one block time or or some that um especially for like bases yeah that's the uh that's the uh that's the only current uh major trade-off that that we've seen consistently with the with the ZK side two things on this side first um is there a difference in L2 uh shared sequencing um where um there's this notion of

atomic inclusion of transactions as well as atomic execution are these one and the same when it comes a Shar sequencing um with rollups so basically you take all these transactions Shar you you sequence them address multiple different rollups they're all put in the same block is that is that Atomic inclusion and execution or there's some sort of like minuscule time difference which causes it to be like almost atomically composable rather than like fully atomically composable yeah for normally shared speak just do the ordering so they can enforce that your transaction is included on all the to that you want to do it but it doesn't enforce that like yeah if if like your transaction

yeah your like all these transactions need like succeed um because if your transaction fails on like your Source roll up to actually like a burn something and you want to M it on the other side then if your burn fails then your mint yeah will also F so it kind like doesn't at Force like both to be at the same time and that can uh give some issues so there are are some like work arounds for it uh also make with like like also like some some liquidity providing uh mechanism to say like okay you can you can actually get there but it's then it's kind of like not Capital efficient um so it's kind of like duplicating the funds post chap I think that's the the latest one like the best possible solutions that's currently put forward to actually do like yeah Atomic like execution instead of like just like

inclusion guarantees yeah so I was thinking because there's difference between ordering and then also executing and then my other thing on this slide and and I feel like what you guys are building with the base boosted rups are kind of solving this in a sense where let's say the these l2s here have like centralized sequencers just like typical current state of rollups with these bus contracts and with these interoperability whether it be by Shar sequencer um or just kind of bridges as is if one of these l2s were to some for some reason uh have major downtime how does that affect the the state of the other l2s which are I guess horizontally integrated with SH sequencing or with um some sort of like

bridging mechanism like is there cause for catastrophic kind of issues or or in shared sequencers kind of uh like if one rollup has some serious downtime they can kind of just almost like isolate that and and then once it gets back up the state is reigned or like in the sense of downtime how does shared sequence and kind of protect uh users or funds on other rollups which don't go down um uh I would say basically none like no extra guarantees because if you have your funds on one L2 and you or yeah you want to do something on like a specific out to or you real money there then if that uh Roll Up is like get down or like

live not live for some reason because yeah the sequencer is done then yeah you cannot uh work around that because that's the only place you will have your your state stored so yeah in that case that cannot happen and that's also like why using like centralized components is like a bad thing right so that's what also like what like doing like a base rollup solves so as long as L1 is actually in life for a base rollup um and there is somebody that is willing to create a block anybody at all then okay the system keeps keeps going and you can actually interact with the chain as you you expect to do love it yeah I figure that's what you guys were solving for so all right on onwards and upwards right I so yeah so

there a the false proof things like ziki is not there yet but like for example like te like sjx that we currently launched just now on are test that yeah they can do like very fast proing of the blocks right so that's kind of like a very convenient way we can actually already have like very strong guarantees of like the initial like even that when the block is proposed we can already have like very good guarantees that whatever the proposer posted is actually the correct State and people canot really depend on it uh to make subsequent blocks um so yeah so this is cool system uh but yeah what we're trying to also solve it like wh is a little bit more than than than than just this um so in

this case uh we still have like the problem where each L2 is kind of like its isolate State um so um if you have like well yeah whatever application that you want to use as so you have like all the all the common ones like hey Unis swap is of course like a very good example because everybody wants to use Unis swap um so yeah you can't of depend on Unis swap specifically deploying to whatever L2 you actually are interested in music um so that's kind of like uh a big problem especially if you expect um like a lot of like l2s to to have to be created right so if you have like 100 l2s that you eventually need to to scale then having to deploy like each application having to deploy this to

this like L2 that you kind of like want to have available everywhere uh is kind of like yeah a hard thing to to get developers to do and also kind of like maintain right because like these applications mostly are still being updated so if you have like an update for your application then you have to do it like all the all the different places or all the l2s and have to go through all the all the Hassel tuta um so yeah you first yeah you get you have to get your application there then you have to keep it updated and users will go where applications go or uh at least if like this um especially if there's like no being way to like Bridge or like if that's like another a great user experience um the other thing is like currently most Al although like in it's

more like a practical thing uh because in theory you could have like multiple bridges for most tokens but yeah in in in practice mostly people just use like you can't like have to wrap your token contract on L1 to be able to bridge it from like L2 one to L2 uh and so these are kind of like yeah um very security CR critical things because if there's like a bug in your bridge then basically all the funds that are stored out to you can just get it out um so not having like a single point of failure there for security would also be a great thing to have um so yeah and and currently like a lot of like interesting state is still on L1 right so uh not being able to access anything on L1 is like very

inconvenient because yeah even yeah for the the most common case course you want to deposit something from L1 to L2 so you have to be able to read L1 for that so that's kind of like a very common case but also for things like yeah you have like your smart wallet on L1 uh you also want to use that smart wallet L2 or like multiple l2s so that would be also be like a case where okay um I kind of like set my like multi sake up on L1 that that's where all the the state is stores and actually I want to just use that state on all the l2s that I also used my small qu to so that's also kind of like a a thing that makes it like much more convenient because compared to like apps that you have to keep updated

everywhere also users have kind of like the states where they have like a Smart M they have like multiple Gardens they have to keep it up to dat between all the l2s that they that they kind like interact with so that's where metallic also wrote like a post about this using like key stores and like one one chain having like a key store and then you just access that key store on all the chains so that's also yeah if you use L1 that's kind of like the currently like the most convenient way to do it because automatically all Al Tunes have access to the L1 in some way uh but yeah even in the future like at doing anything on R1 will be expensive uh so we we also have to be able to to reach from r2s yeah y y it's a cold start problem

for developers and and for Builders it's like well you you need to deploy across this many opers to against the key rups why why do you have to redeploy your contracts and your app you know across all of these chains uh you even necessarily perhaps write uh new parameters for for different codes and then also the vsan comes again with uh updates right like okay the first time you deploy in app PR 10 change okay fine it's a it's a headache but you got it out there now you're you know multi-chain crushing whatever you want to call it but then you got to laun of D2 you have to pay for audits on your code and then you have to make sure that all the audits every single chain you know with the sleep with the slight

differences if if there are any between you know uh L1 l to ZK alistic or alternative L1 or E compatible side chain or there's all these different kind of like Ines so um what's the solution what's the solution we're getting close so yeah that's also like a good point that I didn't like mention like exity but yeah so um just well I guess it's part of the solution but yeah being like a type one uh ziky evm or like being like fully equivalent is like very useful here because yeah uh then there are no change changes that have to do between like all the all the ATM Rec chains um so yeah and also again for

like the last one I guess it's also like having like a standard or like an automatic way to actually construct like cross chain transactions is also kind of like an important thing uh so ens actually has like some interesting eips about this uh but yeah if you for example do like a bridge transaction uh even like today then like yeah you do like a transaction on a one for like a deposit and then you somehow have to know like what to do on the opposite side of the transaction right and there's like no standard way to get and kind of like know like okay if I did this thing on L1 what do I actually have to do on the other L2 to get my my money there so that kind of like yeah a standard way to to interact with like multiple alos is also like an important

thing okay so what does the booster world like okay what is the basic idea here for like the Boer world is that instead of like having to deploy uh or like yeah instead of having like an L2 start from scratch um or like having no State having no smart contracts having nothing at all each L2 would basically like have like a built-in mirror to like the L1 or whatever parent chain there is there um so you would be able to say like okay I want to interact with like this smart L1 but I want to actually do it L2 you could you could do this on any like booster world that that will be deployed from the start so it's not like a a was lint there you can actually just add like an extra rollup to the system

and you can already start doing whatever you want there so if for example yeah it kind like the ideal case and also like very simple example is kind like just token contract so if you have like a chain where you have to do like lots of like stable coin transfers then yeah the really the only thing you have to do is basically add this whist up and you already automatically have like the token smct for usdc or usdt available there and you can already do like transfers on on that 12 um there so you automatically add like extra capacity to the system uh although like yeah to to be clear uh there will be still be like specific L2 state right so it's not automatically like okay yeah you can you can you have like all the state there you would still have to do

Cary the state from the correct wle basically uh but yeah L2 still it's still it's still distinguish between the other l2s as well as L1 yeah exactly exactly right which is very important for like for for security as well as like uh verifiability yeah scalability so yeah if you so for example like the thing that's most important for like a rule up is that you can actually like you have some money stored on your L2 and normally you can depend on like proposers build whatever to actually yeah you you give them your transaction they will handle it for you and you get your money out so for rollups the the important thing here is that you do not have to depend on others to to actually

do that to be able to get your money out so it still needs to be easy enough uh to run like an out2 node on your own so that you can actually build a block like process your own withdrawal transaction yourself and and so exit the system H so that's why for each L2 specifically yeah the the the requirements and like the storage required for it still needs to be kept uh in the get somehow somehow uh limited uh so like yeah the the so it's a limited capacity per L2 but by having like lots of them you kind like incre the scalability yeah so real quick on this which like of course the the point of the uh top of the hour for us and top of

mind is um the modular blockchain stuff right separating these rollups so with with with uh with boosted rollups as far as data storage goes how does that work um and is that something that you guys are looking into does it all just Goose to the L1 is that kind of like how it works or can you use like Celestial r or insert G layers here or kind of like what's your thought there yeah in theory yeah yeah the data availability layer is like yeah you could pick whatever one you like uh because we do not depend on like any specific ones for the rule up the book so as long as the data is

accessible to notes in some way it should work but um like obviously like the Avil sampling Solutions are like very interested now uh interesting so like has come back obvious Cas there also like the restating one from igen layer would also be very interesting uh but yeah it's kind of like a we're at like an interesting point in time where like in two months we will actually have like lots of like more data uh availability capacity just on itself U because of like EI EIP for $4 shipping and so the data availability Wars are happening like you got is launching main NE this quarter and then also EIP 4844 ethereum is going from computational

road map to like data Focus road map so it's just gonna be like a freaking battle it's gonna be just EI e either way the thing that I love about this and about what you guys are building is that users get cheaper costs more security and better experience no matter who kind of wins right um some tradeoffs there are some kind of Ines but overall the users are the ones who end up winning from these like Innovation battles if you will yeah yeah yeah so we'll have to see like how the like ideally of course we we stick with eum because if you add assumptions to like know chain then it does worsen your security uh so that's why I think it's like smart to see like how things will actually progress on AUM because in two months or three months

this will actually be available onum and like a limited Capac NY at least uh but like nobody can really know like what the data availability costs will be because this has like the data availability cost inp 4844 has its own fee market and the Fe Market is kind of like similar to like the normal transaction fee Market where like the the cost is just based on congestion so if nobody uses the data blops then the data blops are free so you can do better than free so it depends on like how this kind is adopted and like how many ales will actually start using it and like how quickly to actually know like okay what's what's is actually the cost of publishing data on it year withp 4844 because nobody knows it's hard to predict there's like no data some people

take like 10x uh improv it but it's just like yeah it's kind of like mostly guess work because it all depends on like who uses and how much it's used so doesn't yeah yeah doesn't make sense to use something like Celestial but maybe they're cheaper maybe not cheaper like how how long be cheaper who knows am security it's a trade op right it's it's a and I also think it's use case specific um something more financially secure C of tvl perhaps posting to theum using e 444s costone makes sense something less financially uh you know important perhaps using alternative da for just ux be and even lower cost but again it's yet to be seen

so we're still in the early endings of this which is exciting and think that idea of not needing to charge uh the rollup uh like the the the sequencer not needing to uh process blocks there there's no transactions is very helpful for early stage app chains or early stage rups who may not have that much traction where they don't have to pay for the blocks every single you know couple seconds if no one's using it it kind of it allows them to look at the revenue models for how they're going to make money or at Le how they're going to reach sustainability and it no that the the the fixed CES having to to pay for each flock uh kind of goes down in more variable cost based on usage so um it's

interesting onwards and upwards so booster rollups yep uh all right yeah this slide is just from the from the article I think is a good one so to to make it clear like what's the ideas is like okay well you have like a limited C like l2s but if you need more then sure like yeah plug one in and yeah you kind of like have like the initial State there that you can start using so I think this is kind of like a good way to visualize that for people uh so it's kind of like yeah plugging in a Bo up uh is like yeah adding like the CPU and like extra storage to to to your chain um which might be easy for people to understand I don't know uh but seem seems something reasonable to for people to understand uh so yeah so this kind of like so the

idea is here also that like yeah the amount of like whistle robs com in the system like yeah would be would be able to get like very high right um so there would be no problem a thousand of these compact in the system um so that's a goal and when you add more does it increase do there is there any benefit for the existing ones are are they using shared sequence single cross stem or is there some sort of um I I understand sees happening at the L1 layer but is there costs that are socialized or is there any benefits to having 10 10,000 a million or does it just kind of scale as it is there's no downside anymore um so the so the there would there should be like no downside

in adding more for for users it's just that um so there's a couple of things like why would you add more right so yeah so that means that you would add more if somehow the other comp are congested um and so if they are congested so we use like EIP 15 F9 on rl2 so if if things are like congested then the the base P will go up so use transactions will be the more expensive right on this specific boost world so if you say like wait this is kind of like my for example my smart wallet is on like this wor uh with like very high fees then you might like want to look into like actually migrating to another one but like cheaper fees um so that's kind of like if you add like a new one then there won't be like lots of

activity there and you can just like move there and then still very easily interact with whatever other rollup you want uh for like specific like liquidity pools that are still like the most liquid on like a specific or somehow not like fully upped into the system right because um for like smart contracts to fully take advantage of the system they would still have to like be able to like do these like cross chain um transactions inside the system um so for example like if you have like smart wallet and you want to do something on like an other chain then your smart W does have to say like okay I want to interact with like this specific or although there's some some ways you

could try to like uh solve that but at least that's not part of the C scope so this is comp how it would work love it yep so yeah I guess like this is kind like the example for like the smart wallet case uh together with like some some interesting like L1 uses as well so if you have like one your smart wet on like one L2 uh and you want to interact with like like yeah some kind of like specific pool that for some reason has most liquidity like one of the l2s uh then you would just do like okay start your normal transaction on a specific L2 you do like a call to like an all out2 to do a swap this swap on its own will also do like uh token transfers on like the different chains

so you could have your money stored on make whatever al2 uh and you just specify what what one that is it will do the transfer there to like the the the liquidity pool and then yeah you kind of like Bal it by by selling your tokens and then you get your tokens back uh so for users it looks like a normal transaction um so they don't have to do anything they just have to sign this one smart Wallet transaction uh and then like the system will just take take care of so yeah what I also added here is like the key stor so um if the user also has it smart wallet deployed on L1 which isn't required you can just deploy your smart wallet on a specific L2 but if it's on L1 then you can use like this key store system so if

you execute your smart wallet on L2 then you'll actually read what signatures are required to be able to execute uh a transaction in your smart wallet uh and okay you can just query it directly from the L1 uh so there's like no delays no extra proofs necessary no moral proofs that you have to generate nothing nothing at all you just it's just part of like normal smart cut code you just have to execute this transaction and this it will do everything for you uh no no manual setup faces that and so when users are interacting with this um what they what they don't see under the hood is that when they post when they submit a transaction on the L2 um it's actually going to being

sequenced by the L1 uh in in in leging in in an ethereum block um so I'm I'm curious on to how how you can take L1 sequencing and get the same low fees and high throughput of l2s um but while taking those transactions and putting them to L1 like is there what's like like is there a like the mechanism in which one transaction on L2 is is very cheap but is also sequenced by L1 how does that how does that work right uh so um how do you best explain it so

things on L1 are priced in like a gas right so you pay gas to do something on L1 and so if you if you actually execute things like if you have like a full transaction R1 then there's a couple of things that you pay so first of all you have like a transaction which needs to like a signature validated uh and so the base cost is already like 21,000 guess uh and then other costs can like add up to it so you have like yeah your your transaction needs some data and the data also requires some so to spend some some some guas and then obviously like all the smart contract codes needs to be executed so all the smart contract code that needs to be executed also cost gas for for transaction so all that kind of like there wrapped up it's kind of like

yeah do total cost for a transaction and the more people that want to do a transaction on L1 the higher the fee is that you have to pay because the the L1 would be congested um so like how does how does N2 actually make things cheaper is that there is actually like specific blond Builders like let's let's keep it not too many details so that it will be like you create like an L2 transaction and there will be like block builders that kind of like batch all these L2 transactions together uh and this batching uh will then be wrapped up in like another L1 transaction but the only thing that needs to be done there on L1 is kind of like just saying like Okay these are the L2 transactions that need

to be done uh and it's just the transaction data that you have to clst there uh but there's also like other ways but in our case as well it's just like the L2 transaction data that needs to be post there so you skip all like all the like signature checks and kind like things like that and also obviously like and none of the smart contracts are executed uh like all none of the transactions are actually executed on the L1 that are L2 so that's where like the savings come from so you instead of like having to execute the actually on L1 which cost guest now on L2 if you want to put data on here you only cost you pay is like this this this data and obviously like if you somehow still have to verify that whatever you did allow to is correct so that's where also like the

proving com which also yeah and the state is different right that makes sort of sense so basically what I'm learning from all these different iterations is that this is a way to avoid the typical tradeoff of like roll up with Central Seer security issues M problems with Bas ropes we're getting to this point where you're getting all the benefits up an L2 and also still really in inheriting like the core principles of ethereum and core properties which make it uh decentralized and the best kind of sell it yeah yeah so so this this like these batchers of blocks like L2 transaction that I talked about like L2 blond

Builders so that could be like anyone so anybody would be able to do that and then they just have to make like just a normal L1 transaction out of it and then they just have to be able to push that one one transactions through the normal setup um so that's compared to like uh like compared to like centralized um sequencers so that's like where like users submit their L2 transactions directly to like this centralized sequencer and then only this centralized sequencer can actually push uh a block of like this this this aggregated like transactions block on the L walk so so they are like the only like block builders in in C or the terms that we use in if you use like Bas R up

that anybody can be a block Builder and you just have to be able to get your block on chain uh in whatever way you can and would well onwards and upwards ladies and gentlemen I think we're almost done okay so I think like this is just like some some like how does it look like uh and this is kind of like the current design uh which uh yeah it's pretty dark I guess well I guess like most people don't care anyways but if you how does it actually look like now and I'm sure like things will still like change as we go along uh but yeah so basically your s looks exactly the same this is just like an extra like evm call options that you set and then you just

specify like okay I want to do this like this call in like my code and I want to do this on like another chain so you just specify there and everything else will be done that's the only thing uh and this is the same thing so we skip it so but the but the but the key thing of those two points because yeah I mean I those go over my head but you know is what it is um those two key points it's that uh the token contract is the same as an L1 toing contract right that's the key thing here and so it's it's it's completely uh replicable from the L1 which allows these things to happen which is again it solves the problem that we were speaking about earlier with regards to the uh you know multiple audits multiple uh deployments different

con you know all these different token contracts right even for like having your token on different chains is can get confusing for users obviously there's like layer zero and different Tex of Standards but um at the end of the day like having the with little trust assumptions the same to contract goes a long way yeah yeah exactly so this for example if you have like an to contract you would actually deploy it on L1 because you want it to be available on all the L uh for forever and like the only thing that you would have to do to be able to use this is yeah deploy just like a bu up and then you can just directly use it to to interact with things so this the same contract code will execute uh on L1 L2 wherever on all the booster WS current current re for

booster wups future wups uh anyways all of that uh so yeah you can also like CH like I guess this could be like interesting uh so yeah you can also like um like yeah choose like where you store the state like so for example you have like a total balance uh and this total balance is kind of like Get shared for all the al2s so you would actually store this on L1 so you have like this function here that said like okay if somebody calls like total balce then you just want to redirect them to the L1 state uh but like for transfers then again you have to be like uh flexible and say like okay um I want to go from like this this specific to to the yell so I think this is last slide but last slide but yeah this can so we have

all these transactions all these blocks all these l2s like how how do we actually like yeah propose a block in this system uh and So currently the idea is to have like just like a single transaction list uh not all like like how shared sequences also like handle so there would be like one large string of like transactions and block Builders would actually like yeah block Builders would pop up and actually do all these like transactions create this this transaction list and they would actually uh build this comp like in sigit so that also allows us to like synchronous uh bridging uh and so these blond BS will we have to see like if there's like a thousand l2s these block Brothers will also have to be like specialized and say like okay I can do transactions for like

a couple of these like would robs but maybe not all of them because they can't like sync all all of the state necessary to do that um so you will be able to specify like okay this is com my transaction I touch like all these different rups uh one Builder just make sure that you have the state to do that otherwise you will not be able to to to uh create like this this um yeah a like cross roll up transaction um so yeah this kind like one one block is bed basically like one block uh and so block drills build like this one block of all these like different booster ws and this the prover will also like just have to prove all this uh it's similar to like how One bu build this the pro will also have to prove this the single ball um so that's

kind of like how this works so that means that uh depending on like how many of this this change this rollups are actually touched in in the block uh depends on like how uh competitional heavy the block building be will be but that's fine because block building and proving is done by like very heavy machines so they can handle that load and they can like be very specialized um but the important thing is here that if you want like your own notes to be able to be able to exit the world if necessary you only have to care about like one chck uh so you just have to filter out transactions that you care about for your own not uh and then be able to yeah sync your own note and and use it whatever way you like to do it um so yeah I think that's it so so it's

single proof this this cost is then mitigated and shared amongst all the uh all the transac which that Builder uh you know puts into the block yeah yeah yeah single proof so like it so you could have like a thousand thousands of these rups working together in like a single block and it would still be one proof on a CH so that's also like the benefit of yeah the benefit of this because if you have like a to like for now you have like 10 rollups and all these 10 rollups have their own proving systems to to uh prove like a block uh but block cerification especially like with ZK is also still like quite expensive it's got like three or 400,000 guess uh so if you can kind of like batch them up even more off CH and have like a single Pro then yeah sure the

proving cost gets a little bit higher uh but like the the cost you save on that one is uh significant and so with the upcoming e444 Will that also significantly uh reduce the cost of the proof or is that strictly just the data cost for posting uh yeah so how is that going to affect the proing uh the proofing cost will not be directly impacted because uh for most ZK systems well uh if you kind of like depend on Starks Starks still have like pretty big proofs uh but if if people that are actually using it mostly wrap them up in like a snark with like a they're using like a recursive a

recursive pove uh where yeah you can like go from a stark to a snark to be able to uh minimize the data and verification cost launching um so yeah most prooves I think are like a couple of kilobytes at most so it won't have like a signant uh well it will be like much smaller actually but yeah it will be like um around but I don't put any numbers on it to take it will be a small cost in data for proofs most of the cost for proofs for snars is just like the computational cost um even though there are pre compiles in the end it's still like quite expensive to do like 300,000 gu makes sense well we bre thank you so much for uh coming out and uh giv the uh

the really intricate understanding of what a Bas R is and what it's wor and um really and excited to see these out in the wild um when can we expect the first base Bo to rollup on yeah on Main no want make any like promises but uh like yeah I think a road map of like one year two years at the most I think is very reasonable I think uh I hope I hope we can get like more like the same as we did with like Tao now like having like lots of like test Nets to be able to quickly test things out fight like problems it R on uh I think that could be like way like much much quicker but yeah M at release will require some

additional work to get everything ready yes sir all right well again thank you Brett for coming on and um excited for uh to keep try out the Tao testet that just went run as well as upcoming main net and everything else the RO world is very exciting so thank you yep yeah it was great to hear it thank you