FOCIL Breakout #12

Transcript

Um, great. Thanks. Yeah. Uh, thanks for joining. This is also, uh, breakout number 12. Um, yeah, I don't think I have tons of, uh, updates on the research side. Uh, it was mostly around, uh, planning the fossil session for Berlin. Uh here is a little note I made uh with the with the speakers and what we're going to talk about when we are there.

Uh so I think it's going to be quite excited and we um we have lots to to talk about. So um yeah stay tuned for that. I think uh we will discuss both like posul as a candidate for glamsterdam. Uh I think there's a big question around the urgency of fossil and um maybe I encourage you to also think about that how much of a priority fossil is compared to scaling EIP. Uh I think uh this has been like a big question these days. So if you have opinions or if you

um have thought about this uh yeah reach out or or feel free to sort of like uh talk to me about it or anyone else. Um and uh yeah and then we have like talks about like you know more like of the research on ZK for statelessness uh and for sort of like interactions with other proposals and upgrades um which is always sort of nice to explore. Um uh yeah and that's basically it for me.

Uh I do have a presentation today and Akatarini is going to present a paper we worked on together but she's been doing most of the work by far. Uh so I'm very excited for for you to give that presentation and I think we're going to start with this already. Yeah. Thank you Thomas. Maybe should I share my screen now or we should wait? Yeah. Yeah, you can just share the screen.

Thanks. Hello everyone. Let me just give me one 10 seconds to share my screen. Can you see my screen now?

Yes. Oh, great. Great. Hello everyone. I'm Katina. Wait, can you just click on the slideshow mode? Maybe it is in a slide show mode. I don't know if should should I what? We see the whole window. Okay, let me see if I can minimize this. Uh, you don't see you see the whole window. You don't see the the slide. I mean, we see it, but like we don't see it full screen.

Okay, let me show Okay, let me see because it is slid so in my window but uh maybe in the sh mode it's not. Maybe I will better share my my whole screen. Maybe this works better. Let's do that. Yeah, maybe. Yeah. Yeah. Yeah. Sorry, give me h give me one second

because like there is a a synchronization problem with the Google slides. I think this was the problem. Uh give me one second please. Sorry for that. There were some uh

connection problems. But I think now it has been fixed. Let me see. Oh, it's again. Oh, I think it's fixed now. Can you see now my screen? Yes. Perfect. Great. Great. There were some connection problem today, but I think now it's it's fine. Great. Hello everyone. So I'm Katina. I'm working in Nethermind and this is a very recent joint work with Julian M Thomas and we uploaded very recently to archive and at the end of the slides I at the end of the presentation I have also the QR code. H this is the title of the

paper. H just a small legal disclaimer that it's not any type of recommendation or advice uh this presentation and let's first discuss a very high level which was the objective of this work. So in this work we propose two concrete payment mechanism for fossil h that enhance the censorship resistance other bribery attacks. During the presentation, we will explain what exactly this means and also we would like to retain some uh good incentive properties of the current Ethereum fee mechanism and in order to prove our statements formally to prove exactly what censorship resistant we have and

what incentive properties we generalized in we generalized existing literature uh and specifically Tim Cardan's model in the transaction fee mechanism design. H before I start to discuss the bribery attack, I will just give a small overview of the false plural protocol. You you already know, but just to highlight what is the honest behavior. So like just to just a a brief a brief um overview of what all the other parties do when everybody behaves honestly.

Um and later we will see like the difference what like happens at their bribing attacks. So as you all already know in fossil we have users that submit their transactions to the meool and the inclusion list committee which is different. It's elected uh in every slot and it's different h choose transactions from the me pool and they put them in their inclusion list one list per member. They broadcast this inclusion list to the validators and to the attesttors. And later the builder, the person who will uh construct the block uh will h will uh see the inclusion list

