Fast Confirmation Rule Breakout #1

Transcript

Okay. Um, so let's get started. Welcome to the first BAS confirmation rule breakout room. Uh, I'm Will. I'm a research coordinator at the EF. Uh, going to be working in very close uh, coordination with Luca and Mle and Julian and a bunch of other uh, individuals. So, we're like really trying to uh, take this research and and bring it to market uh, in short order. And so there's some parallel work streams that are going on. The breakout room being of utmost importance. So working with all the developer teams to make sure that uh you know questions get surfaced and you know additional

research and spec changes uh get modified so that we can take uh proof of concepts and and ship them as production grade uh code. Here's uh as little amount of time as possible. And so in parallel to that, Julie and I have already started the process of reaching out to exchanges and L2s and bridge operators and and people that uh might want to utilize uh this technology and then also working with digital studio to create some marketing resources to be able to bring this to mark, you know, to help bring this to market. And so um yeah, we're trying to move this everything forward as quickly as

possible. But I think it probably uh the most important thing is what is fast confirmation rule? What are the specifics around it? What's the value that it brings? What are the uh trade-offs and assumptions that are involved uh in in this uh in this uh additional set of functionality to a consensus client. So um today we're just going to start off with like a very high level uh presentation from Luca going to be talking about fast confirmation rule and then I believe ML is going to do uh a bit of a a technical uh deep dive into it. So I will kind of uh seed the floor and Luca you wanted to start.

>> Yes, thank you. Hi everyone. Let me quickly um share Give me just a second. Sorry. Okay, great. Can you all see? Yes. Is it the right one?

>> Perfect. Okay. Uh, hi everyone. I'm Lucas. part of protocol consensus. Uh today we thought with Mikail to give you a sort of overview of the confirmation rule both from a theoretical aspect and from specs and so that we are all synchronized maybe some of the things that I'm going to say are already very clear but we thought could be beneficial in some sense to start from zero in this first breakout room. So let me first start by introducing this confirmation rule.

So uh the goal of course here as you might know is that we Ethereum currently only has one canonical confirmation rule which is finality and currently is quite slow until at least until we have a faster finality protocol for for it for for Ethereum and if someone wants something faster either need to use some huristic or some of quote unquote confirmation rule that maybe are not probably secure or are actually arguably not secure. So the goal here was to devise a provably safe confirmation rule under some assumptions so that ideally we can provide users with a criteria per

rule in which it's possible to confirm block in a way that is much much much faster compared to finality. And of course this confirmation rule relies on some assumptions as we will see soon. And these assumptions are generally weaker compared to the assumptions that are provided by the target that are given for finality uh just even simply for the for the from the timing assumptions etc. But we believe that under these assumptions which we believe to hold uh most of the time we can actually provide user with a way of confirming blocks that is very much much faster and much faster we mean in the order of one two slots compared to uh the 15 minutes or two epochs or such of

uh finality. The goal here again is to have this this rule that outputs a block so that user can users can treat as confirmed. And in order to do so, we propose, but Mikl will show better later, we propose to modify the store in order to have an additional field with confirmed route. And this is actually the view of the confirmation the latest confirmation block that this rule provides at each uh at each run. Basically, uh this confirmation rule provides two properties assuming that the assumptions that I will present in the next slide hold. These two properties are safety and monotonicity.

With safety, we mean that blocks that are deemed as confirmed do not get reorg in honest view once confirmed. Meaning that we do not want to confirm something that later on is not anymore confirmed. And monotonicity means that we never move backward with confirmation except when we reset to finality is triggered which means that some assumptions actually failed and because of that we need a safe all back plan to for confirmation to to still be uh valuable. The assumptions that we provide here as I mentioned before are actually generally weaker compared to the assumptions that we uh have in the context of gasfair in the sense that

