Are Based Rollups The Solution To Ethereum's Long-Term Value Capture?

Transcript

GM welcome to another episode of the rollup today we have the pleasure of speaking with BR and Cecilia of gwenith and gwenith is a based rollup incubated by Tao which is using the base boosted contestable rollup stack out of Tao we discuss the mechanism designed for gwenith and discuss some of the trade-offs for based rollups in general hope you enjoy today's video before we get into it a word from our sponsors [Music] enjoy cartey is your home for app specific rollups at the Forefront of

developing new tools and platforms that enhance the capabilities of blockchain Technology ctei enables applications that are flexible and built to scale build on a full Linux environment and use traditional software libraries but in blockchain development go to cy. that's cy. to learn more about building your own app chain today mantel is a layer 2 blockchain with one of the biggest onchain treasuries in all of crypto and they have a 100 day campaign called metamorphosis live now what this is is it is a campaign for their liquid staked eth token and eth as well as their upcoming liquid reaking token C at me

where you can utilize this token on the mantel Network in a variety of different apps some of your favorite resticking protocols and defi protocols and earn yields in the form of powder which will eventually be turning into a governance token Mantle's been around for a while we like them because they use their own form of Ian da uh they have a good ecosystem and they're growing so check out this 100 day metamorphosis campaign and hope you guys enjoy the rest of this video what's going on Welcome Back to the rollup I'm standing desk in NYC first podcast ever on a standing desk the I think the size of the desk is a little too big but then I have this box for my camera so just trying to figure

it out here but I'm feeling pretty based right now um and I know Brett is as well and we have a new guest Cecilia um so looking forward to that Brett welcome back Rob GM um and yeah man we're gonna put some base rollup educational content together today yeah thanks for having uh having us back and uh well I guess it's kind of like it's kind of like a nice Evolution I think from my previous presentation although like some parts even from the presentation are exactly the same but we give some updates and kind of like the kind the evolution that the design has gone through and also like the like different priorities than I guess like last time um because there's some some extra cool that we can actually do

now uh so yeah we'll be we'll be great to kind like explain and also like let people come like learn like what we're actually doing and hopefully they agree this this is actually pretty cool and uh useful solution hell yeah and Cecilia on um would love a quick intro uh because it's your first time on the show and then we can jump in so hi everyone my name is Cecilia I'm a ZK developer at Tao now at granth um and these day I've been working on like base pre-confirmation protocal design and also some of the client code just helping out BR in general so nice to see you guys welcome yeah very excited to learn more

about pre Bas pre- confirmations and and gwenith in general um yeah why don't you I you guys have a whole presentation prepared so feel free to Jump Right In okay so let's start with that what actually gwth is I guess gwth I have to make sure that I actually also pronounce this correctly but it is a gwet is the pronunciation uh so yeah let's let's just talk about like okay what makes like gwet kind special or kind like what are the the core features uh so if you go go to the next slide see okay okay so what is Win still like Tao still a boost like a base roll up of

course and like I guess the the the new thing there uh will also like be like based confirmations because obviously one of the downsides of being based is kind of like the longer uh confirmation time for users and also kind of like the less kind like lower efficiency also because of that reason and so kind of like one thing that we want to make sure we get right this time as well is having like high efficiency of like how block are being proposed but also from like the user perspective where yeah they kind of like have like very fast confirmation types if they actually do uh a transaction on on Quin so yeah that's kind of like a big thing Al this presentation will mostly not go about will be about like pre confirmations but if there's more questions about it then

glad to ask it but yeah most of the presentation will be kind of like about like how we kind like do the horizontal scaling part using boost roll up still but also combined now with um like synchronous composability between all the different layers and so previously the focus was mostly on like synchronous composability between the l2s themselves within with it um but now we also put like a lot of focus on actually making it possible to do synchronous composability with L1 as well and so the reason this wasn't like a before is because doing syn possibility with the other one is kind of like not easy and uh you kind of like have to have the necessary infrastructure to even be able

to do it but I guess that's something we will explain like in one of the later slides as well um and then yeah obviously still a booster rollup so we have like the extra functionality to be able to cheaply access like State on the L1 or other l2s as well but I guess the L1 part is kind the most interesting one uh and then yeah the other thing to also make it possible to do synchr scil well one is kind of like real time proving or at least like close to real time proving something like sub 12 seconds uh the L1 block times and yeah one other thing that's also kind of like important for that is you we only need like real time proving but the finalization time of the prove itself also kind of like needs to

be directly uh so when we post the proof on chain it has to be accepted directly to be able to do the synchronous compatibility with one and to make sure that that is actually like secure and to have like enough confidence in this we also have to use like a multipro to to be able to do that so we don't just have like all like the security relies on like a single proof or like even one single type of proof we kind of like want to have like some diversity there doing like the mul multiple noes implementation that kind of like stuff so yeah that's in a nutshell what the buness is trying to do and what we'll try to explain more in in detail in the in the next couple of slides So currently in the ecosystem we have like a lot of l2s um and obviously that will

introduce fragmented liquidity right and also I feel like people are running out of thesis for launching more L2 so that we come to the this app chain thesis which is good but it doesn't stop liquidity being fragmented further more and we kind of need a solution to like to stop diluting the liquidity also stop deteriorating the user experience it's like bridging from different l to even given the app chains that you're you're using is kind of painful um that's the the ecosystem perspective and for a technical perspective um we think that ideally we can have a single chain at least from a user experience everything

should be seen like a single chain but um the fact is a single chain can't scale that much because of high congestion like if you have one chain following the 1559 paradigm um you'll have like very high con congestion fee uh and results in the very high base fee um that the user will see um and also like for the current L1 the block time is capped at 12 seconds because um to in order to maintain like the security assumption that we want to have for L1 given the the large amount of validator you do have a lot a lot of BS signatures to Aggregate and also the consensus itself and just to to sync the state and

that's like 12 second is a is a very realistic cap for a large blockchain like ethereum so a single chain is like literally not possible for the user experience that we want to aim for so we sort of want to break it up um to more chain but hopefully uh for the user it still look like one chain so that's the goal of GTH yeah we've been talking a lot about that here like um just like you just can't scale a single state machine and the bet the BET of this modular thesis if you will or like this kind of rollup Centric road map is that we can Scale app chains and rollups and put them

