Designing an End to End Solution for Based Preconfirmations

Thank you. Kind of. I mean, it's fine, but since we're here. Okay. Yeah, very good afternoon to all of you present here.

So, yeah, we have reached the final day of DEF CON. We have had, like, ten different talks on pre-confirmations, three full-scale events, and the only question that I've been getting is, how do you make all of this? Like, fast transaction confirmations, yeah, we get it, but how do you make this? So yeah, now on the last day, welcome to the workshop on designing an end-to-end system for Bayes pre-conformations. A quick introduction of the speakers.

Ahmed, go ahead. So my name is Ahmed Bitar. I work as an Ethereum core developer. Normally, I'm also the product manager of Surge and the technical lead for our pre-conformation solution. And I'm Anshu.

I am working as a blockchain engineer at Nethermind. And I joined this industry like five years ago, mostly focused on DeFi. But for the past six months, my efforts have been mostly concentrated on base reconfirmations. So today this session is a no-code session. So I won't be like writing a line of code and then asking you to copy it and repeat it like 100 times over.

I know most of you will leave in like half an hour if I do that. So instead, this is a session on design thinking, where we'll build the whole concept from ground up and share what exactly we did during our research over the past six months. But if you are interested in looking at the code, then I have linked it below. It's taikoprecomp-avs-repository, which you can find on the Nettermine GitHub page. So since we want to build it all up from ground up, we have to start with the foundational knowledge, which is rollups.

Because the base in base pre-confirmations comes from base rollups. Just by show of hands, how many of you do understand what a roll-up is? Okay, pretty much everyone. That's great. Well, roll-up is a scaling solution.

And why do we need a scaling solution? We need a scaling solution because the L1 is really slow. The throughput of L1 is not much. And why exactly is that the case? Well, in a blockchain, blocks are basically a consensus on state transition.

That's the first section of the Ethereum white paper. You have state A, you put a bunch of transactions and apply it to state A, which is like a delta, and you get a state B. But now imagine millions of nodes doing this every single epoch. Now that's going to make this network really slow, and that's a major problem. So what's the roll-up way of doing it?

Well, if processing state transitions is the biggest issue on the L1, what if we process these state transitions off-chain or apply these deltas off-chain? And that's exactly what a roll-up does. You can have one single roll-up node, or an L2 node, since it becomes a layer 2, that applies this delta off-chain, processes the state transition, and the L1 is just an observer. On the L1, you have a roll-up inbox contract, and you simply push the state transition and the delta, maybe as a form of a blob, or in the call data. In the image, it's a blob.

And the L1 is just an observer. And in the most basic form, this is what a rollup is. But is this enough? Well, no. Because if it's just one node pushing the transition and the delta, how do we know whether it's actually correct or not?

And this is where the flavors of the rollups come in, optimistic and ZK. In the case of an optimistic rollup, well, you push the state transition and the delta, and then you just wait. You just wait for someone to prove you incorrect. If you're correct, it's all good. But someone can just come by and say, oh, hey, it's a proof, here's a proof.

This transition that you posted is not possible with the delta that you posted. And then you kind of get slashed if you have some stake in. Depends on what kind of process the rollup wants to do. And Arbitrum is an example of an optimistic rollup. I guess most of you must have used Arbitrum.

And then we have ZK rollups. In the case of ZK rollups, instead of waiting on for someone to prove you incorrect, the moment you push the transition and the delta, you have to prove that this is correct. So it's called a validity proof. You're basically proving the validity of the transition. But the point here is that whatever time or computational effort it takes to verify this validity proof must be less than what it takes for the L1 itself to process all the data.

Only then it actually makes sense, right? So these are the two variants for proving whether a transition is correct or not. Once again, by show of hands, how many of you have heard of centralized sequencing? Okay. It's the most cursed concept right now.

And just to give a quick primer, when you're making a transaction on Arbitrum, you're not directly sending the transaction to a public mempool, like when you're doing when you're transacting on Ethereum L1. Instead, it's going to an Arbitrum sequencer. And it's a private server. What the sequencer does is it has complete control over arranging or ordering the transactions. And they usually promise that they will arrange the transaction in a certain way.

We don't know whether they're actually doing it or not. But in the case of Arbitrum, the promise is that it's a first come, first serve. If your transaction comes before that other person, we'll put your transaction first in the block. But once again, it's a promise. We don't know whether that's actually happening or not.

So let's get based and talk about based rollups and pre-confirmations. Well, the based part is actually not a different variant of a rollup, so it doesn't stand beside our optimistic or ZK rollup. Instead, based is a form of sequencing, just like we have centralized sequencing, we have base sequencing. And in the case of base sequencing, the L1 proposer is the sequencer. You don't have a centralized server sequencing the transactions.

Instead, it's the L1 proposer. Let's say we have Tyco. Tyco is a base rollup. And in the case of Tyco, the L1 proposer literally runs a Tyco software alongside the usual consensus and execution clients. And whenever their block comes in, they literally just pull the L2 transactions from a public Tyco mempool, they order it in their L1 block and put it on the network.

So yeah, you basically are inheriting the L1 security as well as the L1 liveness, because the L1 itself is your sequencer. So just a quick overview of how Tyco actually is arranged. Well, you have the rollups inbox contract that I have been talking about. And although Tyco doesn't really call it rollup inbox, this is the colloquial term. Tyco has like a bunch of contracts that work together and they just call it Tyco L1 contract.

So that's the L1 component. Now, if you're running an Ethereum validator, you usually run an execution client and a consensus client, right? So in a similar way, if you want to run or be a part of an L2 network, the proposer has to run an L2 execution client and an L2 consensus client. So in this case, TycoGet is the execution client, which is a modification of the standard Go Ethereum. And this is where you have the mempool, you have the actual L2 chain, all the blocks are formalized, and you also have the EVM on the L2 network.

And then we have the Tyco client, which has some subcomponents. And this forms the consensus client, and it deals with proving the blocks and proposing the blocks whenever required. Now today, the most important thing for us are block proposals, because that's where the whole concept of pre-conformations will be built upon. So how exactly block proposals work in taiko or in a base roll up so well when you're making a transaction using any kind of standard wallet it goes to the mempool or the public mempool which is offered by taiko geth and every few seconds or depending upon what algorithm the proposer is using, transactions are fetched from the mempool. And this transaction batch forms the actual delta.