and create their block and this block has to respect some requirements and if these requirements are not met the testers later can uh reject the block. Uh so the the requirements say that the builder should include the inclusion list if there is space but there are some cases when they can omit them. So for example h if we are under congestion meaning that there is not enough space for all the transaction in the me pool the builder has uh can create a full block h omit the inclusion list and this block will be valid. Um also it's

important to recall that the erh in order to to avoid ME transaction in inclusion list the inclusion list are executed at the end of the block. So like uh the block producer has the option to put other transactions in the top of the block and h put the inclusion list but at the end. Uh so this means that if in the top of the block there is a transaction that drains a centers's balance from the other transactions in inclusion list uh then these transactions could invalidate them but an honest user could never create such uh transactions.

So this is the honest behavior. So like if if everybody like behaves honestly. H now we will see what happen when we have bribing attacks. H we generalize the literature and we discuss several types of uh bribing attacks but the simplest one is the following. We assume that there is an entity who is malicious like just want to censor to pay and censor a transaction a target transaction and uh this entity is willing to pay money to the includers and or the block block producer uh to censor a transaction.

And uh this can be very simple. For example, they say that I will give you this m they say to the includers or the block producer that they will give them money if they just omit this transaction. Or they can tell them more complicated rules. For example, that okay, they will pay them only if the attack is successful in the end and all the parties remove omit the transaction. But for our presentation, we can just assume that the briber uh is an entity that pays the includer when they sensor or otherwise omit the target transaction from the inclusion list or like uh the block. So this is

for the the purpose of this presentation this will be um a briber and if we have this external entity now we will discuss uh what like maybe some possible uh deviation a a block producer could do if the bribe was very high. Uh so for example um in these attacks the block producer uh would like to take the bribe uh and omit a transaction but on the other side they are afraid of the block being rejected by a testers because if the target is in an inclusion list then the block

producer and and the and the block producer we are not under congestion which means that the block is has empty space the block producer cannot just like ignore the transaction because okay he they will take the bribe but like the the block will be invalid. So like they will lose the whole rewards. So the block user could make some other like things to to take the bribe but make the block valid. One example is that they could just create transaction for them originated from from themselves and put them in the block to make it full and like to pretend that there is

congestion. H every time like we we call this transaction fake because they are not originated from the users but like they are real transaction. When we say fake we mean that they don't uses transactions. like originated from the block producer for an attack. But if we see them and they are valid transactions. So this is one thing that the block producer can do. Of course, this has a cost because like uh the block producer to put all these transactions in the block, they have to pay uh the burning fee for all these transactions which means that like that the bribe should be high enough in order to make them be in this like uh to follow this uh action.

But like h this is one one thing that a deviant block user could could do. Erh, another deviant strategy that a block producer may may attempt is the following. H they try to spam menool in order to make includers prefer the the their transactions and ignore the target transaction. So somehow they they they try to create many many transactions. So includers select the the transactions for the block producer because it has higher fee or whatever and they don't put the target transaction there. So the block

producer does not have to respect this transaction they they can ignore it and take the bribe. Of course, this has again a huge cost because like all these transaction if they make it to the inclusion list later they have to be in the block and the again the block producer has to pay the burning fee and the same thing. But however h the block producer has an advantage that has the top of the block. This means that they could create one single transaction that uh drains the balance of the center of the other transactions and make them invalid. So this means that now he he's he he can uh he can omit them and not

pay the burning fee. So what the the the producer achieve is that they spam inclusion list. A target transaction which is about to be censored does not make it to an inclusion list. The block producer ignores it, takes the bribe and on the other side has not to respect their own fake transactions because now they are invalidated by a new transaction. So this is like something this is a deviant strategy and in our case what we do is we were setting payment mechanism that make this deviant strategy more costly which means that a briber would need higher bribe like in order to uh make a block producer do