here the assumptions of this confirmation rule is first of all synchrony meaning that we are assuming a healthy network in which at the stations sent by an honest validator in a slot are received by any honest validator by the end of that slot. Okay. And this by the way also kind of aligns with the uh dynamically available layer that is kind of considered within uh within Dasper right we know that we have this sort of two modules one is that provide dynamic availability meaning that is safe and live even if we varying participation level and in order for dynamically available protocol to be safe we need to have synchrony so in some sense this

confirmation rule which is meant to be working in that layer is actually aligned with the assumptions that are also required for the dynamically available layer to be secure in some sense. But anyway and the other assumption that we give that we provide is that we need we need to assume a maximal adversarial fracture of stake uh of uh 20 25%. Maybe this we can discuss later better in the context of for example in the specs of why we need this sort of uh assumption on the adversarial on on the adversary and what happens if we do not have it. But for the moment let's just assume that just consider

these two type of assumptions. If these two type of assumptions hold then we can have our fast confirmation rule providing uh safety and uh monotonicity. So um the confirmation rule is actually run at two different time step. Specifically is it a confirmation rule is executed at the beginning of every slot after we have applied at the station from past slots. And of course a particular subcase of this is that it can also be run executed at the beginning of an epoch because beginning of the first l of an epoch is the beginning of an epoch. And if that's the case, we have an additional set of

conditions that we need to satisfy which I will uh present shortly. But you can imagine that this fast confirmation rule slot again after we have applied at the station from previous slot. And what it does each runs each run starts from the previously confirmed block and tries to advance confirmation along the current canonical chain. Okay. So basically it takes again the latest confirmed block in the view in the store and it tries to advance to along the canonical chain.

The entry point of this confirmation rule is uh this function which is get latest uh confirmed. Okay. And what this function does is basically it wants to return basically the latest uh the deepest f the deepest confirmed block along the canonical chain. You can imagine this sort of this function as divided into parts and depending on when we are executing this purchase function we follow some specific code or some other specific code as we will see later with with the specs. But the the overview of this of this function is that you can imagine as divided in two big chunks. One chunk is for uh checking whether the assumptions that we have

that that I stated in the previous couple of slides are still holding. So for example, if we are at the beginning of a slot and we are running this confirmation rule and we observe that the latest confirmed block is very very very very slow or for example that is not anymore canonical for instance then it means that something must have happened right either we don't have any more synchrony or maybe we had an adversarial threshold adversarial adversary that was higher than expected. So in that case we cannot safely proceed with confirmation. So in some sense we just reset to finality. So we revert to the greatest finalized uh checkpoint basically. And

another thing that we check at the beginning of each run of this confirmation rule is whether we should restart the confirmation rule. And this usually happens in the subcase in which we are at the beginning of an epoch. So of an epoch, we can treat the beginning of an epoch as a sort of reset to synchrony kind of because at the beginning of an epoch we have new justification, new finalization, we have a new realization of this new this checkpoints and everything. So in some sense what we can do is to treat the beginning of an epoch as starting point again for our assumptions to hold. So at the beginning of an epoch we can check

whether it's safe to restart the confirmation rule. So for example imagine that for a long time we had a synchron network partition or whatever in a way in which we had to keep relying on finality but then assumptions come back again to halt. What happens is that at the beginning of an epoch we can see if conditions seem reasonable enough for our confirmation rule to actually restart. What we do is to set the latest confirm not anymore to the greatest finalized but to the greatest unrealized justification as seen in the latest lot of in the last lot of the previous epoch. And this is actually the first chunk that is executed when you execute

the forest function at the beginning of every slot or in the sub case of the be at the beginning of every epoch of the ebook. Yes. The second chunk is actually the confirmation rule in the sense that the second chunk of this function is actually trying to find the latest confirmed descendants along the canonical chain so that we can actually fast confirm something new compared to what we started from. And we do this by means of this predicate which is one is called is one confirmed. The intuition behind this is that basically what we do is we start from the latest confirmation and we try to go along the and we try to