And when you're calling the grow up inbox contract, you're basically calling a function, which is proposed block, and you're just passing this delta along. Now you might be wondering, well, that's the delta, fine. Where's the transition? So in Tyco, it's a two-step process. The delta is gone, and now we have the Tyco prover, which comes in later on and just says, okay, remember that delta that was pushed a few seconds ago or a few minutes ago?

You see, this is the transition that that delta causes. And since Tyco is a ZK rollup, it pushes a concise proof along with it, like, okay, this is the transition, and this is the proof that the delta caused this transition. Now the most important aspect, Tyco driver. So once these L2 blocks are put on L1, there is a block proposed event that is released, which shows that, hey, okay, this L2 block was put in the L1 contract. And whenever that block proposed event is released, Tyco driver listens to it and advances the head in get.

Advancing the head basically means you're formalizing and putting an L2 block within the L2 network. And this is when the wallets end up getting the transaction receipt or the confirmation. So you see, the catch here is that Tyco driver only receives the block proposed event every 12 seconds. That means when you're making a transaction on Tyco, you get a transaction receipt after 12 seconds, which is huge. That's not ideal for a rollup or a scaling solution.

And that's very evident from the Dune analytics graph of Tycho's block times. It's average between 12 to 24 seconds, which makes sense. It's inheriting L1 block time. That's not ideal at all. So we need pre-conformations.

And pre-conformations is not something new. We have already had it on Arbitrum for a long while and several other roll-ups. Again, show of hands, how many of you have transacted on Arbitrum? And when you transact on Arbitrum, you basically get a transaction receipt in a very small period of time, like half a second, one second, sometimes two seconds. But the point here is that Arbitrum only posts blocks every two minutes on L1.

So how are you getting this transaction receipt immediately? It's because that's a pre-confirmation. They're giving you a promise that, hey, see, this is the receipt, and we will be putting this on the L1 eventually. In Tyco, you have to wait for it to be put on the L1. But, well, this gives better UX for Arbitrum and bad UX to Tyco.

Now what if we want to put pre-conformations on Tyco? It's really tricky. Because in the case of Arbitrum, we have one server, literally one server in one corner of the world, just running, ordering transactions, providing pre-confirmations. Easy. In the case of based rollups, the sequencer is changing every single slot.

The proposer changes every single slot. So, well, the sequencer changes every single slot. And then, these days, we don't have the proposer building the blocks. The blocks are actually built via a PBS pipeline, like MEV Boost by Flashbots, where builders build the blocks for you as the proposer, and then you just propose the block, whichever builder gives you the highest bid, you just take their block and propose it. You don't even have any control over what's in the block.

So how exactly will you put in base preconformations with three layers of complexity? Well, we have done it and let's start with the design principles. Maybe a quick round of questions if anyone has any questions. No? Okay.

Take it over. Alright. Great, thank you. Okay, so the first thing we wanted to do was we wanted to not introduce centralization again. And the way we wanted...

The idea here is that if we wanted to introduce centralization, we wouldn't have built it as a base roll-up in the first place. Then how are we going to solve this complex problem? So let me explain how gateways work first. So gateways are basically centralized servers that expose an RPC for the user to be able to provide them that pre-conf. The user sends the transaction to the RPC, and then it selects which transactions it wants to pre-conf, and then it proposes that block to L1.

Of course, the confirmation receipt that goes to the user is given in a matter of milliseconds, between 100 and 200 milliseconds, which is very fast. Of course, the UX is very cool, but the compromise is very high. Now, also, there is another concept here in pre-confirmation that is important, which is not all validator has signed up to become pre-confers. And because of this, you sometimes have some validators who have decided to register as a pre-confer and some others that haven't registered. So the gateway can provide pre-confirmation for users, and it not necessarily will push a block, a proposed block for the L2 on this slot, but it could potentially push it here.

And the way to do this will be explained in a later stage when we talk about forced inclusion lists. All right. The other thing that we wanted to focus on, which was important for us, is that we wanted to use the existing transaction structure, the existing wallet. We didn't want to invent a new complexity to the already existing situation when you are sending transactions through wallets. So some suggestions in the pre-confing space were like, oh, we should potentially put an inclusion pre-conf fee premium.

So like what are you going to pay the pre-confer so he can provide you with this fast service? And the base fee per gas for that as well. Or, for example, an execution pre-conf, yeah, it's basically very similar to each other. They're all the same. So what we decided is, no, we're going to choose something that is basic.

So we're going to choose the same exact EIP 1559 fields which is the priority fee. So the priority fee pays for the pre-confirmation, the proposing and the proving of that transaction. And the user does not have to worry about all of these complex things, other things. Okay. It's not moving.

Okay. Alright. So I'll start now explaining what we designed. So So, in Tyco, like I explained, we have the, in Tyco, we have that Tyco client and we also have Tyco GAT. In Tyco also we have, before these, before we come to these, we have the contract that receives the block proposals.

And so what we did is we added something we call a pre-conferring node. And that sits between the proposer and the contracts. And we added some contracts. One contract is the pre-conformation service contract that basically receives the blocks that are coming from the pre-confer. And also, we added a re-staking contract that will basically allow the proposers to register as a pre-confer.

And by this, these proposers, whichever they are, any validator, can basically just run this set of software as a sidecar to whatever they're running for the validator. So alongside L1, you're just running these three Docker images three docker images, docker containers, and then you are able to pre-conf transactions when your slot is up. So how does this exactly work? So we have a loop that happens every three seconds. When you are chosen as the pre-confer for the upcoming slot, what happens is that you as a pre-conferring node will fetch the transactions every three seconds from the Tyco proposer, which will basically fetch them from Tyco get.

The user will have sent this transaction to the mempool, so there is no centralizing aspect here. You don't have to connect to a specific endpoint to send the transaction. And every three seconds, the pre-confer will sign this batch of transactions that it has received from the Taiko proposer, and then broadcast it to other pre-confers through P2P. Oops, okay. Okay, permissionless, okay.

So here we look at, okay, so how do we choose which of the registered pre-confers are going to be used or have the right to propose these blocks? And this is when we use the look-ahead that is provided by the consensus layer to know which exactly is the proposer that has been registered in the upcoming 64 or like in this epoch and in the epoch after. So in consensus layer in beacon chain you can query the CL client for the existing epoch, the current epoch, which proposer, which validators have the right to propose and for the existing epoch, the current epoch, which proposer, which validators have the right to propose and for the upcoming epoch. So it provides you with a list, 32 long list of after you specify the epoch that you want. And so basically what we did is that we made the preconf node fetch this list from the CL client and push it to the preconfirmation service.