this. So like we we were searching how like we could make this more expensive for for the briber. But before we see h what like uh how can be more expensive events continue we will just make a summary of what we discussed and see like now how the fossil protocol is h when like the parties are not honest they do also other things. So summarizing h in the fa in the first phase the you all the parties users includers and block producer send transactions to the meool. Uh the transactions that come from includers or block producer are called fake and here we have we take into account also

deviant strategies from the block producer where they they try to spam the main poolool. So like in the first phase we have like this main poolool that has transactions from everybody. In the next phase, includers again like can select transactions from the map pool but also they can put their own transactions maybe if this gives them some uh uh reward or whatever but they are allowed to do so to put their own transaction there. And finally the block producer see the inclusion list and uh they can put transaction from the map pool from the inclusion list but also they can they have the option to put their own transaction which are called fake again

and they can put them in the block. So now this is not like the honest the strategy because honest includes a block producer have the target goal to just put transactions from a user. It's like h cover strategies where like some parties may want to create their own transactions to to if they are under a bribing like attempt. So this is the summary of how like uh the protocol will look if like there were a bribery and as we discussed before we have shown that when there is no congestion which means like that uh the block is not full. Uh we have seen that

um the minimum bribe we have proved that the minimum bribe a briber needs um to censor a transaction h is the sum of two components. One is the fee of the transaction that they want to censor because like if the block producer ignores it they will not take this fee of course and the other is the cost of the attack we described before. Because like the block producer, in order to be able to censor this transaction without have their block rejected, they should perform the attack we discussed, which is like spamming the main pool and later invalidate their own transaction with a

single transaction and pay for this attack. So like in an order for the briber to make a bribing successful attack, they need to pay both the block producer fee and to give a briber higher of the cost of this uh action that the block producer needs to do in order to ignore the transaction without having an invalid block. And the interesting thing is that we we we have shown that when like the when we are in PBS which means like that the builder is not 100% sure that they will be elected in these cases uh when we are not also under

congestion then it happens that the higher the fee if we have a fee for the includers also not for the block producer only but also for the includers This can make h the cost of the bribing attack higher. This means like that the higher the fee um of a a vulnerable transaction uh for the includers, the more difficult is for the briber to censor this transaction.

And an intuition behind this is that uh if the block if the builder is not sure that they will be elected uh and they have spammed the meool maybe if they don't get elected they cannot invalidate these transactions these transactions can end up to the block and they have to pay for them like to pay the burning fee to burn the includer fee and these things. So like this means that uh when we have an included fee h this action is more risky for the builder and it has more expected cost which means that bibers are more difficult and for these reasons we investigated payment

mechanism that don't give a fee not only to the block producer to the builder but they also give some fee uh to the includers And we ended up with two mechanism. Um both of them uh satisfy to two incentive properties of the current fee mechanism. Um and have um and increase indeed the cost of uh bribing attacks. H but they have some tradeoffs like we will we will see what these tradeoffs are. But first let's explain which are this uh payment mechanism at the at a very high level.

So in the paper you can see exactly like the which is the payment mechanism the structure of the fee and how this changes the current fee mechanism and this thing but for the presentation we keep it high level like just to give the intuition. H so the first payment mechanism is called double and the reason is that we the user h sets two type of fees. One fees for the block producer as it is now in Ethereum and the other refers to the includers.

H this is the general characteristic of the payment mechanism and again and um again the fee will be paid only if the transaction make it to the block. So like it's the same thing as the current mechanism and here uh we have to determine uh how the included inside the comedy because okay the user says I will give 10 very high level it's not exactly structure of the fee but okay say I will I will give at a maximum 10 to the block producer and 11 to to include comedy H. Now we have to see

how this fee is set inside the committee. So the way it's set inside the committee is the following. Um we will h for we will have assumed that the the includer committee h is assigned a random order. So every includer h when it's selected it's selected with a random order. So we we assume that the committee every committee member h when priority. So like it has a random number between one and the number of the members. So like the fee the whole included fee will go to the member with the best order who put the transaction in the inclusion list. So if four