together via what you guys are going to argue as based rollup composability what others are saying intense what others are going to say shared sequencing and coordinated block building or just basic transport layers and do such do such in a way that is also abstracted away via some orchestration or some wallet abstraction Partners on the user level and so that's like the BET and I put out a tweet I was like I think this the bet is that if we can't do it then we struggle to kind of fulfill the vision of like what we think is achievable for maximum scale but if we can achieve that and then go further from there into different ZK and base designs ET that I think I wrote and I think this how I

feel that like the end game or the result is almost like un so I just think that we're on the same page there and um I I just wanted to kind of further reinforce uh the way that you guys are thinking about this um but I'm excited to get school on technicals so let's do it yeah let's do it okay BR right so yeah I guess well I guess in the end the only thing that really matters is the ux or like whatever us see but we go into the technicals because that's what like actually do uh so okay let's let's start from like the the current like well I guess it's still the current kind of like state of things and so you have like single like isolated rups and they have like their own kind of like way to

kind like deposit and withdraw and basically they're like just like well fragmented isolated kind of like Islands everything that is happening on this L2 only happens on this L2 you can directly interact with L1 you cannot directly interact with any other l2s uh so that's not a great experience especially if you have like hundreds of these so not good enough let's go to Next Step where we actually introduce multiple l2s uh so yeah so this is kind of like the same thing but like with multiple l2s here so all each L2 has like their own bridge and if they all have like their own bridge then moving funds from like one roll up to the other has to go to this L1 this bridge that is on L1 which is well well very expensive to

begin with and also not a great user experience because yeah people have to wait until kind of like the the L2 kind of like finalizes which could be like a couple of hours until uh up to like a week for like optimistic rollups so this is not great and there are solutions to kind of like get around this problem but then they kind like depend on like liquidity providers which is not Capital efficient and also introduce like extra fees and things like that so um not yeah well still the status quo but not not a great solution so how do we improve on this is conf like this kind like shared Bridge conflict um design uh which I guess is conflict now the accepted conflict solution don't like how to actually do this so instead of having each roll up have its own Bridge uh on the L1 you

have like a shared bridge on the L1 which contains all the deposits for all the l2s um contct combined so that means that you don't have to go through the L1 again H to you have don't have to go through the L1 to kind of like move funds from one L2 to the other you can just do some kind of like prove that you kind like burn some some kind of like funds on R up a and then you can mint them on R up B you don't have to touch uh the L1 at all you just have to able to prove that something happened on the other alter and that's basically it so this is pretty good solution um it's kind of like uh cheap because you don't only have to touch the two rups that you're like actually interested in um but it's still not ideal because it does

have to happen like a synchrony so you do have to have like two separate kind of like transactions one to kind of like burn it then one to kind of like mint it on the other rollup and like the the time frame to actually be able to Mint the the tokens on the other rollup depends on the finalization time of the source rollup so if it's again it's kind like an optimistic rollup then you can burn something on on rollup a but you will only be able to actually mint it again on the other rollup when the state has finalized on a which is kind of like a week so this would be like a very very slow way slow method to do it but for like ZK rollups this would be kind of like acceptable depending on like how uh like how often the state is kind of like

finalized uh but still it's a synchronous people kind of like have to do these transactions in like multiple Parts um there might be like a relayer that helps doing like the opposite transaction but it's still kind of like pretty pretty messy and not a great user experience also the It's Kind like not standardized kind like how this works so depending on like what bridge or like what R up you're on uh the user experience might be like pretty pretty different yeah this is like reminds me not not the syn necessarily but but the previous slide reminds me of like super Shan and Ag and those types of designs or at least like a similar thought process there um but I think like the big breakthrough that that we're going to talk about here is kind of like the synchrony the synchronous nature of Base

throwups um as kind of like a big shelling point for the vital for the viability of them in the long term so uh I I'm kind of thinking about this as like there's like rollup clusters that we have right now like you've got like the super chain like ZK stack and like Tao has like its gwith Tao other chains in the future you got like arbitrum now these may fall into some of this asynchronous communication between these separate kind of like clusters but I'm viewing this as like within the Clusters that's going to be synchronous whether via coordinated block building or like base rups or something like that so yeah kind of kind of been slowly putting together a thesis on this but definitely curious to see sure to understand what you guys think

about that as well um I think oh you want to say something see yeah I was going to hit that like maybe we should like skip these like slides faster so that we can get like the the nigre of synchronous block building I think that that would be the yeah yeah let's go see where you're going we're almost there we're almost there the next the next SL introduces the synchronous building aspect well the synchronous aspect so like how we actually see kind of like the synchronous compossibility working uh so then okay we are there we have like the we still have like bridges in this kind of like scheme uh but the bridges would basically be able to directly call each

other to do the the burning and minting and so instead of having well having the relying on like verifying morle proofs or kind of like any kind of like asynchronous proving process we would just be able to prove all the l2s at the same time as they kind com but as as transaction are actually executed uh so you don't have to have like any specific like smart contracts kind of like specific functionality you would simply be able to call in the other smart contract and kind of like because the block would be proven together you can indirectly kind like prove all the interactions between them as well so that's a good thing but the one kind of like downside of this is well if you

actually want this to be like scalable and then if there's like lots of like these layer twos around then to be able to verify that these transactions were actually executed correctly you basically have to run a full note to to be able to check that and so yeah you can have like clusters or whatever you can like want to introduce but ideally you would be able to just sync one L2 and be able to make sure that is L1 L2 that you singly the correct state that you get from the album and so the easiest way and the most skillable way to do this is obviously validity proofs and so what we will be doing is to directly have the village proof available when the block is being proposed and also the block

that is being proposed is already like spit up split up between the l2s so that you only need to so you only need to sync for like you only need to actually execute the transactions that you are like interested in so if you only want to syn with uh like roll up a then on the onchain data will provide you exactly with the data that's necessary to just sync R up a even if there's like cross change transactions going on and so the data that's provided there you can actually trust it because it will be uh validated with the with the the validity proofs so that's kind of like the the easy way to do it and also like the most scalable scalable way to do it but it does require on these real time