And this way we know, for example, that since this proposer is not registered, this proposer is not registered, we know that this proposer is registered, so then we choose this proposer to be the one who is pre-confining those blocks. This thing doesn't always work. Okay. So then there is like, with any system, you have to have incentive to act correctly. Some systems depend on only rewarding good behavior.

Some systems depend on punishing bad behavior. Most systems, or a lot of systems, depend on doing both. So in this case, the pre-confer gets the pre-confirmation fees and the proposing fees. In return, he needs to pre-conf and provide good information and honor the pre-confirmations that he gave to the users. The way we check that is that in the case, the pre-conred node reveals the signed malicious pre-conformation.

The way it's done is that, so let's say I pre-confed a batch of transaction, and then I didn't end up pushing this batch of transactions on chain. But I have already broadcasted that I have pre-conf this batch of transaction with my signature. So what would happen is another pre-confer that was listening on P2P would then pick this signature with the batch of transactions and push that to the pre-confirmation service contract. The pre-confirmation service contract would check if this is a valid signature for the pre-confer of the slot and if it is then it will go and ask the restaking or staking contract to slash the signer. And in this case, yeah, there is also the slashing for the incorrect look ahead because you fished the slashing for the incorrect look ahead because you fish the look ahead from the CL but how does the EL know that this look ahead is correct?

You can use 4788 EIP which basically provides you with the CL beacon route and using that you can push a proof if the look ahead is incorrect and the pre-confer who sent an incorrect look ahead would be slashed. Okay. So before I move on if you guys have any questions it's good to have them now. So yeah please go ahead. Before I move on, if you guys have any questions, it's good to have them now.

So yeah, please go ahead. I have two questions. First one is, based on, I'm not familiar with 4788, but could you not, like, can it only prove that you can look at it as a law? Yeah, so the thing about 4788 is that it provides you with the beacon root of the parent block and not the current block. And because of this, when the look ahead is pushed, I cannot in that moment verify its correctness.

But after one single block, I can, with the proof, using 4788, make sure that if it's not correct, that it is not. So this is why we opted for this. In the case that it was possible to verify, we would have potentially opted for pushing the proof with the look ahead. The problem with that normally entails that you would pay more because the proof needs to be verified on chain in every single submission. Whereas if you do it in a fraud proof manner, only when someone's acting maliciously that you need to do this.

So the cost drops dramatically. And there is precautions to this. So whoever is submitting the look ahead will get rewarded submitting the proof, the fraud proof for the look ahead will get rewarded for this by the slashing of the other pre-confer. Other questions? Yeah.

Okay. Let me try to make this work somehow. Okay. Work please. Okay.

No. Okay. Yeah. Over here. Sure.

I mean, here. This one is now opted in and this one is . Yeah. . Okay.

So this is probably not mentioned in this presentation, which is a problem. Hey, sorry. Basically, based rollups depend on giving the user the ability to always push transactions on the L1 permissionlessly. And that means that there is no one who could prevent the user from pushing a transaction that could invalidate future transactions that have been pre-confed that will be pushed later that have been pre-confed. And this leads to execution pre-confs not being able to be provided.

And this leads to execution preconf not being able to be provided. And the only solution that we have to that is delayed inbox. So preconfers are able to push directly to the Tyco smart contract to propose blocks whereas normal users who don't want to use the preconfing system that is built and want to push directly to avoid potentially censorship by the pre-confer, even though this is a decentralized solution, it could potentially have some type of censorship. So if they push their transaction to this delayed inbox, what happens is that we wait for the pre-confirmations to land and then we include those transactions that have been pushed by the user. So in this instance, just to be clear, any transactions that come in this slot will go to the queue and will not be proposed.

No, it will not be denied. It will go to the queue. Yeah, delayed. Yes. It will be delayed after the pre-confer has pushed his pre-confirmation, and then it will be included.

What if my pre-confirmation ended on L1 state, which is like a really nice component of basic L1s? Yeah, no. I could expect a pre-confirmation with interacting with L1. Yes. So if we engage composability in here, then it could, yes, any L1 state change could potentially affect this L2 transaction that depends on it.

And this is not a problem that the solution is trying to solve, unfortunately. Yeah, I don't think, like, as of now, there is, potentially, there's some people working on this, but I'm not aware of any solution to this particular problem. This is a very good question. Thank you, sir. Any other questions?

Yeah, go ahead. Does this require at least one recall first? Yeah, so I think this might be talked about in a later stage, so I'm not going to touch on it more. But there is a way for choosing a random pre-confer in the case that there isn't a pre-confer available for the next 64 slots. Any other questions?

Yeah, go ahead. The gateway. Okay. So the gateway basically buys the right from the proposers that have registered at Pconfer to propose at a certain slot. I don't think so.

No, they can have varying tips between one gateway to another. The problem is that with gateways is that the gateways will have to compete. In the beginning, we might have a couple of gateways out there. The problem with that is that people normally end up converging into a couple of gateways that then would have a monopoly. So like two or one gateway that would then be dominating.

Because the idea here is that if a gateway cannot secure validators or proposers that are willing to sell it, to sell the gateway, their right to propose these Tyco transactions, the gateway cannot operate. Do they have a business where pre-confirmations are built on other pre-confirmations? gateway cannot operate. . Yeah.

So you do. And that's why we have the P2P. I'll explain that in this slide. So when we said here, sorry, this thing is not, okay, yeah, so when we said that the preconf node every three seconds batches a transaction, takes a batch of transaction and signs it, and then it broadcasts the signed preconfirmation preconf blocks on P2P. This is important because anyone who's listening can do a bunch of things.

First, they can advance the head of the TychoGath so people can keep up with these pre-confirmation. Are you moving to a safe head there? Sorry? Is it moving just to a safe head? It's not a safe head, no.

It's not even a safe head at this point because it's basically a soft head, No, it's not even a safe head at this point because it's basically a soft head, very soft head. Because as long as it hasn't been proposed on L1, it's not fully safe. I mean, there is financial precautions to the pre-confer if he doesn't obey or honor these pre-confirmations, but software can always fail or they could potentially have other incentives. So it's a very soft head, but at least you get consistent block times, which is a better user experience than what you get right now. I mean, Anshu said that transactions normally take 12 seconds, and on Tyco, sometimes they take 20 seconds.

