# Luban

- Channel: [ZuBerlin](https://streameth.org/zuberlin)
- Date: 2024-06-11
- Duration: 24:46
- Topics: blockchain, ethereum, defi, developers, fintech
- Watch: https://streameth.org/watch/6668652806eda795c89291b2
- Download: https://vod-cdn.lp-playback.studio/raw/jxf4iblf6wlsyor6526t4tcmtmqa/catalyst-vod-com/hls/5ec0kz11zbs5c1if/1080p0.mp4

## Description

Clip The video presents a discussion on how to reinvent the protocol buffer (PBS) space, specifically focusing on Layer 1 (L1) pre-confirmation protocols and their integration with wallets for gas fee hedging. The speaker represents a research and product company in the blockchain financial primitives sector. They introduce a mental model where rollups act as block space dealers, buying space from L1 and reselling to Layer 2 (L2) users.

The talk outlines the current issues with high L2 transaction submission costs due to inefficient packing and non-deterministic block confirmation times. A solution proposed is based on pre-confirmation, aiming to reduce confirmation time significantly and lower transaction costs.

The speaker delves into the concept of proposal commitment, which includes an optimistic mechanism, EVM state changes, state dependencies, and a challenge mechanism for penalizing non-compliance. They address the "cold start" problem of getting enough validators to opt into the pre-confirmation network and suggest using pre-conf delegation as an initial strategy.

A go-to-market strategy is discussed, drawing lessons from MEV-Boost's adoption journey by minimizing risk for proposers and simplifying their opt-in process. The talk also touches on potential issues of centralization and censorship resistance that can arise from delegated pre-conf

## Transcript

I hope the title can wake you up a little bit. PBS is a controversial topic. So my title is based on pre-conf, on how to reinvent the PBS world. So first, who we are and what we care about this problem. So we are a research and product company that focuses on building financial primitives around the block space, which is, in my opinion, the most available commodity in the techs to come. So our first product iteration is the L1 Pre-Conf protocol, very much similar to what ChainBound has presented, but our product is more geared toward the gas fee hedging and the composability with the wallets. But this talk is not about our product. It's more about how to share our thinking around basic break-off for L2s. So to us, we have this mental model where roll-ups are basically block space dealers. The bias blocks space from L1 and the reseller to the L2 users, so glorified block space dropshippers. So base-to-roll-ups integrate the block space with the distributor, creating an interesting dynamic between L1 and L2, which is kind of contrary to the aggregation theory where you have the distributor to integrate it with the demand. Here we for the base roll-ups the distributor distribution platform is actually directly integrated with supply which creates this kind of interesting dynamic we're very happy to explore. And also we see that L2 as a surface area to experiment some of the important initiatives that cannot be implemented directly on mainnet today due to technical and operation constraints. So that's basically why we care about this problem. So in this talk, I want to first talk about the BASED rollup today, also our thinkings around the BASED roll-up today, also our thinking around the BASED preconf, and also the selection mechanism, and lastly we want to propose a more actionable item, which is the preconf request transaction format. So firstly, let's take a look at the BASED sequencing today. So this is partially inspired by the Tyco's architecture today. So the user sends their transaction to the L2 mempool. They have a proposers to differentiate it from the L1 proposer. Currently, I believe that there are just a bunch of bots that gather the transaction from L2 mempool. Then they send that to the L1 mempool. Then the builders pick those transactions, the bundles from the L1 mem pool, and this and that to the proposer. The problem with this is that it actually has incurred a very high L2 transaction submission cost, mostly due to the inefficient transaction packing. Because Tyco today, for every transaction the users submit, they have to submit a new blob. So a blob is kind of a fixed data space that their price doesn't really allow you to dissect that into smaller pieces to allow you more transactions. So in this way, so the users are paying the full blob for their transactions today. So the Tyco have to pay out of pocket to subsidize their users. for their transactions today, so the tech will have to pay out of pocket to subsidize their users. And the second problem is that we can see there's a non-deterministic block confirmation time for this vanilla implementation of a based rollup because the transactions bundles that got sent to the L1 mempool, and it doesn't really have this deterministic guarantee that the block builder will actually pick it up. So as the user, they don't really have a very consistent timing in terms of like to know when their transaction will be included into the next block. So this is why we really need a solution like based onoff information. So ideally, we want the confirmation time to go from the non-deterministic to less than 100 milliseconds. And the transaction cost to average to about a 2.5% today to 0.08, assuming that posting one block per epoch with the current Kata-Taiko's transaction volume. So what exactly is a based to pre-confinance? Everybody knows this, but for us, we have this kind of momentum framework that a base to pre-confinance is especially a form of a proposal commitment. So what is a proposal commitment? Proposal commitment to us have this five-inch search element where you have the optometric mechanism where a willing proposer either act independently with the right trust to delegate or combination both to issue a commitment to perform a finite series of actions and the result of these actions will result in EVM state changes and all the state changes will have a state dependencies be either a time dependency or state dependency and lastly there will be a challenge mechanism where if the promoter does not honor this particular commitment they'll be penalized for that so this is totally out of protocol enforced proposal commitment this to differentiate it from the PEPC which is a totally different thing. So to apply this framework, I think the basic pre-conference exactly goes like this. So a proposer opting by agreeing to additional slashing conditions, namely the safety and the liveness failure, and the proposer would commit to sequencing a series of transactions. The sequencing action will lead to the changes in the L2 state. And all these sequencer transactions will have time dependencies. They have to be within the slot that the user has specified or a state commitment if it's a break confirmation of state. Eventually, there will be a challenge mechanism. If the proposer renegates, they'll be penalized for that. So this is essentially saying, as a proposer, I will commit to sequencing user transactions according to a set of user-defined constraints. And if I renegade, I will be willing to be penalized for that. So we're facing a very immediate challenge here. So we have this costar problem for based-up pre-comps. So this graph is basically showing on the x-axis the percentage of validators of the overall Ethereum network that have opted into a based-up pre-comp network. And on the y-axis, it basically shows the probability where at least one or two or three all the way, goes all the way to the 32 pre-conversing in that epoch. So to see, to have a very high confidence that we will have a one pre-conver in epoch, we need to at least to have a 20% of the validator opting into the entire network. So how do we get from zero to one? That's kind of a problem that we are all trying to solve as a community today. So the key questions that we want to answer is that how can we make a basic pre-conf work when there are not enough opt-in proposers? And also at the same time, how can we encourage other proposers who have not opt-in to opt-in to the preconf network and become the proposers to sequence the L2 transactions? So the answer is a preconf delegation. So we can ask these external parties, namely preconf getaways, to ask the proposer to delegate the task of pre-confirmation to them, so that even if we don't have all 32 proposers opt-in to the protocol, we can still ask them to SQL transactions. Secondarily, it's more of an operation goal where we want to simplify the opt-in process for the existing proposers. So I borrowed this graph from Limechain. This is basically their work for vanilla-based roll-up. So in their design proposal, they want to create a proposal pool to fill in the gap for the proposer who have not opted into the protocol but i think to make it even more simpler we can actually have um the pre-conf gateways uh to step in to fill in uh this getaways to step in to fill in this gap the gaps are between slots and to issue pre confirmations of course that's a more centralized solution but I think that's the best way we could to accelerate the adoption and the second way which is the second key issue we want to address is so what exactly is the go-to-market strategy for boost-driving proposers? I think we can actually take a historical lesson from MAV Boost. So from October 2020 to about January 2023, they went from zero to 90% of adoption. Their selling point was actually pretty straightforward. So basically what they're saying is that, here's a piece of software every validator can run, and if you use it, you could earn more fees without incurring any risk. So for the delegated pre-conf, I think we should also make a similar strategy. We should make that the risk undertaken by the proposer as minimal and also we should make that running a sidecar software as easy as possible. But this creates problem. So this progressively sounds like I'm making a case for running PBS, doing PBS again for roll-ups. So this screenshot is taken from a talk by Hasso last year. So decentralized sequencers, in the end, you solve PBS. In a way, for delegated pre-conf, it is exactly the scenario here. So PBS is a very controversial topic. I personally don't have a very strong opinion about it. It was the best solution at the time, but it does create a lot of legacy problems, one of which is that it does increase the censorship resistance for the Ethereum network. So we can see that the top builders are building most of the blocks on the Ethereum network today, which in a way, if they want to, they can censor certain transactions for a certain period of time. So for roll-up, definitely this is not the intended goal that we want to achieve. So for roll-ups, generally, we have a consensus that if the sequencer sends their transaction, there's an alternative path, which is escape hatch. So where your user can send L2 transaction using the L1 mempool and get the transaction include the onchain. However, for some use cases, this is actually not enough. One of the examples is that the sequencer could delay the bids in the auction, giving themselves a fair advantage. Even the user could submit the transaction using this alternative path, because the alternative path is generally slower. By the time their bids lands on chain, the auction probably already completed. So this begs the question, like how based is the delegated breakdown framework? So the intended result for the based sequencing or based roll-up is that one, L2 to inherit the liveness and the censorship resistant properties from the L1 directly. But the issue with the delegation is that the delegation tends to compromise of this virtues for the other reasons I have just elaborated. So what do we learn from the PBS and what, how we can do better? So what we learned is that oligopoly or monopoly is kind of a natural outcome of a merit based delegation mechanism. So auction, the just-in-time block auction is kind of a merit-based delegation mechanism. So that leads to outcome that we have seen today where you have a top three block readers that dominate the whole market. So what we could do with this? So I think it's actually very simple. We want to keep basic sequencing based. So the delegation, as of right now, is a natural solution, especially early on. So the delegated pre-conference can actually rely on the trusted social consensus. But progressively, we should aim for a more robust mechanism. So at this point, I very much agree with the switchboard solution where we don't want to enshrine any mechanism early on, and we want to progressively explore the different design options, how we can actually make the base role a lot more decentralized. And another thing that I want to point out is that we not only want to enable the proposers to have this autonomy when making decisions, but it will also support them. So instead of having this banner option, they either sequence themselves or delegate the sequencing to a third party, there's just something in between that we can actually explore so one of the way two ways I think this could work is that the partial sequencing the partial sequencing I got this idea from the partial blog building there's a actually a design proposal called a MEV boost plus that's for L1 but I think we can actually borrow the idea for the based pre-conference framework as well. So the other idea is that the concurrent sequencing. I also borrowed this idea from a design called multiple concurrent block proposers, where you have multiple pre-conferences. They can all be the opt-in proposer in the same epoch. They form this consensus framework. Then they all propose blocks, first come, first serve. Then you have the current leader of the, the current proposer of the current slot to be the leader, and then they merge out different bundles. And if you have this bundle to be the finalized version of the sequence transactions. In this way, it maximizes the censorship resistance property, and also you have this very high liveness guarantee. So in the next section, I want to talk about the delegation selection mechanism. So there's one important requirement for selecting the pre-conffirmer, which is that the selection has to be done in advance, in contrast to just-in-time block auction today for MEB boost pipeline. So generally there are two approaches for this. The first one is the Ex-Andi auction, which basically is an auction that takes place before the winning party actually perform the task. The other approach is a lottery-based approach. Execution ticket could be considered as one of the representations of this approach. So internally, basically we're writing a blog post on this, we're going to release that soon. But we have conducted some research with the goal to selecting the ideal pre-conformer selection mechanism. So the conclusion we arrive at is that the exit-anti-auction favors well-capitalized sophisticated parties who will gain superior market power over time because of high capital requirement for risk-taking. Because a slot auction compared to just-in-time block auction, there's a risk involved. And not every party can engage in this kind of game. The more money you have, the more money you can lose. So eventually, the well-capitalized parties will always win in the long run. The lotteries are not too much difference because you can imagine that in a lottery setting, the more ticket you buy, the higher likelihood that you are going to win. But we think that a mechanism designer can actually have more control over the probability distribution of winning. So this is how it works. So basically here, p is the winning distribution and it generally confirms the winning distribution function here. We can see three different mean representation of this winning distribution function. So when you have a lottery where one holder can only hold one ticket per round, you have an expected profit that just looks like that. And it's basically the number of tickets or is the reward discounted by discounted factor minus by the ticket price. We change the game's lottery a little bit where one holder can hold multiple tickets. So in this way, T is basically a number of tickets that the user holds. In this way, the expected profit changes a little bit. And the last one is basically the execution ticket proposal. So by comparing the expected profit, we can in a way know how much each party will bid for one epoch. So compared to the auction, this gives the mechanism designer much more control over how they want the winning distribution to look like. So you can imagine this scenario where the number of ticket one holds doesn't increase linearly but quadratically. So in that way, it's much more like a quadratic voting. the number of ticket one holds doesn't increase linearly, but quadratically, so in that way, it's much more like a quadratic voting. So if that's the intended goal of pre-government selection, so that would basically give the lottery, will give the mechanism to decide more options to choose from. So basically, that's the conclusion compared to options. Mechanism designers will have more control over the winning distribution through a lottery-like mechanism. So as an initial step, I think to accelerate development process, we should just do, we should just select the delegated preconf getaway purely randomly or alternatively or just on a rotational basis. Progressively we can research more robust mechanism to make sure that the process is more decentralized and fair. So lastly, I want to propose a more actionable item. Basically, I think when we're talking about the pre-conf format, people are generally thinking about the pre-conf of inclusion and the pre-conf of execution. And for pre-conf of execution, I think most of people after talking to different teams are building this are more thinking about the post-execution state but instead I would propose that especially early on we should focus on more on the pre-conf of a pre-execution state. So for this proposal we assume that the pre-confer request will be gossiped over a B2B network by the pre-confers whenever they pre-confere a transaction. And in the transaction, we'll include two additional data. One's a deadline, basically says that this pre-confirmation should not be executed after this particular time. And the second one is basically the pre-execution state route for the EVM. So why is this beneficial? So this facilitates a very easy transaction contention. So if you can imagine that if a searcher want their transaction to be placed on top of the block, what they can specify is basically the pre-execution state root of the last block. So instead of having, specifying the post-execution state root, which makes the pre-confirmation to build a block much harder, this actually provide a very easy semantic for the searchers to express their block contentious. This actually supports most of the use cases that we can think of for arbitrage bots. Once they receive the gossiped transaction confirmation, they will immediately bid for the next inclusion by specifying the pre-execution state route. For intent-based transactions, honestly, I don't think that is the job for the pre-confirmer. I think that job is the best left for the solver to do at the application layer. Also, another side effect of this is that it incentivizes the timely service. So naturally, the pre-confirmer would want to delay pre-confirming any transactions so that they can reorder the transactions to generate more MEV. But imagine a scenario where every user specify the pre-execution state route. So the pre-confirmer will have this visibility of queue of transactions that all have the same pre-execution state route, the pricing becomes much easier. They simply choose the one that has the highest priority. So in this way, it kind of solved the pricing problem for the pre-confirmation as well. So also, lastly, you also have the benefit of to be front-run resistance because you're specifying the pre-execution state route, so no transaction can actually be placed in front of you. If it does, basically that counts as a slashable offense for the pre-confirmer. So that is my talk. Thank you. Thank you, Harry all makes a lot of sense. How do you think about the, if we include the pre-execution state route and the pre-confirmation request, how do you think about, like, the competition that creates for a lot of users who are trying to get a pre-confirmation and they might not know the latest state route that has been pre-confirmed? And by the time they do learn that latest state route, you know, someone else has already gotten a pre-confirmation. So, like, how do you think about that? Yeah, so first, I think your restaurant assumption is that every confirmed, pre-confirmed transaction need to be broadcasted properly. So everybody in the P2M network should be able to know what's the latest confirmed pre-assecution statement. And alternatively, for pre-confirmed inclusions, the ordering of them doesn't really matter. So the pre-conflict for America actually do this in parallel. The pre-conflict for transactions that have specified the pre-execution state route and the pre-conflict of inclusion transactions. So this too doesn't really conflict with 1.0. Okay, any other questions? Just curious, great presentation, by the way, definitely learned a lot there. How are you guys thinking about the peer-to-peer protocol that you'll use? And also, like, what type of attack surface is there? Yeah, so that's actually something that we definitely need to look into a little more. At this stage, it's just a design proposal. By no means, I'm a computer network expert. I would imagine that this P2P network, you're constantly engaging this confirmation, the broadcast will increase the bandwidth consumption. But by how much, I actually don't know yet. So I would love to talk to experts on in this particular area. Okay, any other questions? No, with that, thanks again.