includers put the transaction in the inclusion list the includ will go to the includer with the best order. And of course this order is random. It's not some specific and the same like in every uh in every slot. So this is and actually it's quite simple because the difference with the current etheum mechanism is that there is an extra fee which is for the includers and this fee goes to the includer with the best order that includes this transaction uh in the inclusion list. And this is the mechanism.

The other mechanism it's exactly the same. So like um it has again the same way that the fee shared inside the committee and this thing. The only difference is that uh the h the user sets a single fee one fee and the system determines the fraction that goes to the includer. So the only difference is that now the the user sets a single fee and does not control the fraction of the fee that goes to the block producer and included.

This is done by the system and it's the same for all the transaction. So like this is the difference otherwise the two payment mechanism are the same. They have an included fee. The fee inside the committee is served in the in the same way. It's everything the same between them and here we have like we discussed their tradeoffs and it's both of them who have proved that they satisfy properties uh as you see if you are familiar with RA gardens model this incentive properties but what happened is that the single mechanism is has the advantage

that is simpler because like the user doesn't do something extra, sets again one fee and waits for the system to to make the splitting between the includer and the proposer. But on the other side, the W mechanism is a little more the user needs to set an extra fee, which means it does something extra. But on the other way, it gives like the freedom to the user uh to select the fraction that wants to go to the includers. if they want to give something to the gluttor or they don't want to give anything to the gluttor and this thing and this is an advantage because we have seen that we can achieve better sensor resistance depending on the characteristic of the transaction.

So like for example depending on the whole fee of the transaction. So it is not that there is an ideal splitting that the system can do in every With tailored splitting, we can achieve a little better censorship resistant. But so this is the trade-off. Single is simpler because there is one fee that the system does the splitting. On the other side, double h it's less less simple in the sense that the user selects another fee, but on otherwise it has more freedom for the user to set a fee that like it's the best like for the censorship resistant.

And these are the two these are like the two mechanisms that we propose in the paper. You can see like we have you can see we explain um exactly like uh how much bribe a briber needs in order like to um to create a bribing attack. We explain how they satisfy the incentive propos. You can see like the formal proofs in the paper but this is the high level overview. And finally the final part of our work was that we identified a class of mechanism that h are not ideal like for our case. So for example uh because they create some problem in

congestion and one example it's like a payment mechanism that does the following. Um if a transaction is included in both in a block add in an inclusion list then the whole field it goes to the includer because like this transaction is an inclusion list. If a transaction is not an inclusion is only in the block the whole fee goes to the block producer and this is a bad idea like because um if there is congestion the block producer will always ignore all the

transactions from inclusion list because like they can do due to congestion they will they'll have other transactions to select and they don't get any fee for from these transactions. So we cannot they will not block user will not like uh select them. So like in general we have proved that um when we are under congestion h mechanism that give h always a reward to the block producer h are better compared to mechanism that that give the whole the whole fee h to the includers.

So like this is a general this was like something a negative result that we found for another type of mechanism. Just to summarize like which are the key takeaways that we discussed is that we we we saw that uh includes if like transaction has a fee for the includers this can increase uh the cost of censorship other bribing attacks. H thus for this reason we propose two mechanisms that involve includes.

H the first mechanism is called double and the user sets two types of fees. One for the includers and one for the block producer. And the second type is called single and the user sets a single fee. But the fee is the fraction that goes to the includes determined by the system. And the both these mechanism satisfy two good properties like Ethereum mechanism incentive properties. But they have some trade-offs like the single is simpler because there's one thing but the double gives more freedom to the users to set like their own uh uh fraction that they want to go uh to the includers. So like this is like the main um h the main takeaways

and thank you for your time. Also you can see here like in the QR code you can see the paper and like I'm happy like to discuss uh any questions or like if you would like to uh to elaborate on any slide or talk more about the topic. Thank you. Thanks a lot. Thanks a lot for the presentation. That was great. Uh does anyone have questions? Um yeah, well thanks for the presentation. It was very interesting.