So there is some kind of extra delay. It's a very long time. Any other questions before moving on? Sorry, I just wanted to understand the consensus at the P2P layer that you were describing. What do you mean, the consensus?

So my original question was, if you have pre-confirmations being built upon by... Sorry, new pre-confirmations being built upon by, sorry, new pre-confirmations being built upon the state of previous pre-confirmations, how does that, like consensus is needed there between two different proposals? So the pre-confer that comes, so let's say that, okay, let's say that all of these are pre-confers. And this one is a pre-confer and has been pushing, it pushed basically four blocks. It pre-conf first one, second one, third one, fourth one, and then it basically just went and pushed it to L1.

This one would be listening to these pre-confirmation batches on the P2P and would receive them. And it would just wait for a confirmation that they have landed on L1, and then it would start building on top of that. Would the middle one be accepting pre-confirmations before it's been posted to L1? NOAM CHOMSKY- No. Because since it's pre-confirmation, depends on the state of what happens in that chain here.

So it can't do that. Or it will collect, I mean, it can, but it will collect a bunch of transactions that has been already included, for example. So it would potentially lose that space on the L1 side. And also, if it does not, if it sees, for example, pre-confs, a bunch of transactions that then already has landed, the execution pre-conf is not honored, that doesn't mean that it will be slashed. It won't be slashed in the system because the inclusion preconf is still there.

But it will lose that. And if it does not include them, it will be slashed. So in both cases, it's kind of losing something. Of course, non-inclusion makes it lose more. So it would include them even though they're already processed and will be invalid if they're included again, but at least it won't be slashed.

Yeah, so this is the consensus. I mean, this is a problem with also varying types of pre-confs because you can always... So in the system right now we're trying to build with pre-confirmations is that we're trying to avoid a singular solution to dominate. So there is multiple solutions. So there is the gateway, there is what we're building, and there is multiple ones.

So if each one kind of needs to build on the other one, it needs to wait for the state of L1 to be updated to start building on top of it. Additionally to that, if a user pushes a transaction directly to L1 without pushing it through a pre-confer, then that also changes the state. So it doesn't make any sense at all to start building pre-confirmations before knowing the exact state on the L1. Thank you. Okay.

Let's hope this marker starts working. Okay. Yeah, so we talked about slashing. Now, so as we said, the pre-conference needs to include and propose these batches of transactions on the L1. But if this validator is selling his right to build the block through PBS to a builder, it cannot accomplish that because it has no control over the content of that block.

And the solution we found to that is that we would modify the EPBS pipeline to accomplish this exact goal. So the preconf node would go and tell, basically, the MEV boost that there is a constraint on the builder and that the builder needs to include a bunch of L2 blocks, which are basically a couple of L1 transactions, or it could be one L1 transaction and their blobs. And it should include them. And that's why the PBS relayer would return with, okay, yeah, I can honor that. And they build a block including these transactions at the end.

And we propose the L1 block. This is the way that... And currently we're using Bolt Smith Boost because they have that constraint API already implemented. So we didn't want to implement, re-implement the wheel. But of course, there is also CommitBoost, which can have that Bolt MIFBoost module built on it.

And you can have it. For more details on those, please search them on Google, CommitBoost and Bolt MIFBoost. Both of them, they have open source GitHub repositories that you can look at. Pre-conference selection, I think Anshu will take over here. Thank you, sir.

Thank you. Do you want the mic? Yeah, just this one, yeah. Okay, so now you have a good idea of what the overall design looks like. And let's talk about pre-conferred selection, because we did speak about how we want the L1 proposer to be the only one who can pre-conf and then propose the L2 blocks in a particular slot.

Now, this is actually a very hard problem, even though it doesn't look like, because at Ethereum, we love patching things up. And in the process of patching things up, we develop new problems. So when ETH moved from POW to POS, what happened was we introduced a new layer, the consensus layer, besides the existing execution. So earlier it was merged into like one single thing and now we have it separate. We have a consensus layer which manages the POS part and we have the execution layer where, which is what we developers usually handle when we are deploying smart contracts or interacting with Ethereum using a wallet.

The problem is the consensus layer is where the proposer's identity lives. And that has a BLS signature scheme. But the execution layer where all the inbox contracts are, where all the transactions are made, that has an ECDSA signature scheme. And that's a big problem. How do we make a connection between both of these?

There's no way to make a connection. So what we need is we need a BLS to ECDSA mapping. So let's say I'm an entity, I have an ECDSA address, and I run a thousand validators with thousand different BLS public keys. I need a way that I can prove that I own those thousand validators. I can show it to the registry contract.

So we have the pre-confirmation service contracts. I actually have three subcontracts, the pre-confirmation registry, which we'll be dealing with in this slide, and two other contracts that we'll be taking up later on. So this entity needs to prove that, hey, I own these validators, and I actually have the right to propose an L2 block in a particular slot. And how exactly do you prove ownership of a key through signatures, right? So we have this signature format here, which you can see it basically has the standard thing like having a chain ID, and then validator op is basically either 0 or 1.

If it's 0, you're removing a validator from your list, 1 you're adding. And then there is an expiry and the actual pre-confer. So in here, the pre-confer in the signature message is the ECDSA address that I'm claiming. That is claiming the ownership of a BLS address. So the ECDSA address just pushes a signature, and the contract just verifies that the signature is correct and this BLS public key actually belongs to this ECDS key and inserts it into a simple map.

Now the execution layer has no native way of verifying BLS signatures right now, but very soon in the next upgrade, the Pectra upgrade, a new precompile is being added via EIP-2537. That's where all the discussion has happened. And this precompile, or a set of precompiles, three precompiles actually, will help us verify BLS signatures. Now, these are really expensive because for verifying one signature, we need to spend like 300K units of gas. That's really expensive.

So in our next POC, we are actually proposing an alternative where in the case of BLS, there's a great feature, and that's aggregation. So if you have 1,000 validators, what you can do is you can have 1,000 signatures off-chain, then add all of these signatures up. It's basically elliptic curve addition. You add these signatures up, and then on the contract, you just have to verify one signature. So essentially, you can add, like you can put thousands of validators in your registry via just one signature and just a bit more than 300k gas, which is amazing.

And this is what we will potentially be putting in the next version. But yeah, right now it's one-to-one, single address, single signature every single time. So how is this used to construct the lookahead? Because the BLS lookahead is absolutely useless on the consensus layer. We need an EC-DSA lookahead because the BLS lookahead is absolutely useless on the consensus layer.