find a suffix of it which is a prefix of the canonical chain in which this predicate is evaluated as true along every single block that we find until is not holding anymore. Okay. And this ideally is the block that we want to try to confirm. And this predicate basically simply wants to was this predicate simply means that um if a block passes this check is one confirm. It means that this block has enough LMD support to defeat any potential siblings take over. So you can imagine that we are in a block and we say assuming all the possible things that might push the chain to a sibling

to a conflicting chain for example. for example, proposer boost or uh adversarial budget like equivocation or adversary voting on another branch. If assuming all of these potential weight that could influence or that can go in to benefit another branch, is this block still having more than half of all of this contribution in some sense? Is still a majority? If so, then it means that it's very unlikely that we can have a sibling take over. And so this is one confirmed check actually passes for a specific block. And we keep doing this check along all the suffix starting from the latest confirmation that comes from the

previous run until a point in which this is one confirm is not holding anymore. And and that's it. This is basically what we do. Of course the problem is that in an ideal world this s would suffice. The problem is that given we are given that we are considering Gasper and Gasper has the FFG part in it and the FFG part also influences the forest function in the sense that we have all the filtering that we need to take into account. The last thing that we want is to reach a point in which we confirm something along one ch along one branch and then this branch gets filtered out because we because then it turns out that we have a

conflicting um checkpoint or something else. So the last thing that we want is to confirm something that that gets filtered out. So the whole complexity of this confirmation rule comes from the fact that we need to be able to handle all of the scenarios in which we might filter out something that is actually confirmed and because of that we enter in the complexity of the confirmation rule which I'm not going into many theoretical discussion just other couple of minutes because I think that the specs will also highlight this much together. But the goal here is that uh we can have you can imagine two

categories in which this confirmation rule actually confirms. Okay. So one is that we try to confirm something in the current epoch. This is the best case scenario, right? In the sense that we are in epoch E and we try to confirm something in epoch E. Ideally the closest to the tip of the canonical chain as possible because of course we cannot confirm something in the future. So the best that we can do is to confirm something in the current epoch. If that's not possible, then we try to confirm something in the previous epoch assuming that no conflicting justification happens in a way that is not even safe to confirm at all because could also be the case that we cannot

even confirm anything in this specific run. And if that's the case, we just return the previous confirmation in the previous run. So the very first um case that we are considering is confirmation of something that is actually in the current epoch. Okay. So we try to confirm something in the current epoch meaning that we start the confirmation rule. The confirmation rule starts from the previous confirm block. We go along the canonical chain until this is one confirm keeps holding. If it happens that we are in the current epoch meaning that the latest block for which is one confirm holds is in the current epoch then we try to confirm this block

assuming that some other conditions hold. For instance, I I'm not going again too much into details here because this is just an overview without code or without pseudo code. But for example, [snorts] if we let's say that we are in the middle of the current epoch, what we want is to be able to be on a branch in which the head has a greatest unrealized checkpoint that is fresh enough in the sense that we don't want to risk to be in a branch that will then later be filtered out. So some conditions are around the fact that we want to be in a branch that is updated enough with respect to the to the

checkpoint and if that's the case then okay we are happy and we try to confirm something. There is a critical case in which for example if we start from the latest confirmation and in order to reach the current epoch we cross an epoch because for example I don't know the previous confirmation was in epoch E minus one but now we are in epoch E and while going while reaching the current epoch we had to cross an epoch. This enables additional conditions namely that the checkpoint in the current epoch should should become justified. If that's the case then we are happy otherwise we need to go on another case and the other case is actually to check whether we can make progresses at all

meaning that let's assume that we are in the current epoch okay and we actually cannot prove that we that there aren't conflicting checkpoint that could be justified meaning that we are in epoch and we don't have proof that at some point another checkpoint could be justified. If that's the case then it means that is not safe to confirm at all because we might confirm something that then will be filtered out because a conflicting checkpoint will get justified. So it's not safe to confirm anything on the current epoch but it's not also safe to confirm anything in the previous epoch. So if that's the case, we simply freeze the confirmation rule and we return the the latest confirmation that was in in the store.