Um I just had a question about the way that the includ fee is distributed. So why is it uh just done on this ordering rather than splitting? So if multiple includers include the same transaction, why only give it to the top ranked one? Uh yeah. Yeah. Good question. Um actually this h the disadvant the advantage of this h of uh this splitting uh is not to split like equally to all the member is that h if there is h if there is nobody in the committee assume that nobody in the

committee has included one transaction all the one person of the committee h if they see if for example We assume that they could see that this transaction is not in no inclusion list. If they take this transaction in their inclusion list, they will take the whole fee. They will so like what happens is that like they they will uh h they they will take the whole fee. So like h they have the advantage that they will not share this fee w with others. Um so uh let me so what happen is that the the the includer with the highest order uh when they include this transaction uh they will take the whole includer fee

which means that bribing is more expensive because now the briber needs to give more to this person and needs to give the whole includer fee in at least and some extra stuff to make them ignore this transaction. If like the fee was splitting among 10 members then every includ of the fee and they could deviate at even with a bribe with which is like one10enth of the transaction fees. So somehow like in this goes also with os or other mechanism that they give like um the whole fee to some um in some cases like

to the includer is that h we want the when an includer omits a transaction to lose the whole fee not to to lose one h one tenth of the includer fee. I don't know if uh uh does make sense to you or like Yeah, but um generally I'm not sure that say you're saying say uh you knew that all of the other includers had includes included something, but generally I'm not sure that you could know that, right? Because you're kind of constructing I guess you're observing which is are being gossiped, but then you'd have an incentive to wait and see everyone else's inclusion list first.

Yeah. Yeah, good point. Actually I have to to correct because I was thinking h when we have an order good point you don't need you you need to know only your order you don't need like to know h what the other inclusion includers have included because what happen is that the advantage of the order as you say is that uh if I am the f the person with the best order I know that if I put this transaction I will take the whole fee even if other 10 people do the name I have priority. So somehow if you know the size of the inclusion list only this the maximum size and you know your order and assume that all the other people are

rational which means that they will select the transactions with the highest includ you you can compute on your own which transactions will be taken. So for example if I am a person with order three I will know that the first two persons with the best order will take the best transactions. So like I will don't make an attempt to put this in my inclusion list because even if I put them I will not take any fee. The other half have priority. I will put the next available transaction. So the advantage of the order is that you can predict what the other will do without actually see their inclusion list. You imagine that

a a person will select the best includes the transaction with the best includes that um that match their order. So for example, if if an inclusion list has size 10, h the the person with order one will select the 10 transaction with the best fee. uh the person with order two will select the transaction that the best transaction in terms of fee but beginning of 11th until to end it. So somehow if a person knows their order they can they can somehow make um order the fee according to the

included fees and select the part that belongs to them somehow and if all are rational like they will have this is the best they can do like for to maximize their profits if it makes sense. Yeah, I think it makes sense. But I guess it does kind of break the property we have that you know you have like a one of n honesty assumption. So now you can sort of map say if you're the third ranked you know these are this range of transactions I'm estimating um are going to be like if everyone else chooses rationally. Um, yeah. Sorry. What I'm saying is like before we have this, you

know, you can have multiple includers that you would have to bribe whereas now there's just one. Um, and it also assumes that everyone's going to follow the same strategy. Um, and like I'm just not completely sure that the the most rational behavior necessarily is to assume that everyone's going to do that or that someone might follow a different strategy. um or or that you know I if this is the fee that's associated with the transaction that include a tip there might be you know other incentives outside so someone's you know so you can know that this is going to go to the rank third person right so you can just bribe them you don't have to worry about anyone else does that make sense yeah actually yeah sure so what we do is