We need an ECDSA lookahead on the execution layer. So every single time we know that only this ECDSA is supposed to propose. No other ECDSA can propose an L2 block. So in this case, it's kind of simple. The preconf node has the logic.

The preconf node can take a look at the consensus layer because the preconf node has the view. The preconf node can take a look at the consensus layer, because the preconf node has the view of both the execution layer and the consensus layer. So the preconf node pulls all the proposers from the consensus layer for the next epoch. Then it fetches the associated ECDSA key from the preconfirmation registry, because we have the BLS to ECDSA mapping there and it just matches it. This BLS for the next slot belongs to this ECDSA.

This one belongs to this and it creates the entire lookahead. Now in our design, we have assigned the duty to push the lookahead, of pushing the lookahead to the first pre-confer of every epoch ahead to the first pre-confer of every epoch so the first pre-confer of current epoch will be pushing the look ahead for the next epoch and they are basically bounded by this duty they must do it if they well it kind of there's no option of not doing it because the contract expects you to provide that and this is what a simple look-ahead, like one of the nodes in the look-ahead array or mapping looks like. I'll get to what the look-ahead, what data structure we actually use. But in here, the timestamp, the second field and the fourth field makes sense. The timestamp is the timestamp of the slot, and the pre-confer is whoever is supposed to be pre-conferring in that slot or proposing an L2 block.

We have another field, fallback, and previous time stamp. Now, what are these? Well, the previous time stamp is just a link to the last look-ahead nodes timestamp. What this allows us to do is arrange the look-ahead as a link list within the contract, or sort of a link list. So every look-ahead structure is an item in a map, and the previous timestamp just points to one of the other timestamps.

What this allows us to do is have advanced proposals because not every proposer will be opting in. And also not every proposer will be registering and exposing an ECDSA address. Some are just not interested in pre-config, right? So in this case, we cannot just have an entire epoch be empty if there are no pre-confers or if there are very few pre-confers. We need to do something in the empty slots.

And what we do is we allow the next chosen pre-confer to pre-conf in advance. And because of this link, we can do that with a simple check, a simple if condition. That's why in here you can see that P2, pre-confer 2, can pre-conf in the second and third slot already. And P3 can pre-conf in three slots in advance. That is made possible because of this linkless design.

Finally, if we have an epoch where there are no preconfers at all, and that's very much possible if none of the proposers in that epoch has opted in, we don't have anyone as a pre-confer. Then we have to select someone randomly. And that's a very simple selection. Like, we need a source of randomness and apply simple modulus to select one of the indices of who is exactly going to be the pre-confer from the registry. And the source of randomness comes from the beacon root contract.

So we, as far as as far as i remember we basically end up choosing the beacon root of the first block in the last epoch because this gives us a pre a deterministic idea of who's going to be the random pre-confer in the next epoch so we use that as a source of randomness and we just use that to pick out a pre-confer. And this fallback pre-confer has an advantage, and that is it can pre-conf in every single slot of this epoch because no one else is there to pre-conf. Yeah? Yeah? Sorry, I have a question.

If the pre-confer is not in the epoch, doesn't that mean they're highly unlikely to be In six months? Well, but we won't be stopping the system for six months, right? Yeah, so... If can uh get in here I understand the question um so you're asking is since the pre-confer does not have the right to pre uh to propose a block in the next epoch for example and we chose it at random um how will it be able to honor these pre-confirmations? And the answer to this question is that it might not be able to honor the pre-confirmations.

But it will not be slashed if it does not honor them in this case because it's a random picked pre-confer. And also, we thought about this like, OK, maybe it shouldn't be providing pre-confirmation, but this would be a very bad UX. So shouldn't be providing pre-confirmation, but this would be a very bad UX. So we'd provide the pre-confirmation, we would send them in the P2P on the mempool, and potentially someone will pick them up and include them if the fee is right. And this was like the mechanism that we wanted to do.

So what Tyco is doing also is that they're using this fallback mechanism to say, okay, if there is a no-up-recon for a register, then the next epoch, then we are going to propose just to keep the liveness of the chain. And of course, this proposal will go to the mempool and someone will pick it up. But if someone intentionally is censoring these transactions and there is no mechanism to force the builders to include them, then they will potentially not be embedded in time. Yeah. Thank you, Emma.

And one thing to note is that throughout this POC, we have never touched the Tyco contracts, although eventually we might to add that delayed inbox. But in here, we have tried to not mess around with the Tyco contract. And what our task manager does is it simply routes the blocks that are being proposed over to Tyco contract. So because of this, the prover architecture doesn't have to change. That's the best part.

Nothing in the prover has to change and the proposer also needs very minor modifications because the original contract, original contracts of Tyco have barely been changed. Go ahead for the next step. Thank you. Thank you. Okay.

So now we're going to go back to The pre confirmation loop that we discussed that every three Seconds we go in a bit more details. I hope this clicker Works. Okay. I'll just stand here. All right.

So first we start with The normal event loop for tyco. So what tyco does is that once Every slot it pulls the pending transactions from the Mempool, tyco proposes and forms the block and then pushes it Through the blob to the roll up in box contract through that proposed block function. Very simple, straightforward. What we have with the preconf solution is the following. So we have the preconf node every three seconds requesting from the Tyco proposal a batch of transaction.

Tyco proposal goes and fetches those batch of transactions from Tyco get and forms a batch, gives that batch to the preconf node and the preconf node then goes and then um uh pushes this transaction to the P2P like we said the batch of transactions to the P2P and of course this also only happens after it made sure that it is the pre-confer for this specific uh for the for this slot and or an upcoming slot that is very near. So this is the new loop. So what do we sign when we provide the pre-confirmations through P2P? What's the signature? So the structure that we use is we use the block ID because we need to commit to a specific block height or that pre-confer could potentially sandwich transaction if it wanted to.

If we don't commit to a specific block height that it needs to propose this batch at. Also the chain ID in case we have multiple chains and transaction list hash which is basically just a hash of the RLP encoded transaction list. I see there are some hands for questions. Yeah, go ahead. You have the mic?

It's fine. Just raise your hand. Yeah, so three seconds was just a conservative random number that we chose at this point because we weren't Yeah, so three seconds was like just a conservative random Number that we chose at this point because we weren't sure How fast the system would be, the latencies, all of that. What we're going to be working on later, as we will see in one Of the slides, is like getting that number lower and seeing how It's going to behave and how it will work. We will talk about that in later slides Yeah So the pre-confirmation structure We saw it And then there is the pre-confirmation object That is sent in P2P Because the pre- object that is sent in p2p.