proofs or like close to real time proofs and so that's kind of like where some of the well some of the challenges I guess come come in where currently the things that are available to do real time proving is kind these Dees X whatever uh and also kind of like ABS Solutions where you simply have like all the people running notes and then creating like a signature that the state is actually correct uh but yeah we are like a ZK roll up so ideally obviously we believe that the ZK proofs are like the best proofs to actually verify this these things uh but for now they actually cannot be used yet to to generate these fast proofs well to to generate these proofs like fast enough um so that's kind of like the thing that

currently is not available but that we see as being available like pretty soon there's like multiple people making some estimates there like when this will be available but let's say like roughly a year from now it will probably be possible to also actually generate ZK proofs uh fast enough to also yeah generate like real time proving or like close to real time proving oh Brock I'll go over the proof part later let's go to the next slide for now okay okay so we have this syn composability down we have like a shared liquidity like a bridge uh so you don't have to touch that one if you don't have to um so pretty good solution still not like ideal because if you kind of like want to increase skillability then you

have to deploy like multiple l2s and these multiple l2s would basically be like yeah basically like clean slates you don't have any any existing States if you want to do something on it then you have to redeploy like small context and all this kind stuff uh so that's kind of like where the kind like the booster roll up function will come in where you don't always have to like start from scratch if you actually deploy like a new rollup you basically inherit all the state from the L1 and users can directly use that new rollup to do all these kind functionality and so you don't have to yeah recreate like ecosystem all the time so that's on that note um what's the latest on the booster like is there is gwth a or gwth a booster roll up from like Tao itself

like or is is that what you guys are calling a boost a base boosted roll up is that what gwth is technically or no not complet question but I think yes as in the will be like a well used booster roll up functionality or like will have it and also like combined with the base R up yeah well I guess the name booster is just bra just came up with that out of the yeah I remember that saying of our last okay okay so so so this is how the the booster design works here for yeah yeah exactly so kind the new thing here is that compared to last time is you don't have to deploy like all the

smart contacts on one because that would be kind of like inefficient for certain use cases so that's why some some extra like smart contracts on the L2 site because for example if you for a user if you want to have like a smart wallet then you don't want to deploy that smart wallet to the L1 even though it has like like benefits of doing that it would be like very expensive to kind like force users to do this if they actually want something like a specifically for for themselves and they are not really interested in having their functionality available on all the all the booster rollups um so yeah it will be possible to just deploy a specific contract as well on like a single al2 and then you can just do all your transactions directly to all al2s like normal but yeah for generalized applications like

if you want to have like a token SM token contract or you have like a real application like Unis swap or whatever you would just still deploy it on the L1 because then you automatically scale your application across all the all the AL um yeah so well I guess I already like said it but yeah so this system makes it possible to easily add more scalability to the system so you don't have to perect stuff from crutch but yeah horizontal scaling to the max it's almost like sh so many of these Roll Up designs that I see these app chains and l2s and like this expansion of them there's going to be so many and like iir rollups and all these different types like I I just always come back to being like damn it we we we had the right idea

with sharding we just didn't realize that it was not going to be sharting the L1 it was going to be expanding horizontally by adding new state in the form of rollups you know yeah yeah yeah yeah it's shy except in this case you do have like a shared kind of like storage room and in in the form of like the L1 and so being able to just not have like all the stage started but like having like this kind of like all right like very well but all the interesting data is mostly still on that one uh so having that available next to conflict your own storage yeah I think it's kind a think the thing that makes a lot of sense okay so I will go over like the details of what we actually mean because I feel like bra's explanation kind of

goes everywhere so like um let's start with like the semantics of cross chain read and right so currently on the left hand side you see this Marco proof is basically how we uh read the L1 state or L2 State on these days right today right um if we want to approve to a chain where Alice has like $10 in uh in L1 or Alice honestly deposit $10 in the bridge contract we we provide the sple proof and that is like super asynchronous that's like not synchronous composability at all but like by saying that we add te or ZK proof to the Paradigm it literally just means that like we run the the whole execution of L1 or L2 um of this like brid smart

contract on a node that has te or ZK support right so by the time where the execution is done where Alice has deposit $10 uh in the bridge contracts we would have generated a real time proof um to the Target chain so that basically what we're doing is to prove the Integrity of Alice's deposit so that she can Min on L2 um so the purpose of both side of the diagrams are the same it's just that currently um the proof is being being offered as a miracle proof which is also asynchronous like the proof is being supplied at the road up time um but now what we're trying to do is run everything within the same

execution uh process so that like the proofs is being seen in real time where you know like a a two a L1 and L to know that are being run side by side can just like synchronously uh compos with each other yeah so this is for a read this is for a cross Ching reading for cross Ching writing on the other hand so let's say we have a uh unit swap Deploy on Layer Two currently what people are doing is at the road up operation where you update the road up State what you're actually updating is the state that are derived from the the state route of the road up so let's say this your your

smart contract is on arbitrum and when arbitrum roll up to L1 the state rut gets updated so implicitly it's still it also update the unit swap pool status um on arbitrum through you know a state right to to layer one um arbiton State Route however what we're trying to do right now on the right hand side is is that when we are executing L2 transaction which encapsulate a L1 call to the L1 arbitrum smart contract we will rad up the execution result of that call directly on L1 so by saying that we solve fragment fragmented liquidity is

the fact that you actually only have one unit swap there's no like two two unit swap on L1 and L2 there's only one unit swap exist existing on L1 and then you kind of just directly modify the state uh via a delegate call like a direct call to the arit to the usw contract as long as it inherit the booster Road up interface um so yeah um and the uh the call that are being initiated from L2 is is like uh sort of enumerated at L2 execution in advance and then by carrying out this enumeration on a te or