But if that's not the case, meaning that if it's if we are not safe to confirm something in the current epoch, but also we can prove that no conflicting checkpoint will get justified when we cross the epoch boundary to go to epoch E+1. Then what the best that we can do is to try to confirm something in the previous epoch. And if that's the case, basically we keep redoing the same mechanism that we did so far. meaning that we start from the latest confirmation. We try to advance as much as possible along the canonical chain while remaining in the previous epoch and we pick basically the longest uh the deepest one confirmed descendant

uh that um that has a recent enough voting source because of course the filtering also takes into account uh the freshness of the voting source of a specific block. And if that's not even the case, then we have an additional case which is a subset subc case of this case that I just mentioned. But still we try to confirm the longest possible suffix of the latest confirmation that has at least a potential descendant with a fresh enough voting source. So here I might I understand I like can imagine that maybe some details are not 100% clear which I believe become much

much clear once we see the code and we try to compare the code with this type of macro cases that I just presented. But the goal here is to give you an overview of how to reason about this confirmation rule. Meaning that we always want to try to advance the block the the confirmation in a way that we never confirm anything that is non-cononical and we always want to to advance confirmation unless the assumptions are not holding and if that's the case we revert to finality and the confirmation simply tries to advance as much as possible along the canonical chain using this is one confirmed predicate that simply shows

a block that will shows that a block will not be take over by a conflicting block. So we are confident enough that we can proceed along that specific canonical chain and at that point we try confirmation and we try to confirm the best candidate as possible. The best candidate as possible is a candidate that is in the current epoch because it is the closest as possible to the tip of the canonical chain. But if that's not the case, then we try to confirm something from the previous epoch. All of these assuming that nothing will get filtered out because if you are in a scenario which something might get filtered out, it might not be safe at all to confirm. And if that's the case,

we just return the previous confirmation. So this is the uh the overview of the confirmation rule. I hope uh I hope it's clear. I think now it becomes slightly more clear if it's not already very clear um using the specs and I think we can match now these cases with the specific specs because we try to build the paper and all the theoretic the all the theory behind the confirmation rule in a way that what you see in the paper and what you see in the theory is exactly what you see in the code. So there is this one to one equivalence between code that you see and the specs that that you that you work on and yes now if Nik want you want

to proceed with the with with the specs then we are very happy further are any questions or anything that you like to to discuss. me share my screen in the meantime. Um, yeah. So, um, can you see slides? Oh, sorry. No, it's not yet there. Now, it should be there.

Oh, >> I can. Yes. Great. [snorts] >> So, are there any questions uh to the part uh that is given by Luca? No. Then let's proceed with uh yeah with the spec. So I'll I'll give a brief overview of this pack and uh to give an idea how it's organized um and uh also with references to the part that was given by Luca the part of the presentation. So how it's uh uh from we'll go from the very high level to the um to the lowle functions. So uh the for for this um algorithm to get trigger it

uh we introduce a new um book choice handler. This handler is a bit artificial because kind of like uh there is no such uh explicit uh event in the protocol which is called slow start after passation is applied. But uh this handler is introduced to give an uh an idea and uh to specify a point in time uh when this uh code should be uh triggered. So what should happen on uh upon this uh moment in time is basically the first part is uh the fast confirmation variable should be updated.

It is very important to update them in this specific uh moment in time. Um there are four variables that are used by the pass confirmation rule uh for you know for the algorithm purposes and uh then uh basically the uh confirmation rule trigger it and uh the result the product of its work uh in this iteration is stored in this confirmed root variable. Uh now the entry point I hope it uh it's it's large enough but yeah so anyway uh you can find it in the PR. So this get latest confirmed function has three basically three blocks. The first piece