The pre confirmation structure is the one that can be pushed as a proof for fraud proof. But here we need to when we are pushing the preconf batch on p2p we need more details. That one is not enough. So we have the block height and the pending transaction list, the whole list and the pre confirmation structure enough. So we have the block height and the pending transaction list, the whole list, and the pending transaction bytes.

I'm not entirely sure what that is for. And the proof of the preconf message. And this is what ends up being sent exactly in the P2P. And the reason we need the batch of transactions is because we need all the other pre-confers or all of the other participants in the network to be able to advance the head with this batch of transaction. And we also need them to be aware of this so when their role of pre-confing comes along they know that okay these transactions have been already pre-confed and potentially will be proposed in the next one and in the in the previous one block before we start pre-confing ourselves.

So when when a preconf node receives the batch of transaction from The p2p once it has been preconfed, we currently the way It works in tyco before the preconf is that we get an event Which is called block proposed from the l1 and that goes tyco Driver is basically subscribed to this specific event and advances the head once it receives this event which means that the user will get a transaction receipt every 12 to 24 seconds. And this is the main point that pre-confirmation our pre-confirmation solution is trying to alleviate with this design. So now the pre-confirm node can, once it receives the pre-conf message with the pending transaction list, it can provide it to Tyco driver, and Tyco driver can basically advance the head of Tyco geth in around three seconds given that we choose a three second confirmation loop time. All right. So the non pre so there is the pre-config node so this is the previous slide was about the pre-config node.

So this is the previous slide was about the pre-config node. So once it pre-confs the transaction list, it does this. And there is also the non-pre-config node receiving this message through P2P and then sending it to Tyco driver to advance the head. So the whole network advances together and not a single one of the nodes in the network. So we already kind of discussed this.

So we have two ways that the pre-confer sends his transactions or the L1 transactions that will basically push the L2 transaction batches. So first we said, okay, let's say that we have a pre-conference slot number five. And this pre-conference is on duty for slot number one, two, three, four, and five. That means that they need to pre-conft a lot of batches in these slots, and then they can force include them in slot number 5. That's not a problem.

That's easy to do by using the PBS software like we explained. The problem arises if there are sparse pre-conforts. There isn't a lot of pre-conforts, and that would mean that potentially one pre-confer could be in slot number 42 and he's responsible for slot uh i don't know five up until 42 and this would mean that he needs to push a lot of transactions in in his slot if we follow this model so instead we said okay maybe we should just push all the pre preconf transactions right away to the mempool. So we get batch A, batch B, and we just push them directly to the mempool. And at the same time, we put them in a queue, in a cache.

And the idea of this cache is that once an L1 block comes and it has those batch transactions that has been pushed here in it, then we can remove this batch from the cache. If that doesn't happen, then that batch of L2 transactions stays in the cache. And then once it is, yeah, and so basically if it's included, we clear that batch from the cache. Okay. So on the proposal slot, we take the ones that hasn't been included, that we push to the mempool and hasn't been included yet, and we make sure that we push them through the constraints API of Bolt Smith Boost to be force-included by the builder.

And then once we receive the L1 block, we have the guarantee from the relayer that these transactions, L1 transactions that contain the L2 transaction batches are included then in the L1 proposed L1 block. And she will talk about slashing and yeah. Okay. So now comes the pre confirmation service manager contract which we haven't spoken about yet. And this is a very interesting contract because what we have tried to achieve with this POC is a really flexible interfacing because we have a number of restaking solutions right now out there in the market.

We have Eigenlehr, we have Karak. We might also have our own staking contract later on if a community decides on one, which is actually going on. A discussion is going on on having a unified registry. And that calls for having some kind of a middleware contract so that later on the core logic doesn't have to be changed and the staking is just abstracted away to a different set of contracts. And that's what we achieve with the service manager.

It's essentially like a middleware that ensures that only those proposers who have a required stake are allowed to precomp or propose in the upcoming slots. So what kind of slashings do we have or when exactly do we slash? Well, one time that we do slash is when the lookahead being posted is incorrect or the lookahead posted is incorrect. A basic version of this is that when you have, like, let's say for a validator with BLS public key B5, in the lookahead mapping, sorry, in the BLS mapping, you have E4 as the associated individual who owns the B5 key, but the proposer who pushed the lookahead placed E2 as the associated ECDSA key, which is factually incorrect. Now, this might look like an easy way to just compare, hey, okay, both of these are not really equal, so why not we slash the person who posted a look-ahead?

But it's kind of tricky to prove this inequality because we have B5 and E4 from the pre-confirmation registry, but in the task manager, we don't have access to who exactly was the validator and its associated BLS key for the current slot or any slot that is incorrect. We don't have that information in a simple way. And what we need to do is we basically need to have this kind of a match that, okay, B5 from the pre-confirmation registry and B5 in the current slot, both of them have different ECDSA keys. And then on the basis of that, we slash the poster of the lookahead. So, well, there is a way to do that.

And I kind of have to make a correction on my previous statement that there is no connection between the consensus layer and execution layer. Well, there is, but it's kind of a complicated connection. And that's through the beacon block route, which I think Emma touched upon briefly. So you see, just like the consensus layer has blocks, sorry, the execution layer has blocks that we deal with, the consensus layer also has beacon blocks, because it's the beacon chain. And each beacon block has a state root.

And if you unravel the entire state tree, then you'll realize that in beacon state, we have the validators field, which contains all the validators or the proposers. And that includes their unique index, as well as their BLS key. So what EIP-4788 proposes is that we get this eventual Merkle root. Like, if we Merkle-ize this entire beacon state and then eventually the beacon block, we eventually get a 132 byte long Merkle root. And we make this available within the execution layer.

So the thing here is that there's a problem, and that's we only have access to historical roots. We don't have access to the current slots proposer because, well, the consensus layer is yet to create the block, so we can't really know who the proposer is. So we have to slash or prove that a lookahead is incorrect optimistically. yet to create the block, so we can't really know who the proposer is. So we have to slash or prove that a lookahead is incorrect optimistically.