some other like real time proving solution you also like generate the proof for that so when you roll that up to L1 and your L1 smart contract execute the delegated call to the to the real Unis swap contract the proof is also being verified so this is what we mean by actual synchronous composability and cly if I have uh like Unis swap instance on arbitrum optimism and base yeah then all of those end up getting aggregated be when they get when they get put when they change the state on the L1 and that's how the liquidity is is synchronous and it's composable

across those three environments because you end up aggregating it when you change the L1 State uh yes so like you can still have your swap separately deploying on all of these chains right it's just is a implementation Choice like un can be like I only want one instance of my contract being deployed on the main chain and then this this uh contract inherit the booster Road up interface where you know for any subchain that carry out the execution of the Euros swap smart contract with a proof um can you know modify the state of the L1 unit

swap contract Direct as long as the proofs are verified so you're basically using L2 block space to execute L1 logic and updating the L1 end result at Road up time and then yeah and then the L1 is like a proof aggregator um I would think that as the proof verifier right or but then the proofs can be aggregated at the same time right if you have that many proofs um basically each there's still like Pro details uh regarding the block building so you you have to have like exclusive like right lock on the contract St of unit Swap and that would be like implementation details that we may or

may not have ch have time to go over so hopefully yeah go ahead it's also important that you don't have to T the one state if you don't have to R so if you don't want it so it's kind like up to the application to decide like how how it's more most efficient to come like split up the state so you can have like a un SW pool on the L2 and you can actually write the state there directly it would just be not directly shared between all the all the all L2 and on that's cool we'll uh we'll try to stop interrupting you guys so that we can get to the block building part sure sure uh so Brax is gonna go over this simple example okay people are interested in

blog building for some reason okay so I keep it short so the so we had this kind like an easy kind of example like like how this actually would work so for example if the user has like a smart wallet on on the a then this could contain like all the social recovery State there uh but then yeah this would just be like data there and then on L2 you would actually execute like a like a smart Wallet transaction this would be able to check like all the data that's on L1 to be able to say like okay I need like these two addresses to sign stuff and you would just be able to call like the L1 contract to kind of verify which signatures are required and then the smart wallet on on like the left L2 would also be able to directly just call

the the amm smart contract on on on on the other L2 so for the user it's kind of like very seamless there would be like only one transaction just to call the call into his own smart wallet it would automatically check the data on that one it would automatically call the other smart contact on the2 and then these tokens transfers will just happen as they make sense so this token smart contact would also be like deployed on the L1 which made the token smart contct available on all the l2s and then depending on where the balance is for the user it could be on the same chain as the the smart wallet it could also be on other chain it doesn't really matter uh it just fetches the correct balance from like the the chain that that that is storing the

funds swaps them on this amm smart contract so at that point those two tokens do need to be on on this specific uh chain but then afterwards again you can just transfer the tokens to whatever chain L2 that you want so that's kind like very easy for the user simple transaction as they are used to uh just like internally it it does like multiple cross chain things um let let's skip over the contracts because there is some some code there uh and then yeah shortly like what what I block block Loop Ty so like there would be like each L2 would be its own P but there would be like a single like transaction list containing all the different uh transactions on all the different like l2s so it's up to the

Builder to kind of like decide which transactions make sense and also which transaction he can actually build because if he want if a builder wants to create the like execute a transaction that touches multiple chains then the build doesn't need to have like all the state for these chains that are being touched um so depending on kind of like which things are like the most popular or have like the most value builds want to like pick and match which one they actually want to sync that and so that they will be able to ex execute transactions that touch all of those chains so yeah it's kind of up to builders to kind of like make sure this synchronous composability actually works in practice because they do have to sync the multiple change and then yeah the build builds a block this build this

kind of like super block is proven like in a single go so only like one proof required to to be able to prove yeah any kind of like all the all the different L2 transactions and then yeah it should should just work except that there's kind of like a d dos risk as in like the Builder like if you do like a transaction and this trans action can touch like lots of like different chains uh so the bill kind like has to know for a transaction which chains will be touched otherwise he might start executing a transaction and then see like okay I actually don't have like the the necessary state to to execute this transaction so that's why the the transaction format will also have to include like a list of all the chains that will be touched and if the user kind of like is wrong then the gas will

still be used and the the transaction will simp all right so we're we're looking at some uh block building process more in depth talking about got some MV here um right let's go yeah so like let's start from like how does the M and PBS Paradigm work nowadays on L1 so um obviously we have this Builder which has a lot of transaction in the men poool and the Builder will just pick whatever transaction that are profitable to form profitable to form a block and submit this entire block through the PBS pipeline which you have a validator and all that stuff blah blah blah um and the Builder gets revenue from MV plus tip right but what about if we add

the base stuff in the in the Paradigm so we'll have um L1 Builder which is also a base L2 Builder uh because that's the definition of base Ro up your L1 L2 sequencer is also L1 sequencer right L1 validator so in this case then um the Builder's transaction pool the men pool within the database will also have the access to L2 State and and also the L2 meno itself you have a L2 RPC endpoint right um and in this case the Builder will just directly build the L2 blocks you see this pink block over here and this pink block is being built is in the exact same way as L1 blocks because you

you still receive mbv plus tip or if your if your L2 Works differently you might have other L2 fee uh accounting mechanism but um but the whole L2 block is being packed in a road do operation right like when you have like rad up transaction proposal every every all of the the entire batch is being is being batch in like a blob in a transaction with 444 blob or something so this is how you WR wrote it up nowadays and it actually works very nicely in a base sequencing uh mechanism um yeah so just briefly here um so I understand how uh let's say you have multiple base rollups

app chains are just enter sort of you know base rollup L2 they can settle atomically in the same L1 block because of the way that the sequencing happens and that can allow them to have uh you know basically like they can they can read each other's State and have really well like really fluid cross domain interactions for asset transfers and messaging and things but like you're giving away all of the transaction ordering or at least from my understand you're giving away transaction ordering and Sovereign sequencing as a form of Revenue back to your sequencer and giving that to ethereum L1 validators and that doesn't seem like a