of code is uh the reset to finalized uh part where the conditions um that uh need to be met where we have to reset the finalized uh uh block they are checked and if if we found uh those conditions um once again it means that our assumptions um we see the evidence that assumptions that we made uh on the synchronous and potentially adversarial fraction are not held. So and in this case we have to revert to the finalized block as a fallback um as a because the confirmed block becomes unsafe. One of

such conditions is obviously when we see that the u confirmed confirmed block gets reorged. So it means that something really bad happens in the network. We reset to finalized uh block in this case. So uh there there is another one uh but uh yeah I will not dive into detail here about it. Uh so the next uh the next piece of code is uh this starting point or restarting point when we uh for instance revert it to finalized and before and we are looking for uh good conditions where we can start our confirmation chain once again.

Uh so if if we met a certain conditions here and if the restart is required uh uh then we just basically seed the uh confirmed route with uh the one of the justified checkpoints that's uh we that that is proven that it will be canonical uh for this uh for this current epoch for the entire epoch. So it is safe to use this checkpoint uh route as a start. And uh the last piece of code is uh basically find latest confirmed descendant function which advances the confirmed block uh towards the head as much as it can.

So let's zoom into find latest confirm and descendant. This looks really really complicated at the first glance, but what it actually does is uh going alongside the canonical chain starting from the uh child of the uh previously confirmed block uh and uh it checks this dominance predicate uh which is called is one confirmed uh for every block and uh the majority uh the majority of complexity comes here from handling and uh from from proving that uh our confirmed block will not get filtered out by the fork choice uh during the current and uh the next epoch. This is important for to do for the current and

the next epoch. This is why we have so many conditions here uh to check uh and uh here you can see uh the cases that Luca was mentioning the cases in blue are referring to attempting to confirm a block from the previous epoch. The case number one which is green is the uh code that confirms block from the current epoch. So it basically uh start if if we started from the previous epoch block uh we go through uh the previous epoch blocks first then we switch to the uh current epoch blocks and uh yeah this this is like uh outlined in these two loops that you can see. Um and yeah you can see here the checks uh this big if

is basically here you can see the voting source check uh which is uh refer which is the filtering thing. Uh here you can also see the unrealized justification check which is also the uh uh one of the proofs that uh in the next epoch the blog that we have confirmed now will not get filtered out. And uh why it is so complicated is basically because uh there are we run different uh kind of checks different set of checks for each case. Uh like we run one checks for the previous epoch blocks and we run another checks for the current epoch blocks. uh and also what was uh mentioned here for

the previous epoch blocks there are different cases where we run the algorithm in the first uh slot of the current epoch and in the middle of the current epoch. So this is why there is a lot of uh complexity uh for you know for uh for in this function this why this function holds a lot of complexity uh from the implementation perspective um probably it uh worth just starting implemented it implementing it as is in this pack and uh for those who are interested in uh how it on in the intuition behind all these uh checks and how it works Uh there will be a write up uh there will be a paper basically um

that is Luka is working on currently with the intuition and uh it will also have proof of correctness and uh we already have like a short explainer for with enough of technical details for those who are interested to get into the intuition of uh this algorithm. So we'll be probably public. It's already published somewhere but yeah we can probably share it once again. All right. So um yeah and that's the complexity of filtering and the other part of uh comp uh but yeah that's kind of like uh this complexity is handled by this uh number of lines of codes. uh and uh there is

another complexity that is kind of hidden at the from the first ones. Uh and uh this is uh this complexity yeah this is quite probably one of the biggest challenges for implementations um and uh this is basically dependency on uh several beacon states. So this uh algorithm depends uh on pot on on four potentially different picking states as opposed to as opposed to the fk choice uh rule which basically depends just on one on a single state which is uh the justified checkpoint state. Uh this algorithm uh requires access to committee shuffling.