And the way we do it is we wait until the incorrect slot has passed, and we have the root. And once we have the root, we can basically make a static call to this contract, which is the beacon roots contract, and get that beacon root. And then just need to send two proofs so first the proposer or sorry the challenger posts the bls key of whoever was supposed to be the validator of that slot as well as their validator index and along with this it sends two proofs. First is the proof that in this case, if you see, we have a proposer index in the beacon block, but in the beacon state, well, we basically end up having BLS keys of the validators at respective indices. So via a Merkle proof, we have to make this connection that, hey, this proposer index actually belongs to this particular BLS key or BLS public key, and that's the step two.

And then in the next step, the validator or once again, not the validator, the challenger needs to prove that this is the proposer index that is present in the beacon block, as you can see here, the second field. So very simply with two simple Merkle proofs, you are able to get whoever was the BLS key of whoever was the validator in the current slot or the slot that is being challenged. And well, once you get that, you can just go ahead and make, check if this inequality is actually satisfied. If it is, then well, the lookahead slot is incorrect and you can slash whoever posted it. Along with that, we have slashing of bad pre-confirmations, which I think was touched upon by Ahmed.

But in this case, if we want to expand it, we have execution pre-comps that could be bad and we could also have bad inclusion pre-comps. In the case of execution pre-comps, well, the proposer did push the eventual block that he pre-confirmed, but he misordered the transactions or maybe inserted a new transaction that was not actually pre-confirmed. And in this case, what we end up having is that the transaction list hash is mismatched between the proposed block and the pre-confirmed block that was on the P2P. And in the case of inclusion precomps, that's a bit more simpler. We end up getting different proposers for the same block ID because it might have happened that, well, he pre-confirmed, but he never really proposed, and someone else ends up proposing in that particular block height eventually.

So, yeah, these are the two kinds of slashings. I think that was quite a mouthful, so any questions? No? No. Yeah, so in this case, we actually have discovered a few issues.

So another variant, a more simple variant of your issue would be, I pre-conf, and I don't include it, but then for a long period, no one actually includes any block. So what happens is a long time passes and the dispute period gets over. So even though there is no pre-confirmation, there is a pre-confirmation, but there is no associated block. Like the block ID has never really progressed on chain, and that's an issue. But you can't really prove the incorrectness of this.

So we have a way of doing that, and that is, so we might have to go back to, so let's say this is like the slots, okay? So whenever a pre-confirmation is being made, we also include a look-ahead pointer, which basically points to which slot in the look ahead am I preconfing for. So in this way what we have to do is we have to make a connection between the preconfirmation and the proposed block via the look ahead. I think now that answers your question because if we have that look ahead pointer that basically states which look ahead slot have we made the pre confirmation for. And if it lands on at a different time on the L1, we can make the inequality.

Okay, but is it possible that I pre confirm something and someone includes it because they are a proposer before me? Or that can happen because they would be pre-confirmers for that slot before, so I wouldn't be able to even include this as part of the pre-confirmations. I don't know if that makes sense. I mean, not really, because the proposer is, once again, I mean, this is advanced proposals. I mean, you just release it in the public mempool, and it might happen that the proposer does not include it, but then your slot will be coming in.

So if you go back to this slide that Ahmed presented, in this case, when your slot comes in, you clear all those pending transactions that have never been included because the proposer didn't want to include. But your slot has now arrived. So you pick those transactions and you force include it via the inclusion list through the PBS pipeline. Yeah, the other answer to this question is that the previous pre-confer cannot, like, the previous slot, if you're talking about, if this slot is for pre-confer 2 to pre-confer at, the pre-confer 1 cannot then go and push transactions there. Every slot has an assigned pre-confer and only a specific pre-confer can push transactions or batches in those slots.

So the contract will just ignore any batches that arrive from pre-conference that are not assigned to these specific slots. Okay. Perfect. Any more questions? No?

I think we can touch upon the future work now. All right. So first we start with soft blocks. So currently what we do when we advance the head is that we push a whole full block to tyco geth and in this way what ends up happening is that it goes and lands in the canonical chain, and this is normal. And this is why those transactions are then removed from the mempool.

So when you propose the next block, they don't get included twice. So that's one thing. The problem with this approach is that when we are proposing these blocks at the end on L1, we need to propose multiple blocks. So, for example, if I pre-confirm in every L1 slot around four batches, then that means that I have to make four proposals on L1. And this is costly.

Proposers and verification of these blocks is costly. For a block proposal, it costs around 200,000 gas, right? Yeah, give or take. And around 400 for verifying the ZK proof for a single block, give or take as well. could be a bit more than 400 more closer to 500 so every block that we end up proposing is is is adding a lot of cost for proposal and verification so what did we end up with is a solution where when you preconf you're gonna add the batch to TycoGash, push it, and then when you push another batch, what ends up happening is that it gets added to the block instead of being, so it gets appended in the block.

So what happens is that a new block is formed with the previous transactions that are in the block and the new transaction batch and the previous block gets reorged out and then we include the new block. And this keeps happening until the preconf node sends end of preconfirmation or and then this block becomes a standard block and gets pushed To L1 as a whole single proposal. And this gives us the cost saving that we're looking for, But it's still not finalized. It's something that we're going to hopefully work on the next Couple of months. Another thing, like our friend here asked about before, is the Slot time for the L2.

So currently we have a constant three-second block time. And what we're looking for to accomplishing is one-second block time. And it's not that this is not possible currently. It just hasn't been tried yet. And we're not sure what limitations we're going to hit with the P2P, et cetera.

Yeah. And then in the last one, I think you will talk about it. Yeah. So when I was talking about the pre-confirmation Service manager contract, I said we are trying to make it Like a middleware so that as and when we want to change the Restaking service change the restaking service or the staking service, we can just swap it out and use a new one. And in regards to that, the community is planning to launch a universal pre-confirmation registry.

So chances are there will be many more based roll-ups down the line, not just Tyco. And when you have so many based rollups, it could be the case that one proposer wants to propose or pre-conf for multiple based rollups, but it doesn't really want to register continuously because that will cost him a lot of gas. And also, it won't be that credibly neutral because it might be the case that every rollup starts up its own staking service. And that's not reasonable for the proposer, and that's a waste of ETH, not a good use of collateral. So in this case, there will be a universal pre-confirmation registry where any proposer who wants to become a pre-confer can go in, register the BLS mapping instead of being in the protocol-owned registry, it will be here in the universal pre-confirmation registry.