great business model for app Builders who want to acrew revenue for their block space demand that they have for their chain how are you guys thinking about this yeah I totally see your argument but actually it doesn't have to be that way right that's why I leave it open for the L2 sequencing protocol without specifying okay this is like a absolute uh Anarchy that you can do anything it's actually not the case like we can literally sell execution ticket on Layer Two right if you're a sovereign app where you have blocks block space that are that are profit you as a protocol can sell execution

ticket to random block Builder that wants to build your block and we can also uh receive revenue from 1559 Bas fee because as you know like people modify the fee accounting on ethereum all the time and you can also do that on L too in any sort of manner that you want such that you you you capture back some of the base feed that are about to burn right and in fact that is how Tao work currently um that we literally all of the base fee generated from Tao uh congestion is being transferred to our to our treasury um so yeah yeah so cool you don't have to give up all of the

revenue understood that's a good that's that's good to know is like as far as like the Spectrum goes I think a lot of people see things binary sometimes in technical designs but it's often not um the other thing with specifically with uh Gwyneth and Tao's kind of booster designs with regards to the horizontal scalability um it seems like the design works better as more booster rollups come onto the system because then you get this kind of expansion of composability across different chains with the same sequencing happening and like you can get a lot more scale like all I'm saying is like if there's three booster rollups it's like okay great we

can atomically compose amongst three different applications or ecosystems but it was like 3,000 then it's like oh like this is a big problem right now in any sort of evm uh centralized sequencer or even like in a proposed decentralized sequencer manner um there's incentive issues and all these things so like it really does seem like this design scales the value in people's eyes I think will scale exponentially as the chains adopting the sequencing method uh grows so I just wanted to also make that point and see kind of if you guys agree which I assume that you do birex Edge is now live on say Network say users can now trade 50 plus spot and

per markets with the unified order book liquidity of vertex Edge across arbitrum blast mantle and SE the next 6 weeks 850,000 SE tokens will be up for grabs as trading rewards every single week exclusively on say join vertex on say Network now on vertex Edge that's vertex protocol.com coent is solving the longterm data availability problem where a lot of the data availability providers today in the Moder space when you post data to them they actually only hold that data for about 12 to 16 days and then it's basically they can go into

archive note or often times it's just kind of put away into the abyss and what coent is trying to do is build this long-term data availability solution which can plug into some of these modular data availability providers and provide this longer term Perpetual data solution so what we try to think of this as is when you post transaction data onto Celestial or Vil or any of these mod da Solutions or even ethereum coal is able to provide a longterm data storage and data availability platform for that data after the time period blockchains are built boards not databases and you know we need these providers in the space to be able to kind of hold on to the longterm data that is provided from these providers

and these blockchain State this is where coent comes in they just had a nice Rebrand check them out on Twitter as well as the website thank you for being here hope you enjoy the rest of the show I I was about to touch on that cuz I have many slides but sorry I'm GNA stop here but it's okay but literally what you just mentioned is literally this situation that we're talking that I will be touching on so I'll just jump ahead um so if we imagine we have like multiple layer twos right we have this like pink Layer Two and the blue Layer Two where the Builder um choose to to be the sequencer of both of these Layer Two actually the the Paradigm still work

right because you basically do the same thing for the other layer too where um your the the trans actually the different chain can actually synchronously compose compose with each other because like they're they're basically in the same men poool right and if we have like Atomic transaction where you know like a bundle can goes across the pink layer to the blue layer to and the gray layer one um they can like literally be uh packaged with each other through you know the uh um the building Paradigm that we're going to introduce um yeah so like if so and also like different protocol the protocol design is still like open for for

different layer too right we can have the the pink layer to selling execution ticket and we can also have the blue layer to having a you know deterministic look ahead through AWS um so this system is like totally flexible you can do whatever as long as the states are available for the Builder to build and the Builder can also um choose to exclude um the layer to that he doesn't want to sequence for like the Builder can just say like I only have access to the pink Layer Two or I don't want the blue Layer Two or I just want to sensor the blue Layer Two whatever right you as long as you have the right RPC endpoint and you have the access to the menol the

order flows whatever you can build for whatever you want and I think this really introduced like a new meev um me me V Market where Builder can really do like cross chain Atomic mbv in this Paradigm um yeah yeah just want to also mention that like we do have to be careful about like adding like extra barriers to come like be able to synchronously compose between the L2 because yeah that's kind of like the main the main selling point is that it should be like easy and it should be like just like work out of the box so if we have like multiple kind like uh leader selections or like multiple like execution tickets for like the different l2s then it's great for Value capture but we have to be be also like be aware

that this could actually increase like barriers and build becoming like a builder and also like decreasing like the chance that if you do like a cross-chain transaction that will be picked up by a builder that actually has the correct access rights to to these different chains U so yeah there's like a an interesting kind of like balance going on there which you can well you probably can go like max value capture because you still want to have like the good user experience as well right so we're talking about like BND and M I would just jump ahead to like here right like a example of like how these um cross chain bundle will actually be executed would be something like this where you have like for example a user will want to bridge uh E from L1 to L2

and swap on L2 and then Bridge it back to L1 and let's say these are all Atomic they're supposed to execute together right so like within the Builder's database like uh he will like virtually see the bundles together and then um at the road up point right he will have to like um like he would have to roll up the transaction into L1 block with like this the first transaction being on L1 and the second transaction on L2 the third transaction on L1 again um and then he and oh yeah and this kind of like this implied that the Builder has to have exclusive sequencing right of the one block and the L2 block because like the

the order have to be preserved um this is where pre-confirmation comes into place right if the Builder doesn't have the right through pre-confirmation if there's isn't like a preon pre-confirmation provider that let the Builder to execute to to become like a to guarantee the Builder for execution preon then this thing wouldn't be possible that's why pre-confirmation is also Al very very important for us um however though like if you only care about like L2 order like if the the transaction itself doesn't doesn't doesn't go through L1 in a strictly orderly manner then you don't have to

have execution pre-confirmation like inclusion pre-confirmation will be enough if you if you just want to roll up the state of L2 however if you want to introduce any synchronously compul any composability actually from L1 to L2 the fact that like the L2 execution depends on certain state of L1 then you you do you do need like execution pre-confirmation yeah so that's that um and in fact if we if we want to go into like more detail into how these transaction are formatted so this is our design right um I like bundle these three transaction like this because it's like easy for people to understand but