Uh this is like uh the committee shuffling is needed in two places. One of them is the optimization for uh confirming blocks uh that are coming after empty slot where we need to dis distinguish uh support given to the parent block in in the uh slot of this parent block and uh given to to the same parent block but in the uh empty slot. So this is important. Uh the other one is the current epoch target state. This is basically where we try to assess if if we get back here there is this will current target be justified and will no conflicting checkpoint be justified. Uh and for these two checks we need this u

current target state. Uh this is this state uh is the state that will be used by the protocol eventually to assess uh the whether the um the current checkpoint is justified or not. So we use it here to do some preliminary evaluation. So we have to use this uh current epoch checkpoint state uh to to to get the validator effective balances to to do this assessment. And also uh there are two other uh balance sources that the algorithm uses. And uh they are not not that far. Um in terms of like uh th those two those two uh balance

sources are basically also checkpoint states. Um and they could be from the previous epoch checkpoint and from uh the checkpoint that is two epochs uh old. Um yeah. So that's and uh this is not these two balance sources are not necessarily always the same as the justify checkpoint state. This is to bear in mind. So this like uh here we have uh yeah there is the state helpers uh section in in this spec which encapsulates this complexity and I should say that uh get slot committee function is just there uh for to denote

the um the basically denote the um the semantics of what is required from this function and implementation can uh have a it's an an own uh version of this function and the same is for uh the rest of you know for the rest of these functions it's debatable and yeah let's let's discuss this um further right so I would like to go over API and testing a bit here but if there are any questions to to this uh spec overview.

Let's stop here for questions. All right. Um API. So what's already in the PR in the spec PR is repurposing safe block hash uh which is passed in the pork choice updated engine API method call. Uh repurpose this safe block hash for the hash of the confirmed block of the confirmed EL block. Um this is what we are planning to do and this is how the consumer will h have an access

to the confirmed block. uh hash uh on the L side basically why JSON RPC API because it already have this notion of safe block and there are also potential ven API changes that uh we need to decide uh whether we do them or maybe we we we can do uh something on top of that. Uh so we we we could add confirmed root update to the event stream. We could also add the confirmed flag uh to responses to any uh queries over the over the beacon API uh similarly to the optimistic uh flag that we have today.

And yeah, it can be um confirm block uh to to the like um add confirm block basically or block header query uh specific like yeah what's the latest confirmed block header for instance. Um that's this is the beacon API changes is something that uh we are really really uh want to we're very keen to get inputs uh from from from the community testing.

So uh this is a quite complicated algorithm because it covers a lot of uh cases such cases. So uh and uh we want uh want to provide a quite good testing suit um in terms of code coverage. So if implementation is done with some optimizations which will definitely make sense um this implementation can be tested against the spec and if there are any bugs they can be u discovered um with a very high probability.

Um so and for for the tests uh format itself so how do we want these tests that we are working on already to be run by a client uh we extend the fork choice test format that is every client is familiar with uh by uh with a new uh event which is basically slot start after passition applied and uh yeah with a few more checks uh and a few more property property checks like four properties are basically these uh variables that are used by the algorithm and the one main property is the confirmed route.

So this is how it will look like in the steps yl file. Um and this is what client will be able to to consume and you know check their uh bus confirmation rule implementation. So that's uh yeah good question uh Justin um so it uses with alter and later because I believe that we um phase zero test might not be I don't know do we want to support phase zero test because they have a bit different uh beacon state um you can

state structure I don't know if client really support them um not sure if all clients support them because they were previous and current stations and yeah the begin status was uh redesigned in alter so we can yeah figure this out yeah okay right so any other questions All right, cool.

I'll just stop sharing. Thank you. >> Um, thanks Mel. Thanks, Luca. I don't I've never uh run a poll in Zoom, so I just try to do this as sort of like an icebreaker. Um I just launched it. Can people let me know if they're seeing that? >> Yes, we can. Oh yeah. >> Uh yeah, I thought it'd be a good way to just like kind of get a sense of um yeah, what what the what the primary concerns or blockers might be for people.

