A Masterclass in Based Rollups w/ Jason Vranek (Fabric)

Rex (00:01.92) Jason, welcome to the Signaling Theory Podcast. Jason Vranek (00:04.834) Hey Rex, yeah thanks for having me. Rex (00:06.654) Of course, man. So before we get started, can you just give a really brief introduction to who you are and what you're working on? Jason Vranek (00:12.824) Yeah, my name is Jason. I'm working as part of the Fabric team and not to be confused with the like hardware Fabric. We're focused on based rollups, pre-comps, all of that. it's Fabric is a effort that's like a nonprofit under the CommitBoost. Rex (00:29.716) Awesome, cool. So I think the best place to get started this conversation is let's really just talk through what a base rollup is. We'll take for table stakes that anyone listening to this show already understands the concept of rollups. But can you just give us a foundation of, especially compared to something as basic and centralized and kind of table stakes as something like base or Arbitrum or Linnea, what is a base roll-up and why are they different than the technology that we have and take for granted today? Jason Vranek (01:10.52) Right, so it's kind of an interesting story. Like if you go back years ago, the original rollups were actually based rollups. The idea was like, we want to do like, we want scaling, like that's kind of the point of these rollups. And the question was like, how do we sequence them? And a based rollup is just saying like, there's no dedicated sequencer. And the one that naturally fits that role would be Ethereum validators. And in contrast, you have like base today is run by a single entity. And that's actually like a huge UX improvement. It's like a lot more low latency efficient things like that, which is why they shifted from this kind of anarchy mode of like anyone can sequence the rollup into like we have this dedicated party that can specialize. And because it's a rollup and we're leveraging Ethereum security, that's like, can accept that trust assumption as long as we build in things like. forced inclusion, these safety mechanisms. But yeah, based rollups are kind of this returning to the past, like how can we decentralize the sequencer? And I think like another part about that is like, what do you unlock? Like there's liveness, like if we decentralize something, like we're trying to help with improving liveness and robustness. But I think a lot of the sort of past two years, like the resurgence of based rollups was around composability. This is like connecting rollups back to Ethereum. Rex (02:42.294) Cool. So, you know, I think everyone kind of, if you've come across the base rollup concept, you hear this like, okay, we are going to create rollups, but we're going to use the Ethereum node network as the sequencer. And I think if you're deep, deep enough in the weeds, that means something if you are kind of like barely understand the technology, it doesn't. But I think even if you, are you understand how blockchain works, but you don't understand how these are being built. Personally, I think the concept is still a little confusing, right? Because the core concept of what we were doing with Ethereum and with the L2-centric roadmap was like the most important thing is we want to ensure that the Ethereum network stays decentralized. And the The most important thing to enable that is to ensure that nodes stay super lightweight and they can run on a Raspberry Pi, right? Like in Africa, something like that. And when you say like, okay, we are gonna use the Ethereum node network in order to SQLize rollups and we're gonna be able to get properties like execution and speed and UX at similar levels as something like base. I think it's tough to understand how you can maintain that decentralization, maintain these low node requirements, but still get what we're getting through something like base, which to most people's understandings happens because it's super centralized and the hardware requirements are super strong. So can you help pick apart that and help us understand what it means to have a base roll up that's using the Ethereum network for this high throughput? high bandwidth compute, isn't making a fundamental compromise that makes Ethereum less decentralized. quite frankly, the risk would be that it looks more and more like Solana or hell even just financial applications on AWS. Jason Vranek (04:53.41) Great. Okay. Yeah, that's a great point. And it's worth also taking a step back and maybe I butchered it last time, but like what we really are talking about with based rollups is purely on the sequencing front. So in general, like you have your like base is a rollup and there's some leader election mechanism. And that's kind of like maybe the Coinbase shareholders decide or board decides who the sequencer is. But If you start to generalize that there's like some kind of election process on like, how do we decide who has the ability to sequence the roll up on Ethereum? Like we do that today through consensus, like a validator is chosen to propose a block. So same thing applies on, on roll ups for a base roll up. We're just making this choice instead of like designing our own leader election mechanism. Let's just use the one that Ethereum already has and say. If a validator is chosen to propose the L1 block, they also get this other like monopoly rights to sequence this based rollup. And so if we stopped there, that would be like base sequencing and based rollups in general. Then we start to wanna like classify on like the kind of like refining maybe this election mechanism. So the default one that most people might be familiar with was Tycho's original design. So Tycho did total anarchy mode, which was saying like, we're not even forcing or not like forcing it to be just L1 proposers that sequence Tycho. It's just fair game. Like it's a smart contract. Anyone can post to it. But the idea is if the opportunity is like lucrative enough, then the proposer would use their monopoly rights over the L1 to propose the Tycho block. But really there's no rules, like anyone could do it. The issue though, this is kind of leading into your point about like how do we provide this performance and this UX for users? And that's where this total anarchy mode starts to fall apart. Because when you have a fixed sequencer or Jason Vranek (07:13.654) at least an election process that's clearer about who's going to be the sequencer, then you can start to issue what are called pre-confirmations. And you probably receive this all the time when you're using any existing roll-up. Like I send my transaction to base, they give me like an immediate receipt, even though like the L2 block time is like two seconds. And the L2 blobs aren't being posted possibly for hours. Like your transaction is like, it's a like handshake promise saying like, will include you eventually. And that's what you kind of lose when you move into this total anarchy mode. And so it's really the spectrum of like, you have liveness, you have credible neutrality, decentralization on the like anarchy mode, but you're losing on the UX front. Rex (08:04.246) Yeah. So, so let me repeat back what I heard from you. Tell me if this is, this sounds right. But what you're saying is the idea of a bass roll up is when it, know, Ethereum, every, uh, epoch, right? Um, or, know, every, how long is the epoch? 12, 24 minutes. forget. Eight minutes. 12. Jason Vranek (08:24.27) No, 12 minutes. Or each E-fac six minutes, finalizing is 12 minutes. Rex (08:28.776) Yeah. So, so once every six minutes, I think we're selecting the set of proposers for each slot for the next epoch. Correct? And so what we're saying there is, okay, now looking six minutes into the future, we know who the proposer for each block is. And today we allow them to decide like with complete, not autonomy with complete control who, like which Transactions are going to be allowed into the block and what order they're going to be allowed in and then kind of the next step is well We give them control over this block space like why not in our new? construction of aetherium give them complete control over the blob space as well right that area where roll-ups are posting transactions and You know we can talk in a minute about okay like Again, the whole reason why we didn't want the Ethereum based network to be responsible for these like high throughput environments was that would inherently require the Ethereum network to be high bandwidth to have super high hardware requirements and then start to compromise on decentralization. So we'll put that aside for a second, but that's kind of the fundamental idea behind base rollups is You had control over the block space before, that's table stakes, that's just how Ethereum worked. Now let's also give a monopoly rights over to the blob space as well. Not just which blob kind of comes in, but also like what are the specific transactions within each blob and the ordering of them. Does that sound right? Jason Vranek (10:07.342) Yeah, I'd say like I guess technically like we always are like proposers always have control of the blob space but it is that kind of refining of like the transactions within the L2 blobs like typically is That's all sequenced by like base and these decentralized sequencers. So yeah base for lobs Extend that ability so you can kind of rearrange the blob space. So I think that's a good analogy Rex (10:30.046) Okay, centering the conversation just on the block space, what we've seen in the evolution of Ethereum over the last five years is, of course, I'm running an Intel NUC that is now five years old in my wife's closet. It has power, but not that much power and definitely not enough power to be super intelligent about transaction ordering from an MEV perspective. Because I can't participate in MEV in the same way that someone like Coinbase, who is running a bunch of Ethereum validators, Over time, that is problematic for the network for centralizing reasons and just fairness reasons and all these things. The solution that we brought to the table that has, if not fixed this, at least moved the problem into a different part of the technology stack is proposer-builder separation. As the proposer, I don't need to worry about the ordering of transactions to maximize the value. can trust another party or at least trust the competition of many other parties to build the most lucrative block. And then I can propose that and share some of the value back with them. Right? Like that's how MEV works. that is ultimately how we're able to still allow Ethereum nodes to stay. hardware light and use consumer level and Raspberry Pi level hardware while still allowing for as much sophistication as needed for modern financial systems in the execution. First of all, do agree with everything I just said there? Jason Vranek (12:16.534) Yeah, totally. There's this trend of unbundling things as well, like proposing from building, and that's something that's also kind of happening on the bass twillip side. Rex (12:26.09) Yeah, well, I guess what I kind of want to understand from you is, is the way that base rollups kind of work is through that same mechanism where, sure, at a theoretical level, we're saying is when it's my turn to propose a block, again, my Intel NUC that really barely has enough compute to do something even remotely sophisticated on the block level and definitely doesn't have enough to be sequencing. a roll up that's going every 2.5 seconds with millions and millions of transactions. But I still get that monopoly and I can still farm out that sequencing to something like a block builder and then choose based on their competition or maybe a private agreement or whatever, which blob is most lucrative and then include that in my proposal of my block. Is that kind of what's happening here is that we're able to get the qualities of a base roll up without juicing up Ethereum validators because we have created this proposer builder separation and then we're able to kind of use something analogous or extend it to the blob space as well. Jason Vranek (13:46.081) So I would say kind of like we're in this direction of like, want, you don't want to expect that the proposer is like sophisticated. Like that's the whole point of PBS. And if we, if like sequencing based rollups adds the sophistication, then it reintroduces these dynamics that you talked about. And so like the default is that you want to be able to delegate these rights to keep like the proposer as just a dumb box, like a nook that isn't capable of building or anything and offload the whole like, sequencing based relifes to someone that's a little more sophisticated and can specialize in this. So that is a trend that is like something that we've been building towards. but I think it is worth kind of stepping back a little and trying to untangle. Like I think based sequencing is like one, it's like a subset of like these things that proposers can do. And like the bigger category is proposer commitments. So like if I want to sequence like Tyco, I can actually like in sequencing, I'm kind of committing to including these Tyco transactions as part of my L1 blob. So it's like a subset here. There's some of these things like proposer commitments that you can do without really needing to like beef up your proposers. One of them that we're working on is around inclusion lists, like fossil TBD, one that's going to be added. So one of the things we're doing is like, how can a proposer like add constraints to their block? that the rest of the PBS supply chain has to follow. Like, I want you to include these transactions, maybe at the bottom of the block because they're like less valuable ones. I can just grab those directly from my mempool. I don't need to be sophisticated. But that same mechanism, like how do you tell the rest of the supply chain, like how you want your block built is like fundamental in actually delivering like on the UX for these based roll-ups. Rex (15:56.063) Mmm. Jason Vranek (15:56.291) Like you want to be able to either tell someone like, Hey, my block has to include like Tyco blocks or do it yourself. Like build the Tyco blocks and then tell the pipeline that they have to include them. Rex (16:09.686) Yeah, so, and we don't need to get too deep into commitments. believe our second episode, if not one of the first few, was with Drew from Commit Boost. And, if you audience want to hear more about how this kind of works at that level, we'll link it in the show notes. suggest you check that out. But just to kind of put a bow on what you described, what... I think you're correct in pointing at inclusion lists as the simplest way to understand commitments, which is to say, look, I want 99 or 95 or 90 % of the block to be constructed as it is today by a sophisticated third party like Titan Build or Beaver Build, or is it Beaver Build even still around? don't know, but by a block builder. But I want to reserve some amount to... go to specific transactions that I want included. And maybe that's things that are currently on the OFAC sanction list, but I believe that Ethereum is credibly neutral and the US government has no right to dictate which transactions get included. And so I want to reserve a specific space. And so I think what you're saying is either as a proposer, I can put that constraint out into the wild and when people give me back blocks, they are forced to kind of do that work for me. Or I can just say, hey, like the block can only be 90 % full because I need to reserve some space for some stuff I want to do on my own. But that concept serves as the foundation for these much more sophisticated things, which are not really just about like, hey, you must include these transactions or you must not, but like can be built into entire roll-ups or maybe even. you know, systems that are beyond anything that we've built in crypto so far. Is that correct? Jason Vranek (18:05.216) Exactly. It's like inclusion lists would be like baby steps. And then once we want to do kind of more complicated things, there's for a lot of these going to be a layer of delegation. like typically those have been called gateways. Like a proposer can delegate responsibilities to a gateway and the gateway has this sophistication to be able to sequence the roll up based roll up or issue like more fancy difficult kinds of L1 pre-confirmations. And I think that's kind of the bigger thing that I'm getting at here is like pre-confirmations being like the missing piece for a lot of the base rollup adoption and that what's kind of like differentiating the newer iterations of these stacks from like the original like anarchy mode ones. Rex (18:54.998) Mm-hmm. So, uh, there's two directions I want to go in. Um, uh, I'll just pick one and we'll, we'll circle back to more of, um, the pre-confirmation side, but I'd love to just walk through the, the, the flow from two sides. One, the end user sides. Um, can you talk us through how, like, if I'm an end user, I don't care about any of this infrastructure. I just want to be using this base roll up. So, um, I. see a DAP, like I see a Uniswap on this base rollup, using a front-end generated transaction, and then the transaction leaves my computer. Can you talk through what kind of steps that flows through in order to reach ultimately like a confirmed blob on the Ethereum L1? And then afterwards, I'd love to talk the other way. Like if I am a Ethereum validator and I have opted into you know, I think commit boost or maybe something more generic and decide I want to be part of the base rollup ecosystem. Can you talk about how, you know, I signal that and kind of what that means for my workflow as a proposer. Jason Vranek (20:06.988) Yeah, exactly. So I'd say there's like two types of user flows and I can kind of easily contrast them. There's like the post-preconf world, like the UX should feel exactly the same today as using bass or any of these roll-ups. I think... maybe we could touch upon this later. There's like this composability aspect, like maybe my transaction isn't just touching like one Uniswap pool, but it's across like multiple as like this composable cross-chain transaction. ignoring that, like post this pre-conf world, it should feel the same. I think it's worth highlighting like why we need pre-conf so much. Like the UX of like the kind of anarchy mode is let's say like, And Tyco already has like iterations after this, like I go back over a year ago and I want to use Tyco. I would send a transaction. It would go to the public, L1 mempool. It's like an L2 transaction technically, but it's, it's in the public. And I have to wait for a searcher to kind of scoop up my transaction, put together a Tyco, blob and then post it. And the problem with that is like. Already the fastest UX you can get without pre-comps would be like 12 second confirmation time from a proposer. But if the Tyco blob isn't actually profitable, it could go multiple slots before someone decides it's like worth them submitting or it's worth it for a builder to include it. And so my UX could be actually like, several slots or like minutes worse than an actual L1 transaction because we don't have this inclusion mechanism. So with precomps though we kind of solve all this pretty easily with the pipeline. But you want me go into the other side? Rex (22:09.086) Yeah. Yeah. Let's get to that in a second, but like, guess let's, I want to be just like incredibly pendantic with you and like specific, right? So if I'm a user and I, I get, we'll get into composability later, right? But if I, so I generate using a front end, a Uniswap transaction, then that in the base rollout paradigm, that L2 transaction, where does that go? Does that go to some sort, does it go to the L1 mempool? Does it go to something like a private channel to a blob builder? mean, does it go to what essentially is like the base sequencer? talk to me through like, where am I sending it to and how does that ultimately get to the chain, the Ethereum chain? Jason Vranek (23:01.114) So in the old anarchy mode, it kind of just has to go to a public mempool since there's no single party that's responsible. So it has to be made available. In the pre-conf world, you'd be able to track, like this would all be abstracted away in your wallets, but it would know who the next gateway is going to be that has delegations from. L1 proposers and you're able to send a request to them and receive back these like fast confirmations or pre confirmations. Rex (23:32.191) Mm-hmm. Got it. So I guess what that is predicated on, right, is the next set of proposers need to, they opt in to providing these pre-confirmations and then they understand what the available gateways are. And they're saying, hey, I am opting into pre-confirmations. Like you on gateway on my behalf can, what is this? I? You can issue pre-confirmations based on like these constraints and then the gateway using the pre-confirmations that they have available to issue plus the transactions they have coming in are able to construct the L2 block or, or, you know, I guess I understand that, Ethereum validators need to opt in to say we are providing pre-confirmations. The user is sending transactions to the gateway, like talk to me on where these things come together, like what is the role of the gateway and how are they kind of taking all these pieces in order to do the bass sequencing. Jason Vranek (24:35.79) Okay, so, and you can stop me too if you want me to clarify on like parts of the PBS supply chain, but what we're doing is we're essentially adding one more person. So like we have searchers and all of that stuff we can kind of ignore for now and just focus on like, we have builders and we have relays, we have proposers, and now we have gateways. The role of the gateway is to be able to... issue different types of commitments on behalf of the proposer. And there's teams out there like NetherMind and Tyco are working on integrating like their gateway and proposer are the same entity. So you can think of them as logically different, but it's possible to collapse them. But their job is to be kind of user facing. Like they're going to issue whatever type of commitment you want. Whether that's like, will include your transaction on the L1 or I will include it on some L2. I will sell an entire slot. it's kind of, this is where we enter the world of proposer commitments. But once a commitment is actually made, it's the role of the gateway to create a constraint. Like there's like a mapping between like some kind of commitment and some kind of constraint. And it's usually like, if we're talking about inclusion, like back to the easier example of inclusion lists, the commitment could be, I will include this L1 transaction. And the constraint is going to be like, you have to include this L1 transaction. It's like a very clear one-to-one mapping. Then it's the job of the relay. to kind of aggregate together all of these constraints and make them available to all of the different builders. And so now when the builder like is submitting their bids, they have to take into account all of the constraints for the block and build something compliant. And then it's the job of the relay to kind of verify like proofs. There's like a whole proof element to this. Like it gets a little complicated, but the builders would want to prove that. Jason Vranek (26:45.046) This block satisfies the constraints. And then the relay will finally make them available to the proposer. So it tries to abstract it all away from the proposer. Rex (26:55.734) So I think the idea here is just like builders, and I guess searchers, builders is the, just like builders abstract away all of the sequencing of L1 transactions for proposers so that they can get the same performance without having to worry about being hyper sophisticated. I think what you're saying is that gateways abstract away the commitment piece. so that proposers can still get all of the benefits of pre-commitments without having to deal with the actual execution and everything from like pulling all the pieces together in order to make a fully, like a full block and then verifying that all of these things within the block and the blobs satisfy the constraints. then essentially just like Block builders allow Ethereum nodes to do sophisticated MEV without increasing hardware constraints. Gateways are doing that same thing on the pre-commitment side. Jason Vranek (28:03.702) Yeah, I like that analogy. Like one way to summarize that is like searchers and builders kind of abstract users away from proposers and then gateways also kind of abstract end users away from proposers. Rex (28:17.61) Okay, hopefully the audience is following, but I am. so, you know, to me, the pipeline is starting to come together and make a little bit of sense, but like, let's talk about some of the constraints that are put out there just by Ethereum, right? So as we said, we can only know into the future 12 minutes, right? Like in terms of who's going to be proposers. And then on top of that, because the Ethereum base network itself isn't requiring everyone to opt in to commitments at all, let alone specific commitments for base rollups, it seems like a lot of these systems are predicated on only needing to look forward a 12-minute window and having a high enough percentage of proposers that are opting in. So, I guess... I'm not really sure how to phrase this question, but for something like a bass roll-up, I don't think necessarily the look forward piece is particularly problematic. Like bass doesn't need to look more than 12 minutes into the future in order to like understand how to sequence transaction. But something that does seem kind of problematic is you need a certain percentage of Ethereum validators to opt in, right? And if like, let's say you only have 10 % that are opting into a bass roll-up, you could go. many, many epochs without having a single proposer that takes that pre-commitment and like pushes that block forward. So is there a way to kind of like on a general or heuristic level to understand what percentage of Ethereum validators need to opt in to servicing a based roll up in order for it to be a user friendly experience? Jason Vranek (30:14.242) Yeah, so I guess everything like always is a spectrum. There's kind of different designs that could be built. Like if you want to go completely like back to like we're based, like we're really based, like only L1 proposers can sequence the roll up. We just need one single validator kind of per two epochs in the look ahead. And that should be able to like, they should be able to offer confirmations, pre-confirmations ahead of time. Where this starts to fall apart though, is imagine like we have 64 total slots. If the single proposer is just like early on, then you have this downtime after. And like either you fall back to this total anarchy mode, where like if you really want your transaction included, like you can just include it yourself. Rex (31:01.728) Mm-hmm. Jason Vranek (31:12.172) just submit a normal transaction to like advance Tyco or baseball upstate. The other option is that you can fall back to some other like this is like another leader election mechanism on top. Like it could be that there are, there's a committee like you rotate between sequencers. You just fall back to like the foundation sequencer. So there's like ways to kind of regain that UX, like despite not having enough proposers, but then you're starting to trade off on like the sort of liveness and decentralization aspect. Rex (31:50.391) Got it. Okay, I think now's like kind of a good time to pivot the conversation into why, right? Like what are the benefits of building what is just inherently a more complicated structure? like you can tell it takes us 30 minutes even like put enough scaffolding around what is based rollups. like frankly, I'm not sure we're even there yet. But. But what are the benefits to doing this versus the centralized sequencer, you know, a la base, right? And I'd love to hear kind of the pros and maybe the cons, both from the benefit of the Ethereum network itself and like what we're trying to build in this credibly neutral computing platform and why the base rollup paradigm kind of delivers on that promise much more than what we have in centralized rollups. And then also, I'm gonna, we've teased it, right? What are some of the benefits to users, right? They don't maybe don't even really care about credible neutrality because like frankly, credible neutrality really hasn't been tested. And the moment it's tested, we might have like bigger things to be worrying about. So like talk me through why this is so cool, why it's so valuable and like why this really changes the game for what we're building here in crypto. Jason Vranek (33:12.514) But so, I mean, over the time working at Fabric, we've kind of come to a realization, which I'll maybe get to, but I think for starters, there was like two main pieces that were important. And it feels like you got to pick one, Or maybe it's a trilema, so I'll try to this all out. So definitely like, liveness is like one of the main... properties that you get from the original like based rollup concept. And it's liveness coupled together with this like neutrality. Like by relying on the validators, like you're always able to make progress with the base rollup as long as there's like another validator there and they're willing to sequence. But what we lost in that design was the UX. When you start to add like precomps back into it, There is this delegation step for a lot of these more complicated designs. And that starts to erode at that neutrality gain that you're getting. So, but we, now have fast, faster UX. Maybe it's, it's more decentralized than like just having one. Maybe there's like a bunch of gateways and they're taking turns or they're competing. Like that's kind of like the trade-off space between them, but. Then I guess you'd ask like, why do we even care to move in this direction if we're kind of like losing out on the decentralization? And I think this comes to like the other big selling point of bass doorlobes was this idea of composability. And that's where like composability today, what that means is like, I can call. in one transaction, like I could call Uniswap and then I can take something and move it to Aave. And this all happens atomically, like one single transaction. If any of these legs fail, like the whole thing is undone. And this is where I like that analogy of Lego blocks. Like we can build up a cool Lego structure from all these composable pieces. Jason Vranek (35:25.646) What happened with the roll-up set trick roadmap was that we started like having different sets of Lego blocks and they didn't really interoperate. So like I can't call, I can't go from L1 and call something on bass and then like take that result back and continue along. It requires, it adds these layers of like asynchrony to it. The idea with bass sequencing was kind of rooted in shared sequencing. If we remember when I was hyped up a while ago. shared sequencing is this idea of like, if you have one person with the monopoly rights, like to sequence multiple roll-ups, then they can start to give better guarantees compared to like multiple different sequencers all trying to coordinate with each other. And the idea with base sequencing was like, well, you have this L1 proposer, they have a monopoly over the next L1 block. And if you extended that monopoly over to some rollup, then you're able to start to treat them as like a shared sequencer for both and offer these, these guarantees. Rex (36:40.712) And so how this might be like too technical, not only to follow, right. But just from a, standpoint that we're not there yet, but in practice, what does that look like on the base layer is the idea that today each blob really is the execution space for a specific roll up that is sequenced and generated by, you know, a completely centralized third party, whether that's the off-chain labs for Arbitrum or Coinbase for base. But in the future, what that might look like is when the Ethereum proposer has the ability to sequence this space and more specifically to delegate that to a gateway, which then farms out all the different pieces of the process to different actors, a blob might look like really the combination of like two or three or many different execution environments, like four different base rollups, but because one party is in charge of that space, like they're able to say like, I am going to issue this swap on this chain, a bridge to this other chain, then use that bridge capital to do a loan, and then use that loan capital to buy an NFT. And because I control... all of the space and can sequence all the different roll ups in the same space, like I can make sure that that whole thing happens either completely or like all gets reverted together. And then so blobs become less like a space for each blob is for an individual roll up and much more a space for all the bass roll ups to do what they need to do together in that one blob. Is that, is that track at all? Jason Vranek (38:34.72) It does, I just want to like try and untangle a couple things. Like I'd say one, I guess I don't personally view like the blob space as being quite so isolated from like the L1 blob space or block space. And part of that is because like, I mean, users have to like bridge funds. Like if I want to deposit assets from L1 to L2, I would go through the bridge on the L1 contract. But What you see from a lot of these roll-up designs, like Arbitrum, for example, will only process a deposit after that L1 transaction has been finalized. On the OP stack, they'll wait four slots or four blocks. Like after that amount of time, they're fairly confident that there's not going to be a L1 reorg. And that's like, this kind of reorg part is where things start to get a little like you blend the lines between like the execution states. If like my deposit was initiated on the L1, like the sequencer starts like doing stuff with that on the L2, but then the L1 reorgs, now the sequencers kind of like left in this weird state, they need to either like roll back or like invalidate transactions. So that's where they're kind of different environments and. This kind of world that you're talking about with kind of blobs all kind of being shared and kind of this, the walls coming down and rollups are able to interoperate. Like that is actually like a lot of the goals of shared sequencing in general is to allow for this L2 to L2 interrupt. The thing that... based sequencing, or like including the L1 proposer, adds to this is composability with the L1 itself. And that was like back to like one of the original goals and why I think as like kind of a meme based rollups got started a lot was. Rex (40:31.114) Mmm. Jason Vranek (40:41.152) healing a lot of the fragmentation you're seeing from like L1 liquidity moving into L2s now like they're in different environments. Well, if we can collapse all of that so it L2s feel like and act like they're part of the L1 again, that helps with like value accrual, network effects, all of those things. Rex (41:00.158) Yeah, no, that's super helpful because, you know, part of what shared sequencing was offering was sure this, execution stuff that we were referencing, but, know, the flip side of this, and we S we saw this in other solutions that didn't really have anything to do with sequencing, like polygons, Ag layer was like, Hey, let's just aggregate all of the assets that are in this family of rollups. into one contract on the base chain so that if you want to interrupt between any chains that, like for example, like the whole thesis of the super chain for OP stack, right, was all of the assets for super chain eventually were supposed to be in one smart contract and so if you wanted to bridge from base to OP, right, like you didn't really have to do anything on the L1 because... Yeah, there's some accounting things you need to do, but like you can kind of manage that through ZK or batched over time or whatever. so that because the assets don't actually have to move, like you're able to get those, that, you know, atomic, UX. And what you're saying is that base rollups kind of the whole point of base rollups was to give that, that functionality from day one. Jason Vranek (42:21.015) you Rex (42:26.046) Right? Like that is what you're getting out of the box by using a base roll up is that you can, guarantee that what transactions on the L2 are core or directly correlated with things that are happening on the L1 and not have to worry so much about reorgs or, any of like these finalization games that we play that break the UX as it is today. Jason Vranek (42:52.03) right. actually that last part is sadly like, we, we still have to deal with that. but maybe like, yeah, just to like really summarize it with something like Ag layer. Like you're able to achieve, asynchronous composability between rollups. and Usually people like that are very pragmatic would say like asynchronous is good enough and we'd prefer that because it's a lot simpler to get two people to like join a protocol rather than like to tell them like hey you need to give up sequencing rights to this shared sequencer. What you need a shared sequencer for this synchrony. And maybe just to like, because like we always say these words like asynchronous meaning like, it doesn't happen in like one kind of unit. It's like I would send a response or like a request over and then like eventually like the other sequencer would pick up that request and like do the cross chain transaction. It's still like. atomic using these kind of shared bridge protocols like ag layer. So like if they don't actually like execute my transaction on their leg, then like on my leg, it won't like appear. So and like there's kind of a battle like that. A lot of people think that's good enough from a UX point of view, but it is kind of failing to solve this like fragmentation problem from the L1 side. Like you can have like fixed fragmentation using asynchronous interrupt on like L2 to L2. But a lot of the goals of like pushing based rollups and stuff is like, how do we bring that back home to the L1 as well? Rex (44:42.026) Hmm. Yeah, I like that. And with this construction of base rollups, do you like, how does the end game start to look? Do you think that the benefits of, of the base rollup construction will eventually be so strong that the chains like base will like either choose or be forced to opt in to becoming base rollups? Or do you see this as like, we've created a paradigm that you can build a roll-up and like, that'll be great. These are the benefits you could get, but also it's like totally legitimate and like, it makes a lot of sense if you want to be a business that still relies on a centralized sequencer. I guess like to phrase it a different way, do you see that bass roll-ups are coming to... be the next iteration of all rollups or do you see them as just equal class citizen to the different types of rollups, all of which will be entirely valid in the Ethereum end state? Jason Vranek (45:47.097) So my thinking on this has definitely evolved over the past year. If I put my idealistic hat on, would say if we're able to ship a bass roll-up stack that is performant and you're able to do this kind of types of composability out of the box, that would be great if it just like. was enough to attract existing roll-ups. But I think like, kind of from experience talking with a lot of these different chains now, there's like a handful of criticisms, like one extremely valid one that I think has been like very under-researched is around like the UX. Like we talked about like fast inclusion through pre-comps, but Something that you get from like base is this trusted relationship. When we switch over to this world, like whether it's through gateways or not, it's like kind of a, we're entering like a permissionless system. And that's where like maybe the incentives of the sequencer aren't exactly aligned with the incentives of the users. And the argument is that like they would just start sandwiching L2 users. And I think this is like, it's like a valid argument, but this could be stopped by adding sequencing rules to your rollup, which is something like, not, we're not really, I don't think there's a lot of research into because like, you don't need to like design mechanisms to enforce a sequencing rule if you just trust based, like not to sandwich you. So. Jason Vranek (47:35.361) If we like, guess my, way that my kind of thinking is evolved on this though, is that there's going to be like a class of rollups that are based and like there's certain like user preferences. it's that would be like kind of. If we move towards on this back on this side of the spectrum towards like liveness and decentralization, I think that could fit a category of users that don't care about like. high frequency trading or anything. They just want a cheaper transaction than on the L1 and they don't really care about like how fast it gets included. What they do care about is like actually inheriting the like security properties of the L1. So I think that those will exist as like a class of roll up. There's going to be kind of On the other side, you might have like these like really cranked up, like we got a gateway and they're really fast and they're able to compete with bass and maybe we're rotating between gateways because it's still permissionless, but you still need to be like competitive enough to compete. And I kind of view those as like a flavor of these kind of bass rollups that are more competitive with like the status quo. But there's actually like a third path that we've been really thinking about and this was like kind of the big realization that we had was like the prep, the original premise of based rollups, like the old total anarchy one was like twofold. It was like the liveness and everything and composability. And if we kind of agree like, Touching liveness is hard, like if we don't want to expect proposers to become sophisticated and we just focus on the composability piece, what can we do with that? And the realization was you don't actually need the L1 proposer to be the L2 sequencer. Like they don't have to be like shared in that sense. You just need them to coordinate with each other. Jason Vranek (49:43.247) in order to be able to get this L1 to L2 composability. And so what that could look like in this end game is that you have L1 proposers, they make commitments, and the commitment is to some L2 proposer like base that says, like, I'm going to include these L1 transactions in this order. and your blob transaction. if I don't mess with the ordering at all, it'll all execute atomically. And you're able to do cool things like flash loans from L1 to L2, all of those cool composability things. Rex (50:25.15) And so in this case, what you're saying is that the pre-confirmations allow you to get all of the composability of benefits of based rollups, but still allow the rollups themselves to be run in sequence by centralized single entities, correct? Jason Vranek (50:49.61) Right. And a way to think about it was before we would say the proposer sequences the L1 and now like they're going to sequence some like portion of this blob space. Now, like if we change to this paradigm, it's like the L2 sequencer sequences their blob space and a really small subset of the L1 block space. And then they use like proposer commitments to coordinate, to make sure that like that actually ends up on the L1. Rex (51:19.914) And so what this would look like is the proposer says, gateway, I'm opting into this construction. I am committing that I will accept a blob and let's say 10 or up to 10 corresponding L1 transactions atomically. And then the gateway will say, okay, base, arbitrum, linear. I want all you got, like here is like the offer on the table. You can have the blob space and up to 10. Now create the most lucrative blob slash block combination, send them over and I'll offer them the proposer and they'll pick the one that they want, but whatever they pick, you're guaranteed to get both those pieces in. Jason Vranek (52:06.39) Right. And one like even simpler construction is like without even coordinating with like linear based on all these different players would be like, whoever if once we get to this like super, I'm just focusing on like OP stack, like they have the super chain, they're going to like all kind of publish together. Like you'd be able to coordinate that with this L1 proposer. And now you have like L1 into whatever ecosystem. So like super chain ecosystem or like zk-sync. Like that's yeah and this is all without like needing we don't really need sophisticated gateways to even do that. Like the simplest construction is you just say like the L1 proposer is selling their like top of block slot and like the L2 proposer would just purchase that like base would just purchase that. Rex (52:38.208) Mm-hmm. Rex (53:05.206) Mmm. Jason Vranek (53:05.294) But that's like contentious because top of block and all that MEV and stuff. So there's like other designs we're exploring. Rex (53:12.214) Yeah, middle of block. Cool. No, man, I think that's, I think that's really interesting because, you know, I think in crypto, we tend to have this habit of kind of talking about things on the extremes of like either it's a centralized, like financial application or it's decentralized and like you kind of have, you try to bucket things into one or the other and that really breaks down, or it doesn't break down. What it does is it makes it lot harder to see the interesting things you can do in the spectrum in the middle. And so, you know, I think one of the cool ways to look at this technology that we're building in base rollups is not necessarily that the future of all rollups are going to be based, but by going through this process of creating base rollups, we've really opened up the design space to say, how can we combine parts that are centralized and parts that are decentralized to gain benefits of both and have something that definitely exists in the middle, but it's maybe better for it. Jason Vranek (54:24.918) Yeah, totally agree. This is like huge design space and we're always like uncovering new bits of it every day. Rex (54:31.402) Yeah, awesome. And so the last couple of minutes here, can you just like give us like a high level overview of where we are in terms of implementation? Like do base rollups exist? Like are they out in production? Are the ones that are out in production like really at the level where you can do stuff like you can do on the, you know, their centralized counterparts? Where are we in the roadmap? Like what should we be looking forward to see this progress? Like just talk to me. Like I think we've run through like what are base rollups and why are they cool? But like. Where are we? Jason Vranek (55:02.786) Right, so, I mean, there's a handful of teams building out there. think the pioneer has always been Tyco. They started with this like total anarchy and they're on mainnet. So recently they did a release where they added pre-comps that are like not based pre-comps. Like they're not actually tapping into the L1 proposers, but they have kind of a whitelist of... you can call them gateways or whoever is actually sequencing. like, even though like having a whitelist and everything like sounds like kind of a half solution, like that's already like more decentralized than like bass and any of these other existing L1s, cause at least they have like a rotating set of sequencers. So the next step just on like the bass roll-up side has been. Rex (55:48.031) Mm-hmm. Jason Vranek (55:54.575) how do we actually unlock the proposers, like add them into the picture? And there's actually been kind of a blocker for a while. Like you mentioned before, like we have a view of the next 64 slots on the beacon chain. The problem was that there was like, this non-determinism, like between epoch boundaries, if proposers got like slashed or like consolidated their stake, it actually affected like the randomness for the calculation. And so the whole next epoch could be different. And you wouldn't know that it's different until like that moment that like the epoch boundary changes. And so if you're imagining like trying to issue credible commitments to people, like, yeah, I'm up in six and a half minutes. I'm going to like include your transaction. But then like you just lose your slot. as the proposer, like that's a terrible UX. So there was a Lin from Nethermine proposed this, this EIP and it was probably the fastest EIP to get fast dragged in and just launched in Fusaka. So now it's like, one, it's like deterministic. The look ahead boundary like doesn't change anything. And now it's also possible to like get a view on the look ahead from the point of view of a smart contract, which just like. wasn't possible before and made things like really tricky and complicated designing things. So that was like one of the main blockers like before you'd see production kind of like proposers in your bass prolapse. The other piece here is around... Jason Vranek (57:37.199) collateral, like something we haven't mentioned. When we're doing pre-comps, it has to be like a credible commitment. Like these are permissionless systems and anonymous people, like you can't just pinky promise. You have to like have some slashing mechanism there to punish them if they like don't include your transaction. And so this was something that at Fabric we've been designing to be like a neutral kind of, we call it the universal registry contract. It's just like, kind of a immutable contract, proposers can put in collateral and there's like ways where they can like get slashed if they break their promises. And we're trying not to like have to like enshrine anything like restaking or any of these complicated things. It's just like a neutral contract. And the goal is you want to get as many proposers to like opt into this and use it as like a discovery mechanism. Like today we might have like Or in the future, might have inclusion pre-comps for inclusion lists or other flavors of proposer commitments. You don't want to have to go through this BD process, like getting proposers to put down collateral to join your network. It's like a shared location to bootstrap that. So that's another thing. gone through a couple audits. We're kind of hoping Q1 next year, I think, to deploy that. And I think Tyco will start to use it. And that's like, if you just focused on like pre-comps and based roll-ups, like those are where the biggest blockers. There's actually like another one that we haven't even talked about, real-time proving. When we're talking about composability stuff, especially between the L1 and L2, if you want to do like this kind of flash load, borrow from L1, go to L2 and come back, it's like that coming back part you need to be able to prove the roll up state transition function. that was never possible until like all of a sudden, like all the acceleration around proving has made that possible. So what used to be years away is now kind of Jason Vranek (59:50.13) building block for people to use. Rex (59:53.813) Yeah. No, awesome, man. And like you just opened up a bunch of like new conversations to have, you know, I think one, I think there's a really interesting conversation about how the line between the beacon chain and the execution chain is starting to get more and more blurry. And like you made one reference to how now smart contracts are, have access to the look ahead window. And, you know, I think that that's just like one small piece, but then you start to have these conversations around. native rollups and like having the ability to, you know, essentially like prove the EVM as a precompile. I think there's like a whole interesting conversation about what does the future look like? Like is the end state of Ethereum still these like kind of two chains that are fused together or does that all kind of collapse into one? I think on the collateral piece, you know, I I totally get it. And I also totally get why you wouldn't want to build any specific solution into that. Like, how are we doing the crypto economic security just for, for credibly neutral reasons? And to me that wants, I want to open up the whole conversation around what restaking, what Eigenlayer originally was. Like, look, like it's, it's a little bit crazy to me that if I'm a proposed or if, yeah, if I'm a Validator on Ethereum. I already had to put in 32 ETH and now have to put in even more collateral in order to participate in Pre-confirmations like why can't I just use the same original collateral? And then on the the last piece that you just talked about on real-time proving I mean You know, I think at this point it's cliche to say but like the I Remember when I first got into crypto in like 2020. I remember Rex (01:01:53.139) Even back then, think the bankless guys had Vitalik on the, you know, this is like the end of 2022 or something, but the bankless guys had Vitalik on and they're like, what's the most surprising thing in crypto right now? And what Vitalik said was, you know, I always thought that like we would get optimistic roll ups like done. then like years later, we'd have ZK roll ups and just the rate at which ZK is progressing and becoming more efficient and performing and cheap. Like the reality is, is we're gonna have real ZK roll ups before we ever really figured out how to do fraud proofs. And so like that, that was like two, three years ago and things are only getting like so much more crazy. But again, I think that just opens up three hours more of conversation and I'm not sure that either of us have the attention span or the time to get through that. So. Jason Vranek (01:02:26.542) you Rex (01:02:44.724) I will wrap us up here, first of all, just Jason, thank you so much for the time and walking us through such a kind of complex and technical topic that most people, it's still, despite this conversation being years old at this point, it's still so far off people's radar, but like really will transform what we can do and what these blockchains are even for. first of all, thank you. And if anyone is interested in learning more or excited about what we're talking about or just wants to be more involved in this space, can you tell the audience where they can find you and maybe some of the resources or places they should check out? Jason Vranek (01:03:22.958) Yeah, so I think the best place for information would be like on Fabric's website. We kind of put together a lot of the educational resources and the research that we've been putting out and links to all the repos. I guess the biggest announcement to stay tuned for would be gonna do a testnet very soon for the full pipeline like L1, pre-comps, everything. So just yeah, if anyone is interested in the research, I'd say like Those big questions, like real-time proving, always made this very theoretical and far off. And now all the pieces are here, it's just up to people to put them together. Rex (01:04:03.798) All right, awesome man. Well, Jason, thank you so much and have a good rest of your day. Jason Vranek (01:04:08.047) Thanks, Rex. Rex (01:04:10.039) All right, don't leave.