in fact fact for a user you only need to like send one transaction that are being packed like a onions that look like this so a the user since this transaction is originated from L1 right because you bridge from L1 to L2 right um the outer skin of this onion will be like a L1 transaction in which the inner transaction will be encapsulated as you know call data and and being picked up by the by the L2 L2 process within the you know the base Builder Big nodes the node that sequence for both L1 and L2 right after the L1 is being processed from the L1 um from the L1 execution like it will like call the L2 node right

and since the inner inner parts of the onions and the L2 no get executed which encapsulate another L1 call within itself that are being emulated in the L2 evm right so at the road up time where we have to like roll up the the end state to the L1 will actually it actually contains like two process right like the L2 thing the L the L2 the pink layer will actually be rolled down in the L2 execution context but um the L1 processes will be rolled up right to as the end state of the L1 and everything

has to be carried out in Te or ZK because you can just like insert Miracle proof randomly in these processes right like if everything is directly proven in real time um like the execution Integrity is guaranteed then you can basically like roll up and roll down freely at any time in however way that you want to compose your transaction yeah yeah so this is and it's like embedded right like we have transactions that are embedded into one another my question here is like like you know everyone who's around and like using like a and Unis Swap and compound and like the popular applications you know they had liquidity on L1 but now everyone has migrated their liquidity

and their assets and they're doing things on L2 it sounds like here you know l2s are still used for execution but it's almost like we're going to like bridge to the L2 we're going to do some execution and then we're going to come back to the L1 do you think people are going to migrate liquidity back to L1 and then start to like use like L1 and make transactions and hold their their assets on L1 and then use this to like make transactions on L2 and then get it back on L1 or now that all the liquidi away from L1 you think it's just going to stay on l2s um I think that's a good question because like I said right we're using L2

block space as a execution layer of L1 so like L2 is literally a execution extension of L1 and honestly since L1 has the max maximum amount of those security guarantee so it kind of makes sense to keep your assets on L1 right and just leverage because like by the end of the day all these L2 nodes are just uh extra execution power like execution capacity that you add on to like the base chain like the base L1 chain right um so I think like after this this ecosystem being picked up maybe you will see more people migrating their assets back to L1 and only use L2

as as you know a execution layer and then the L2 Builder will will get revenue from like processing your your your execution yeah so I think it's also like like depending on like well kind like like your priorities right so if you are like very like security uh sensitive or you have like very well you have like a lot of like funds on on the L one then you do start carrying more like okay where is kind like the most liquidity where do I actually have like the least like slippage on like the swap that I want to do and then it makes sense to kind of like pay the extra cost to still have your funds on the L1 or like partially on L2 or whatever you want to kind of like do and then pay this extra

cost to to have this uh but for normal users that are like very cost sensitive and you want to just swap like $100 or whatever uh then yeah you do want to store your funds on on the L2 as well and then you kind of like have the benefit of like if the liquidity on the L1 is still much higher than on the L2 that you're on or like another L2 then you can still kind of like kind of like combine all these transaction in one do like a single Swap on the on the L1 and then get your your funds back on L2 with like the minimal slippage so it opens up like a more like a design space of like like different options and it's kind of like up to you kind of like what option do you want also kind of like on the

application level how can I scale my application because yeah if you do still have your funds on the L1 or the application kind of like state is stored on that one you do end up paying like a higher cost right so you will pay like a very kind of like well expensive like ass store cost to actually store data there or kind of like move funds between the L2 and on the L1 smart contract so yeah you you pay a cost so it needs to be worthwhile to actually pay this cost and it depends on yeah whatever the users kind of like priorities and like the apps priorities got it Cecilia what what else yeah go please go ahead oh I was going to go for the next slide but if you have any question we can like

answer no no I my question was like if there was if there was more slides and like what else you know are like some observations and consequences of of this design right um so this is like more details of the design where if like a uh a transaction is being initiated by L2 we we can still like pack it up as like one transaction but uh in this case like we'll have like one transaction follow the other transaction but still like encapsulate the L1 transaction that are in the middle so like it's all about emulating L1 transaction while you're executing on L2 and then prove it later on and then like the L2 sequencer we

we'll see like the pink transactions separately on Layer Two um yeah so these are the details I guess uh and oh yeah I think this is very important like if we evolve um how we did from L1 and L2 to like cross chain transaction um we can do the same thing from like for example um you know chain a and chain B right um and I think braat can go over this it's like more like I think like there's like details about uh on Layer Two only that are different from L1 to L2 um yeah PR oh um yeah well I guess it's kind of like a I think it's still pretty similar to the L1 but yeah so kind of like if

you do just like a a transaction between the l2s then basically you still have like a single transaction and you would just directly call in the in the other L2 as well uh but yeah the difference here is maybe that okay there are kind of like these sub transactions that have to be well both validated by the approver but also kind of like to split up the state between those two l2s you kind have to have like this subtransaction that like the blue rollup actually has to execute and then the pink stuff is actually being executed only by by the the the the pink roll up uh so yeah it's kind of like more of like a scalability kind of like uh kind of like a implementation detail where yeah for for everybody they only

actually care about like the one transaction also from from the Builder perspective but we do still to have like split them up just to make it possible to sync the specific notes uh separately so there's like no kind of like interdependency even for cross chain transactions right so for and also at from a block building standpoint um if a builder sees this like pink Layer Two has a lot of traction right I can choose to sequence for um the pink Layer Two well in this case um it should still have the access to the state of the blue layer too is that true BR for the yeah yeah right so like if

you do want to maximize value capture from sequencing multiple Layer Two um you will have to like uh obtain as much State access as possible um and then I think like the building the blob building algorithm you know how people like build blob differently like rsync or like a beaver build or Titan they all have like different tactics and and block building right and in this case like all these all their tactics will be renewed right it will be very interesting how the block building space will evolve with this situation in this model are all of these based rollups the pink and the blue are