again like if the other persons are not rational then you may like um ignore some transaction that would could give you like some fee because like if I say okay I'm I have order two so I will not select the highest fee transaction because person with order one will do if the person with order one doesn't do this it's a pity because I could take this transaction because of the bribing but what happen is that h in our model we compute what happens at an equilibrium so like of course in the equilibrium we assume that all the others do this the indicated strategy and what you you see what you do. So like it is this equilibrium assumption but also we take into account bribings.

So h there is the assumption that okay assuming that all are rational this is the rational things to do but h the good thing is that we capture bribing in this rational behavior. We don't we don't think that they are rational ignoring bribes. We the proofs we do is that we we we think that the other people are rational and they take bribes and also we have um in our model we take into account that you may not be sure h about if the other person takes or not bribe.

So somehow we make the proof agnostic that like I I am I don't know like if the other people take or not bribe but again what is my behavior in an equilibrium so somehow we we assume that all the rational people it is this rational assumption of course which is an assumption right that they are rational but we we don't consider them that they don't take bribe we say okay they are rational but they may take bribe which means that if the bribe is high enough they may censor and also we take into account that every person is not sure about the bribe of the other they cannot do know if they are bribed so somehow we we do something like basian nas equilibrium where you don't

know exactly which is the other player but you have some beliefs you believe like that with 50% like they take a bribe or not so like on one side it is their assumption of rationality as you say which is an assumption because we consider them rational But on the other side, we don't consider them irrational without bribe. We we leave the thing that they may take bribe and censor the transaction. So this is like uh what we take into account. Yeah, thank you. I need to read through it. Sounds interesting. But just one more thing I'm thinking about with this is you know we're only considering you know rational as responding to bribes.

But what if the includers actually trying to get their own transaction included? Then they might have an incentive to pretend that they're going to accept the bribe so that the person the briber doesn't bribe other people, but it's actually they're going to put it in their inclusion list anyway to get their own transaction included. You see what I mean? So they might have this other incentive as well. Actually, sorry. I I think I'm going to have to sort of like cut it here just to make sure we have time for like the implementation. uh updates, but um if if you guys can either follow up in the chat or or later, that would be great. Yeah, I hate to do this, but I I want to make sure at least we get like 15 minutes for like

the implementation sort of updates. I I can share in the the text, right? I can uh Yes. Yes. Great. Mark, I will ask you in the text. Great. Thank you. Thank you. Thanks a lot. Uh and thanks again for the presentation. Um yeah, I I do want to hear about um things that have been happening on the uh implementation side of things. I I did see quite a lot of things in the Discord channels. So if anyone wants to share updates, that would be great.

Um, I can start. Um, so it looks like we got the changes to the EIP merge, which is which is great. Um I have a PR uh on the execution specs for um yeah essentially just adding uh adding a branch um with the fossil IP and then based on that also have a branch of the execution spec test um which I don't have a a PR open for yet um although I can if that makes the uh discussion easier Um would be nice if uh at least the Yelp clients could verify they can generate

the test fixtures and consume them. Um right now these are um marked as uh engine test only. So they generate uh Hive uh fixtures. At least that's what they're called in the um execution spec test documentation. but yeah that's that's mainly mainly the update. Um and then yeah I think I'll uh change the implementation in the execution specs uh PR to to not um attempt to execute each transaction but to uh kind of statically verify uh these transactions. Um but yeah that's uh

that's mainly it nice. Yeah, thanks. That that's awesome. And so you say what would help now is having EL clients uh sort of like try and generate tests from what you made uh to try to generate them and also consume them. Um okay. Okay. Which Yeah. Sorry. Imagine Oh, sorry. Uh yeah, I imagine they would be familiar or at least likely to be familiar with that uh execution spec test, but um if not, there's uh some documentation on how to consume the test.

Nice. And so that would be um because yeah I mean so far you've been working on the rep side of things and and Jun has been working on the get side of things and then Mark has been working on on the mind but I um so you need we need input from G and ref people uh or can you and Jiun start testing things like what's the or is it just like something KM does have to have to do.