Along with that, so the slashing condition opt-in, this is a very important aspect. So the roll-up protocol, like whether whoever makes another base roll-up, might want to have their own set of conditions based on which they want to slash. So maybe they don't want to slash inclusion precoms. They want to just slash execution precoms. So they can define their own slashing conditions and then only have those proposers who have opted into these slashing conditions be preconfers for their rollup.

So yeah, this is still an ongoing discussion in the community, and eventually we will be speccing it all out and releasing it, but it's going to be a while. Well, that's it. Thank you so much. Okay, there's a question here. How do you see this integrating into existing KYC systems or rather the path to scale and adoption on the side of users and institutions?

I'm not sure that's a question for this session. Yeah. Yeah. All right, so any questions? Final.

All right, so any questions? Final? How do I evaluate the security of a free account? Say, I'm sending $10, I'm probably not going to get it. If I send $10 million, how do I know if they're staying?

Do I wait? Do I know? Right. So what you're asking about is the fair exchange problem. And this is something that our research team has been looking into for quite some time now.

As of now, we don't have a solution for the fair exchange problem. And I think most of the existing or proposed solutions depend on a reputation system as of now, where if the pre-confer or the gateway providing the pre-confirmation is acting maliciously, this would affect the reputation in a bad way, and they would potentially be cut out of pre-confirming for the specific protocol they're working on, and this would potentially lead them for losses. So the reputation based system is being proposed for now but we are working on a non-reputation based system where there is some oversight over how the pre-confers are acting and if they are actually pre-confing in the correct time, providing pre-confirmations in a timely manner without delaying the pre-confirmations coming from the users or reordering transactions with this delay to just generate more MIP or profit for themselves. There's another question here. What kind of slashing conditions do you see?

Is it a penalty or more tougher? So I think right now our slashing condition is very straightforward. We just slash the entire stake, which is not ideal, and it's definitely not going to be this eventually. I think there is one proposal by the research team and that's we have, let's say, slashable tickets. So for every pre-confirmation that you provide and every validator that you register, you have a fixed amount of stake.

So for pre-confirmations, let's say you are staking one ETH for every pre-confirmation that you provide. And once the pre-confirmation that you provide, and once the pre-confirmation is settled, you can basically reuse those tickets. But if you mess up that pre-confirmation, only that one ETH amount will be slashed, and not your entire stake. So this is open for discussion, and once again, I think this will be a part of the community-led discussion of how seriously we want to slash a malicious preconfer. How do you think distributed validator technology fits into your preconformation design?

Do you think it could make it much more secure? Have you guys looked into that? So in DVT, I'm not entirely sure about the block proposal and how it works exactly. So I know that for the attestation, multiple, like three out of four nodes, they need sign, basically, to get a proper BLS signature. And I think it's kind of the same for the proposal, but I'm not sure how they choose which one of the nodes is the one who is responsible for forming the block.

So honestly, no, we have not looked into how DVT would interact with this protocol at this moment. Because also DVT does not form a significant share in the market of proposers as of now. So it might not make sense for us to look into it in a serious, um, in a serious manner. But potentially if it becomes more popular, then yeah, this would make sense. I mean this is not yet on main net, because firstly, we don't even have the pre-compiles yet.

We need to have the Pectra upgrade. So it's running on testnet, on Helder testnet. Have you heard of Helder testnet? It's a devnet, which was released during ECC. So Tyco already has not the final version, but one of the intermediate versions running on Helder, providing pre-confirmations But once again that's a dev net So it's only the validators that Tyco is running But yeah this was tested Using 300 validators And it worked great Thank you How much do you pay for the pre-conference?

There might be multiple base roll-ups and they might be compete for one pre-conference. If you can speak to the mic because I didn't hear half of what you said. Yeah. How do you decide how much you pay for the pre-conference to propose the roll-up blocks? Because there might be multiple base roll-ups for the slot and they might be competing for the same pre-conference.

So for the payment we have, we have lifted up for the market and because we decided that the priority fee will be used, then basically the pre-confers will just not pre-confirm transactions that are not profitable. So any transactions that do not have a high priority fee that is paying the pre-confer enough will just not be included because the pre-confer has the incentive to include as many transactions as it can in the block to potentially extract as much value as possible from the blob that it's pushing because the blob has quite a lot of space. So the more data I can fit in a blob, which is basically now free, one way to get a blob as of now, the more I can make money. So we lift the pricing to the market to decide. There are some research that is going on in the space by Connor and Lynn from Nethermind, and there's another guy I think called Finn Finn yeah I don't know their full name so I apologize for that about the economics of pre confirmations and the pricing for pre comps etc and this work there is a lot of talks that Connor Finn and Lynn has been talking about pre confirmation I advise you to go check the recordings for these talks by these people.

They touch exactly on what you asked about. Thank you. How do you think the award-winning team affects the likeness of the program? So do you think it improves it? Is there a reason for concern?

Personally, like MAV or not MAV, the protocol works with local built blocks and also works with forced inclusion through PBS pipeline. The only problem here that I see is that if relayers and builders decided that they're not going to adopt the constraint API that we talked about because it basically reduces their income because pre-confirmations are not profitable enough compared to what they can include other than these transactions, then we would have a problem. But as of now and as we heard from our partners, is that there is a lot of talk and the relayers and builders are agreeing to add the constraint API to the EPBS pipeline so they would be potentially including pre-confirmations. To add to this, I think we also have plans for L2 MEV extraction. When that is added to this, I think the dynamic changes a bit.

Basically since we have currently three seconds and potentially one second block times for the L2. In this one second, you can, the pre-confer still at well can reorder these transactions. But we would not expect every pre-confer which is basically just an L1 validator to have the sophistication needed in the software and in the hardware to be able to support such ordering in one second. I think what's going to happen is that there will be a PBS pipeline for L2 blocks if this protocol gets adoption that tries to extract mev from these L2 blocks in this one second slot. Sorry, last question.

What are the latency figures that you guys have regarding like the block transmission from the pre-conference? We don't have that yet. Because as of now we have only Dev Nets and Dev Nets are basically just kurtosis set up instances that are running on local machines. I mean we have Helder but Helder deployed a hybrid solution between gateway precomps and our solution. So our smart contracts but gateway software basically.

And as of now that's what, no that's deployed in Hilder? Yeah. Okay, yeah. So that's what's deployed in Hilder right now. So it's not the same and we don't have that distribution of sidecars running so we can calculate this latency.

We can do some simulations potentially but yeah reality always is different than simulations. Do we have more questions? All right. Thank you everyone for attending.