Uh I just exited out of the window by the way because I'm not like a client dev. FYI like that. That's an option. You can simply just close the window if you don't like a client. >> Yeah, I should have made it a little more agnostic. So, um yeah, maybe Luca, you had mentioned that uh testing is coming along. Is there anything that you can provide with an update on that just to see give people a complete picture of uh yeah all the work that's been going that's happening. Uh yes, I'm actually helping uh Mikail with some with some testing part here. And the first

preliminary test that we are doing is like uh this more like easier part quote unquote on revert to finality or restart uh restart the confirmation rule. So basically we are testing out all of the single conditions that Mikail showed in the in the STS now and currently everything like we are proceeding like well I don't know I don't know wait sh I was reading sorry um but yeah before answering that like the I don't know if m you want to say something particular about testing but for now we are focused on uh defining like

all the like showing if all the conditions like if everything works basically with respect to revert to finality or restart justification basically that's the that's the that's the main thing. >> Yeah. And then we plan to extensively cover find latest confirm find latest confirm descendant with to check all of the if uh all of the conditions in all those big ifs uh that you have seen. >> So uh and I think that uh we will have a we should have a pretty good uh updates on tests uh like uh in in the next couple of weeks. So this is like uh one of our main focuses now um on this uh fast in the context of fast confirmation

work. Yes, ideally we would like to release uh the paper also like in a approximately around the time where we are also confident with enough testing so that we basically have like we don't want to release a paper much much much later so that people can actually have a look at both the resources both testing part and the theoretical part if uh because we also noticed that The current paper that is on the archive is other than outdated is not reflecting actually the the discussions that we had today.

Uh it's very updated outdated and is also quite dense. So we are basically redesigning completely the paper and we would like to come up with something that is more gentle from u from from from that point of view also it proves SL mass and and everything but it's it's a fully design which also we believe like within next month to have concrete results on Great. Um, yeah. And June, excellent question in the chat. Maybe, uh, I don't know, it Nazar, I I see your names and

recognize both of you. Um, could you maybe just give us a quick update on where you're at? I don't know if there's anyone from Lighthouse, Prism, or Teu on the call. Uh on Nimba's side, I have so far looked into the specs mostly. Um it seems mostly fine. Um these shufflings should be available, but devil is usually in the details there. So if I run into performance issues there, I will just reach out to Mikail. Um yeah.

>> Yeah. from the Lord star side. I went through the specs most of the things are clear and uh since last week I was drafting an initial PR for understanding how much code changes and where the code changes will affect so that uh we can plan it better. Yeah, if there's any complexity came up or have any question then I will ask in our group. >> Great. Um and then the plan is to you know run this uh meeting on every other week basis. Um, yeah, I think once we

get going, you know, really the hardest part is just getting a little bit of momentum, but starting off with the structure of just some client updates and then rolling that into research and spec updates. Um, and just trying to use the the client efforts to surface any blind spots that might be in the research and also conversely in the specs and then testing. Um I don't know if anyone has any comments on the structure of the meeting. um always open to feedback and you know want to make sure that it's a useful it's a it's a worthwhile use of everyone's time.

Mau >> uh I wanted also to mention that we have a proof of concept in tech and we are now uh discussing like uh moving this proof of concept into production phase like into production grade code. This will definitely take some time but uh we also did the performance measurement of the algorithm u with using shadow data. So you basically uh in the PR in the PR description you you can see u the performance measurement results uh they are pretty pretty exciting.

So that was something I would like to share as well and uh yeah on the state side on the using different state side of things. Yeah I agree that that's one the main I mentioned one of the main challenges. So let's let's discuss this um yeah looking forward to your feedback and uh to to to looking forward to see um um potential ways uh ground here. So if if we have them if not we'll just have to also I would like to say that um this is not a critical for consensus thing. So if it's going to be slower uh even by a order of magnitude that than