Uh it doesn't have to necessarily be client does, but uh definitely been spending less like I haven't really spent much time on the the WH uh codebase in a in a while. So um yeah, if there's someone that's more actively working on the EL implementation then um nice. Okay. Yeah, that's great. That that makes sense. Uh, cool. Thanks a lot. any other updates?

Yeah, I think I can go next. I I open the draft PR to specs. There was a feedback that why we have such changes is unclear. So, I left detailed reasons behind the change. Um please be aware that the work is not finished yet. So it lacks several um tests and so on and I'm planning to get back to it after the Bin inter. I also reached out to Lighthouse. I was told that it was just low priority so far. So I did some debugging to help them out a little bit. But of course there are some more work to be done to get the interrupt work. Um, yeah, that's

it from my end. Great. That may that makes sense. Uh, I don't remember who was working on on for the lighthouse side. Do do you know? bet I believe. Ah, yes. Yes. Okay, perfect. Okay, sounds good. Great. Thanks a lot. Nice, Mark. I remember you maybe wanted to touch on things about the EIP as well.

Um yeah, so I have another PR open which uh hopefully people can take a look at um which is related to the um inclusionless building um and specifically adding a flag so that um that that is passed to the inclusionless builders um that gives them like a unique ID that they can use. Um and this helps to kind of uh control the amount of overlap between different um inclusion lists. Um but yeah, the kind of reason I think this is important is um so we kind of have this uh like slow path. Um oh yeah, sorry. I'll send a link to the PR in a

second. Um yeah, so we have sort of like this um this slow inclusion path um which is where say your transactions been pending for a while then eventually like it'll be given high scores by the builders because they'll see that it's been pending for a while and then hopefully lots of them will try and include it. Um but that doesn't necessarily give you very quick inclusion. Um, so what I think can help here is if you have some like randomness, um, then essentially even if you know your transactions only just been sent, um, so it's not obvious that it's going to be censored yet, you might get randomly picked by, um, an inclusion list builder. Um so yeah I think this

generally helps to increase the kind of throughput of the inclusion list by um and and the speed of of inclusion um is the kind of motivation. Great. Yeah. Thanks uh thanks a lot. Uh would be nice if people can uh take a look at the PR. I think it generally makes sense. It's also um things we've talked about before, but I think yeah, some of them are nice to add in the IP to guide how EL clients ultimately want to uh build their the inclusion lists according to what they the criteria they

sort of like value most. I think it yeah it provides like good guidelines. Okay, great. And then I remember seeing things about transaction visualization and metrics. Are there any updates there or like any other from any other clients? Yeah, I just shared the draft PR about metrics. Um if you are interested to look at it's uh beacon metrics. Um yeah, I hope to update it uh during the Berlin draw because I'm a little bit outdated

was busy with speas. So yeah, I hope to to discuss them in Berlin as well, but you can just take a look and decide if you if you need any specific metrics. So that would be great to hear from you. Yeah, it was great. Uh, cool. Yeah, thanks for watching. I I'll definitely take a look and if any other people want to take a look as well, I think that's useful to sort of like agree on the set of metrics that would be nice to track for.

Yeah. And also good news that we now have uh execution metrics specs uh repo. Uh if Jon has any ideas uh which metrics should be standardized uh yeah that that will be also great to share because we have a nice results about the standardization. It's it's much much easier to uh to test the interrop uh which is which is we are now doing uh on pure. So uh we will definitely benefit from it.

Yeah. Very very great. Uh and I yeah I remember you shared that in the the discord channel in case so if anyone wants to take a look. Uh Okay. If not, uh, thanks everyone for joining the session. Uh, and, uh, yeah, I'm looking forward to see some of you

in person in in Berlin. Uh, and, uh, see you soon. Byebye. Thank you guys. Thank you. Goodbye. Thanks a lot. [Music]