both based yes okay and so they use the same sequencer and which is the the L1 validators and so wouldn't the uh wouldn't the L1 validators have wouldn't the sequencer have access to the entire state of the pink and the blue or not necessarily so they would see all the transaction being posted for these l2s but they don't necessarily keep the actual like L2 State derived from those transactions themselves uh well I guess the L1 validator is like probably not doing anything any case yeah it's kind of like whoever kind of like gets the right to actually build the block for the L1 yeah would have to get the yeah

sync the state they would have to get the state for both of these rollups yeah yeah yeah so so yeah onchange so what the L1 actually only sees most of the time especially for like the L1 case it's only like like data right so they only see like data and so to be able to get the state that you actually need to execute transactions for on L2 you actually have to take that data and like execute on your L2 Noe um so and that kind like a lot of work because now especially with data blops yeah the the blop data you can like put a lot of data there the L1 Val don't have to actually do a lot of stuff with it and just have to propagate the data they don't have to actually like a compute stuff with it uh and so that's the difference so if you

actually want to sync an L2 node you actually have to take that data and actually execute on top of it so there's a different in like syncing the L2 node uh uh in between like syncing the l2o and just like validating out of the the blocks right like for for L1 is still the same like the L1 validator still only sees this block which is being proposed through the regular PBS right it's just like the stuff that the pink and blue transaction here is it will just like it would just show appears as like a regular Road up transaction right and then a pig Builder or like a blue Builder or blue or pink note that are specific to the chain will actually see

this pink and blue block and execute these blocks locally right so like for L1 the pink part and the blue parts are agnostic um so it doesn't add any execution overhead for L1 validator or or a builder that only want to builds for the L1 right you can basically just ignore the other things it's just it's totally optional for like these like pink or blue Builders to like to to build the whole thing and it's also very like uh optional for like a a pink Builder that want to exclude the blue blue transaction then like the pink Builder will would just only build like this single transaction over here right

because this this bundles also contains the blue which means you also require the blue State um right yeah so it's totally open and and you know competitive in that case in that sense right because these Builders are opting in to the the blue or the pink or the blue and the pink yes okay and so I guess to finish off like this podcast which has been absolutely phenomenal I want to ask a really really dumb question which I think I know the answer but maybe it'll help just to like kind of like revisit the basics can you guys like what is the difference between a builder and a sequencer welcome aboard on our journey into the singularity this is the endgame

road map for fra and FRA the new L2 out of the fra ecosystem that is totally based on fractal scaling fractal is a modular L2 blockchain built by fracks with modular and fractal scaling in mind fractal scaling is based on the mandal BR set of fractal images and it explains how l2s become l3s and the entire app chain life cycle goes through its Evolution the fra ecosystem is made of of the top builders in the space and has stemmed from its OG days of the frax stable coin it is now in the LST space

the LRT space and this frax L2 joins the existing Suite of fra products including fra Swap and fra lend you can see fra fairy the bridge to go from any chain arbitrum optimism or main net into the fra Main main net Bridge your tokens and bring your FRA assets into the fraxel ecosystem join today to get the best out of fraxel you are still early join today take part in our Expedition into the singularity Everclear is pioneering the clearing layer the clearing layer can almost be thought of as splitwise when

you go on a trip with friends but for the blockchain what I mean by that is when users are sending cross chain messages is there's often times fillers and solvers who have balances left on different chains that they need to rebalance and reset their positions this is where evercar comes in evercar is pioneering a collaborative approach to the chain abstraction future and they are willing to work with interoperability Partners solvers and other providers in the space to build a interoperable and cheer abstraction future check out Everclear ever clear.org and welcome back to the L up okay definitions game uh so sequencing I guess only the the determines the order

of the transactions and I guess the Builder would actually build a block out of it I think that's kind of like how I would Define them but I am sure people will disagree or like have other definitions on them H but yeah guess okay okay so so yeah yeah so now like the trend is to modularize sequencing and block building or specifically data posting for Road up right like for example uh we just got to know from like paradigm's fromom tier event how like uh optimism is doing their Road up and their um you know uh the ZK fraud proof thing so like their their stack is actually super modular right you have like a share sequencer

that just response only responsible for like sequencing the the order of transaction that like the data even the data availability doesn't really matter you just need to you literally need to just like label the sequence that's it um and then like they post the The Da later on when when you know there's like enough enough transaction to to f up a blob because they compress their blob very tightly to save cost right so and then like in order to execute uh a optimism State you actually need all of the data availability so that that's when the Builder comes in to build a block building the block meaning

execute out of a transaction but sequencing literally just mean you know you have a bunch of transaction you actually don't care what is the result um you just sequence them randomly but like as a as a builder no as a note that actually want to profit from sequencing the transaction you do want to actually build the block meaning execute the block to see how much money you will earn um so that's building and sequency got it got it okay so in in terms of this this pink and the blue would it be fair to say that uh like the the the sequencer is almost like in

the pink and the blue they're kind of the same thing like they're the ones that are like embedding the rollups embedding the transactions in this in this bubble and then the sequencer kind of like sequences the the one the two the three and then the Builder is the one the container on the left that says okay now we have these three transactions in sequence we're going to go set we're going to process these transactions on the L1 and build build the L1 block made up out of these transactions um not exactly because because um the user send these transaction as a whole as a whole or in this case a snowman right like the whole

thing will be like so for the it it wouldn't make sense for a user to split up like three different transaction and and make a you know sandwich or whatever s and send it to the Builder like because we want to we want to have like a good ux right the user should just be able to like specify intent or whatever that basically does these three things and then and then like the the ux will will package some ask you know like encapsulated transaction and send it to like and put it in the public man poool um and the Builder will see like Okay so this transaction will require me to have the pink State and the blue State and okay and I only have the pink state so

I'm probably not supposed to touch this transaction I should probably leave it to someone else a different build that has access to both the state exactly exactly and that also means that I probably not I'm probably not profiting from this transaction right but go ahead well can can two Builders coordinate with one another like if I have the pink State you have the blue State you know can we build this block together uh I mean by seeing C coordination if I want to have the state access to the Blue State then I I I'll probably need the database to be you know to be already there available for me that basically just mean I do have the blue State you know what I mean so