uh your fork choice implementation like it's all it's it it's probably fine. It depends on the quality of service that you want to give to your consumers. But probably if this um this bus confirmation rule runs not 10 milliseconds but in a 100 milliseconds or 500 milliseconds, it's probably um good enough. Um, there's a couple questions in the chat. MueL, Luca, I might just ask you to respond to these. Um, are there any performance concerns with this? Do you

have any rough estimate of how expensive this extra work is? I imagine it's pretty minimal. This is coming from Justin Trogia. Uh, you mean performance in terms of running the algorithm or other kind of performance? uh yeah just running the algorithm. >> Yeah, as I mentioned it's like yeah we can it can be slower than the critical code uh required for you know ser duties.

Um, >> okay. >> How expensive you mean like expensive in terms of CPU cycles or like expensive >> uh likeation >> like 100 milliseconds on a single core or something? >> Yeah. Yeah. Yeah. I see. So I believe in tackle uh this I don't know it's like a subsecond uh execution time for you know for the confirmation it's like maybe five 100 milliseconds it was a proof of concept we didn't optimize it well enough you know >> okay yeah I mean subsecond isn't very fast but uh like you said it's not very cool it seems

>> uh for tech for the pro proto for the prototype type. It took uh about a month and a month and a half uh to to do these performance measurements and to catch up with uh yeah probably two months in total. But uh one of the reasons behind that was uh basically the spec was changing like uh we did changes after you know the first iteration of implementation. So probably uh if we cut this uh if we put this uh extra time aside, it's a month or month and a half.

>> That would be for a single contributor working full-time. >> Yeah. Yeah. for a single contributor working I don't know uh not a full-time but you know well most of the time on it focused um and then there's another question that was further up the chat uh also from Justin Troga is there a reason the test it uses with alter and later instead of phase zero plus >> yeah that was answered earlier Oh, sorry.

Frederick is wondering what's the signal of this ending ending up being used and how many have pre-committed um in terms of users that is uh is that the question Fred? >> Yeah. Yeah. Well, I'm just curious like how [sighs] how likely this for this to become used compared to finality basically. Um yeah, basically what the signal is on that >> uh if this or if it's uh if it's actually backed up by this is something that many are actually looking for and wanting to implement the same stuff.

Um, yeah, Julian might or others might have a longer historic perspective on this, but we're on we're in the process of getting uh call set up with like three tier one centralized exchanges to help really validate um that. I don't know Julian or Luca or Miky if you have previous experience. I know that there was like a shortrun experiment with Circle um a little over a year ago. >> Yeah. Um I could say this. So we're approaching centralized exchanges uh and layer 2 um who might be interested in using the faster information rule. Uh

for now we're also focusing on on getting it actually deployed so that we have something that we can show them so that they can implement it quickly. Uh so that's to say I guess we don't have any hard commitments for now but I think it's very much in their own interest to use the rule. Many exchanges in L2s use similar rules now like KD and justification uh that are not full finality. So they also have some additional assumptions like like faster information rule but the faster information rule is just faster. Uh so I think it's very much in their own interest uh to use the rule and and we're actively ensuring uh that there is like good information about it and and reaching out to these parties.

>> But excellent question Frederick and something that like we're that's not just like something that we're going to gloss over. something that we're going to put a lot of time into and uh there is like a a concerted and long-term uh parallel effort going into this to bring it to market. So uh yeah, we'll we'll continue to provide updates on that front. Uh cool. So yeah, just like any breakout call, um going to be posting this to to YouTube. Um I tend to open up the issue for say the next call and I'll include

the the meeting minutes from this call and that GitHub issue. So, uh, if you're interested in what was discussed, uh, it'll be in the it'll be in the issue and then I'll link the issue in the description to the YouTube channel and I'll try to be in the habit of, uh, saving this, uh, or passing that around. And yeah, I'll include the the chat in the um, in the distribution as well, Justin. All right, thank you all. Um, and we'll see you in two weeks.

>> Take care. >> Thank you guys. >> Thanks everyone. >> Thank you. Bye.