like you can't just like sand people your entire database um for some other Road up because it doesn't work like that okay well you can you could send like the data that's being touched but yeah I guess the the cost you pay then is latency so it would like well depending on the latency between those two Builders uh it could be feasible or not but yeah it would slow down the block building process like substantially so if you comp like want to optimize uh kind like yeah do like lots of like different variations of the block this could be not ideal but if you do something like pre confirmations but like first in first out then like yeah the yeah you just yeah the ordering is kind of like simple so you just uh do the transactions as they come in so then

the extra latency could be acceptable uh except that you also can like uh enlarge kind of like the time until the pre-confirmation can also be returned uh but yeah it is possible it just depends on like what's kind of like your the latency kind of like tolerance and and kind of like your blog building process yeah cuz like in a developer standpoint like having the state literally means having a active in memory DB in memory BD for like a chain right so if you don't have a BD uh process running on your laptop that basically means you don't have the state you can ask for people uh ask for other people for like the miracle proof

of some random state but that's like not how you would run your software yeah and I guess from a user perspective like I I'm not going to know if there's a builder out there that has access to both the states that I'm looking to transact on and yeah and so so like does that does that prohibit like certain transaction types or they would just it would just kind of like Get Higher latency as a result of the block Builders having to having to like finalize on one chain and then going and asynchronously on another chain well not really because you as a user you just like you just throw your transaction in the men pool in the public men pool and hope for the best

right if you're touching a chain that is like super unpopular no one picks you up right and you just have to right and it it's like the same same scenario for for the L1 this uh today right if you if you're through throwing a transaction in the M pool that has like no tip and cons a lot of gas you probably can't hope for the you won't get executed especially not quick yeah and uh I guess because yeah if you have like funds on like one of these unpopular chains then it would be bad right because that would mean like your FS could be like stuck on this kind like very unpopular Ro so that's why

it's also like important that we still like based so if nobody actually wants to move your funds out then in the worst case scenario you can just do it yourself you can propose you block yourself and and and still recover FS w got it okay very cool I mean so so yeah it's kind of like a service like block build is kind service that these build kind provide you and the rest case scenario you you do it yourself right right and and and for the large like the subset of chains that have a large amount of liquidity it makes sense that these block Builders are going to have access to the state for for the for these prominent chains but once you start getting exotic about the different types of chains that you're going and interacting with you can't really make the assumption that block Builders have

access to all of that state and so they might not pick up these these transactions um but for all of the rollups that do have a large amount of liquidity block Builders have access to the state then we can we can make a pretty safe assumption that if I'm doing a cross rollup transaction amongst these rollups then I'm going to be able to execute kind of like this onion type of transaction bundle across those rollups because Builders have like one Builder has access to the state of all those rollups yeah and it's also not it's not that is like very expensive to actually sync a note right so that's kind of like the thing these these notes should

actually be like pretty normal ethereum kind of like scalability level so you can just run them like pretty stand hard Hardware so um yeah yeah it's not a big extra cost for builds to actually syn like a lot of the got it right got it and like everything will be like incentivized right like user will be incentivized to move to a more prominent chain and the chain will be incentivized to become more prominent so that more builder are willing to build for them but also however a caveat would be if a chain becomes too congested right you have base fee spiking up then it's also like incentivizing people to move off from your chain um due to congestion so

like it is like a very very Dynamic scaling solution I would say it's a big game of hot potato yes yes awesome I yeah I really appreciate you guys sticking around past the uh past the time and uh and and really going deep into this into this design I think this is something that you know we're we're big proponents of Base rollups I think uh to see this play out is going to be fascinating So yeah thank you for taking the time to explain it GL to do it thank thanks for having us awesome do you all have any closing thoughts like that you want to share that you feel like maybe we didn't cover or anything else that you want you want

to say I basically said everything I wanted to say like I'm just like super excited to see like this ecosystem being built like how everything will unroll theel especially with the builders right because like people are talking about muv all the time and then it's a very sexy idea to like to like uh revenue from people transaction bundling sandwich and all that stuff and we really if this kick kicks off like it really unbundles like a new model for like how do you revenue on chain and how like app Chains would play out um on those things yeah yeah also I guess like yeah there is some some challenges well

some sexy and unsexy challenges because the system kind like can't great but I guess there's some some kind of like a yeah some some not unsolved problem with unclear kind of like how things will actually work out so obviously like yeah the fast kind of like finality that we need the real time proving the security kind of like considerations about that we have like some plans to do that but uh yeah I guess there's some some implementation details that I pretty pretty important to actually make the to make sure that the system actually works also kind of like yeah the synchronous composability with the L1 is kind of like tricky thing to do so it might not always be a but I think like as things progress and these things actually kind of like pick up then we should be able to actually synchronize the compos with the L1 most

of the blocks uh and I guess yeah what one of the main benefits there that might be like not so sexy is kind of like just the the Simplicity of things and so you can say like okay when will this kind of like synchronous composability with the L1 be used this kind of like limited maybe use cases depending on the application but still having like an in protocol kind of like solution for this that is Al like uniform across kind of like all the different chains that you want to access I think it's kind of like a very important thing to keep both the security high and kind like the Simplicity uh like also like very high for users so they don't have to really care about like which chain they're like accessing and they also don't have to care too much about like the specific

implementations of kind like bridging between L1 L2 these different l2s because the functionality is directly implemented and the in the L2 kind of like system itself so I think that's also kind of like a big benefit of doing things like this because now yeah you have like Bridge smart contracts which have pretty complicated code to actually make this bridging possible we kind of like just make like a very kind of like a generalized solution we build it into a note and then application can just depend on there yeah and this is solving the fragmentation problem at a very very based level um which hopefully you know fixes uh kind of like the interoperability and fragmentation um and then standardizes it so that everyone can build on top without having to really worry about fragmentation

going forward yep in the best case scenario that's what we're aiming for cool awesome guys thank you so much for coming on and uh yeah very much looking forward to doing uh doing this again soon yep thanks L thank you bye bye bye