FOCIL Breakout #9

Transcript

[Music] Thank

you. Heat. Heat. Heat.

[Applause] Heat up here. Heat. Heat. recording in progress.

Hi everyone, welcome to foral breakout session number nine. Um yeah so as the format uh I think was good last time uh I think we're going to keep going with some presentations on fossil and censorship resistance related work and proposals. Um and today the topic is going to be on statelessness uh and how statelessness interacts with fossil. I mentioned it in the last call.

It's something we've been looking into quite a lot this past few weeks. Um, and it's been quite productive, I think. Uh it's basically Julian from Rick that started looking into it a bit more and then he pulled me uh into the rabbit hole and then we've been working a lot with Carlos Ignasio um Guom from the state test consensus team uh and had like super I don't know interesting discussions about what uh like the synergies and maybe the incompatibilities sometimes between statelessness proposals and and fossil and sensor resistance. So yeah, I'll let Carlos start first. Um, and then I will

follow up with a a quick introduction, maybe recapping some of what Carlos will talk about. I I don't know. I haven't seen his slides yet. Um, and introducing like some some potential I don't know solution we could uh propose uh uh that's called VPS. So valid only partial state business. But I I'll let Carlos start first. Okay. Let me see if I can share my screen and everything. Okay. And uh that should

be okay. will let me know if you can see everything. Yep. All good. Okay, cool. So, yeah. So, thank you uh very much for the introduction. I'm try I will try to briefly present some work that we have been doing together with the Rick team uh on fossil and statelessness uh mainly to see if there's actually things that we should worry about or not uh and if there are any problems trying to

anticipate to that and and try to find solutions for them. So we'll not try to spend too much time on explaining any of both things as I assume basically if you're here you already know what uh fossil at least is about. I will try to explain a bit more on statelessness but the TLDDR is simple. Uh statelessness basically tries to reduce or eliminate uh the storage requirements from nodes. uh for sale on another side and likely orthogonal I would say basically tries to create uh inclusion lists uh with transactions that could be potentially or at least have the chance to be censorship within the public meool and force uh block builders to include them

uh within a block. So the goal of those two together uh keeps being orthogonal from one side we have uh scaling state and resources. So basically have more people within uh or more entities within consensus uh rules and consensus layer in general. Uh the other one plans to improve on censorship uh resistance but as we will likely see soon uh they have a bit more in common as one might expect at the beginning. So to serve as a bit of background I will try to explain the different statelessness flavors or approaches that exist nowadays. uh there are there are three of them two of them are quite uh strongly defined I would

say the other one is a bit of everyone has its own idea we have first of all we statelessness uh so here um the TLDDR is there's um block producers or better say block builders who actually hold uh the full state and generate merker ver zkm whatever kind of proof it is and that proof proof basically gets propagated to all the stateless nodes which then can uh validate the state transition uh via this cryptographic proof verification and they don't have the requirement to store any of the current state uh inside of them which is hundreds of of gigabytes at the moment. Uh so that

basically reduces significantly the entry barrier of uh anyone that is not um one of these super nodes or whatever you want to call it which are holding the the full state. Uh from the strong uh statelessness side we have a fully different picture uh much more decentralized I would say. Basically transactions carry full proofs. So basically every time you see a transaction within the network, the mempool anywhere it comes with a proof that attests its own validity. Uh this proof is basically uh addressing that the the storage that it interacts with is in a particular part of the tree and I don't know where any kind of thing related to to storage of the transaction

is is basically proven there. It can be extended more but that's not a topic that we will discuss today. Um in both weak and strong statelessness we have um this concept of nodes fetching extra state. So basically if you run a stateless node you don't have the state. So anytime you want to get some information about that you basically need to query some note to give you such information on the strong statelessness is far more radical I would say because basically in order to transact uh you basically need to ask for uh state so so that's definitely an inconvenience as we will see later finally there's partial statelessness there's no formal

definition of that uh you maybe you have seen the res uh proposal from the uh ref people from Paradin uh or some other proposals that we will likely see later in this call I assume uh so I will not hint much but yeah just basically say that this is another type of uh statelessness flavor that we can have although not that well defined so as a summary or to address or to put I don't know some kind of picture to the idea we have a weak statelessness who stores the state there is only the proposer or the builder if we assume builder and proposer separation uh the the duty of the block producer or block builder is in this case to build uh the witness. So the proof that attest that

the state transition has been done correctly and also to construct the full block and the included duties in here would basically be just fetch the state required to validate the transactions. So in this case uh if I'm an includer and I'm in a weak stateless regime uh blockchain the only thing that I need to do is when transactions arrive to me and I have them on the meool or I want to include them on the meool I actually need to validate that these transactions are correct. Uh so in order to do that I need to query the people that have the state. Absolutely. The same happens in strong statelessness in within this regard. Although we need to add one more responsibility which is if a proof uh that comes with sorry if a

transaction that comes with a proof becomes stale. So basically the state changes and invalidates the proof. Um the includer will probably have the responsibility as it's holding the meleool to update the witness for the transaction s such that this transaction can basically be used and propagated and included uh in a block. In strong statelessness uh as opposite no node or no centralized entity is holding the state. Uh but in opposite everyone holds uh their own stuff. DAPs can also do it.

Wallets can also do it. Uh three third party services could also do it. So that's much more broader but this is some kind of summary. And finally in partial stateless proposals there's all sorts of flavors I would say. um at least for who holds the state and vops I would uh I assume it's uh nodes partially uh in res is basically some good Samaritan that it's storing all the state and serving it to you because I don't know u it's just a good person uh as for the block producer duty it's basically the same it needs to generate all the witness serve state to stateless nodes and finally for included duties we will have kind of a similar ones as we

will see in strong statelessness. So now that we kind of have a decent idea at least or a TLDDR of the uh different flavors of statelessness, we can actually see uh how stateless and fossil interact together and which are the symbiotic relationships that they that they have and also the not so symbiotic ones and the problems that they come with. So first of all uh stateless and fossile will boost the scalability. Uh one of the main statements uh in here is is the following. What statelessness allows us to do is to trade off disk and hardware in general for uh bandwidth. So basically we need to send and receive a

lot more data through the wire but as opposite we have a lot less requirements uh on the hardware that we need to have in order to be able to follow the chain and be convinced that what we receive or we have is uh what is actually correct. Um so in that regard uh basically we are lowering the entry barrier to a lot of people to the chain and at the same time if we can have a lot of these uh let's say lower resource consumption uh nodes it will be significantly easier to uh scale the chain or at least have a lot more parties that can actively contribute to it uh instead of having a more centralized uh entry I would

uh decoupled throughput. This is one of the most important things I would say. So fossil basically is decoupling uh throughput from local builders. Uh what that basically entails is that if we are forcing block builders to include transactions on each block, we can actually be sure that we will have a sustained high utilization of the gas space that exists within a block. So if we merge this thing together with the fact that um at this point blocks will come uh with proofs with proofs attached to them and we can just verify them directly and we don't need to store the the state as it grows. Uh we can be 100% sure that a lot more people will be able

to follow the chain and a lot more transactions will be able to be generated uh on each block. So generally we have more transactions on each block and we don't need to hold the state. So that means we can have a lot more players uh within the ecosystem. Finally, we have uh the ability to manage bigger payloads. Uh so basically depending on the tree or structure or proof system that you use uh for the witness of the blocks that can have different numbers but generally it will always be true that once we get the block and we get we get a proof uh that test the correctness

of the block and the state transition. One thing that we can always be sure is that the proof will always be smaller than actually receiving the whole thing. So basically we can receive a state div for instance or we can receive just a small cryptographic proof that has as a public input the root of the of the previous state and just with that and this small cryptographic proof we can actually make sure that the transition was done correctly without the need to download massive data or to hold the state. This is some kind of image that I've tried to make to showcase or or summarize what I'm trying to say. But basically with a couple throughput from local building and we enforce inclusion

list uh to prevent censorship this comes with the extra benefit that we always uh get closer to uh target gas limit uh full utilization. From the statelessness side we have no massive DB. We have um no longer slow disk or IO uh punishment. Also, we have fixed size witness uh which is verifiable in a succin way. And usually if it's not uh fixed size, it will be decently small so that we don't even need to worry about it. And finally uh once we have a statelessness regime within the chain we can definitely make sure that we bump uh gas limit and throughput because we don't need to worry about parties just

disappearing like validators just not being able to sync or keep up with all the storage and just dropping. So with stateless that's not an issue anymore. So these two things combined at the end allowed you to have more data load uh more data within the eels because we have a big we can set a bigger target uh gas limit or more throughput and the witness will not grow linearly with the amount of data that we put in blocks uh when the throughput is increased. So that it's beneficial per se. Uh finally this will all lead to an exhaustive an exhaustive utilization of the gas limit or gas uh target gas limit. Um and in that regard we don't need to worry about

the cost or the implications in regards uh this that this will carry over. Then about the censorship resistance it's obvious what fossil is good for that. That's its main goal. Um I would like to add that statelessness can amplify at least or help uh within that a little bit. So sorry within statelessness we can have um a significantly lower set of requirements for includers and for a testers. What that basically means is that if at some point I'm not required anymore uh to have 32 E uh of stake and have the whole state in order to be able

to keep track of the transaction validity in my main poolool and all that stuff. I could arrive to a point where I can just run a fossile um client to put it on some way on basically any hardware. it will it will just be super simple uh as you will not need to hold any state and you will need to you will not need to do any massive data processing. Um so basically this is the goal of statelessness and so that definitely bumps up uh the implication that fossil can can have. Uh second is that there's other kinds of uh censorship resistant attacks. Uh not that common I would say uh but

definitely uh could happen which is for example a state bloat attacks. Uh in this case all the nodes that are stateless will not be suffering at all uh from these kind of things. So this just eliminates uh a lot of risks uh that come from attacks that can be used to do censorship resistance but at a different uh part of the protocol uh which is maybe not so easy to tackle uh from Fossil's perspective. This basically uh brings us again to the question of who actually holds the state. If now includers and testers will be uh like these new kind of stateless nodes uh which don't need to hold any

kind of uh data or state there's different options. Uh the summary of all of this is there's not a particular one that we are all happy with like block builders reduce significantly the burden um but basically centralized a lot um a lot more I would say the network and on the top of that they are already taking care of building most of the blocks. So if now the map uh the me uh builders also take care of serving the state um yeah that will put the whole chain on a tricky spot. We can pass the or delegate the responsibility to wallets and and dabs. Uh the problem is

they are they are not many uh already and it's hard to find like useful and good ones. So if we increase the target difficulty for them to even exist, it it's likely that we will see we will have issues at the very least to get much more uh to to get to a much bigger ecosystem and much more flourishing ecosystem of DAPs uh existing. And finally if we use a stat as a service like portal or other third parties like infura uh it's not clear that they can serve data on time.

we will see later just in time uh windows rec computation in problems like this one but nevertheless it's also unclear uh whether that can be a long-term solution that we can use or not. So we have mentioned already that we're trading this by bandwidth and trading this by bandwidth uh is good for the storage requirements and hardware requirements but is bad in basically the fact that if we don't have good bandwidth uh we we're cooked. So we took some numbers from uh Pope's um post uh on block propagation times blob propagation times sorry. Um basically for stateless witnesses we can

assume that around 200 kilobytes to 3 megabytes would be a range that covers all the flavors. So from vertical trees which will be at the lower end to binary trees or yeah medical patricia trees I don't even know how that will look but not good I assume so to the 3 megaby range which will be probably the worst case that that we could find uh in binary and for that we can see that basically the message uh arrival times start to go really bad uh when we arrive to the megabyte. So if we now assume that we get a lot more participants, uh the network the network gets a lot more crowded, we likely require more jumps to get to our destinations and propagate

blocks and messages. If we include all of that plus the fact that we need to send plus the fact that we have blobs, it's likely that some of the some of the parties that are now participating within the consensus will just not be able to keep up because they don't have the bandwidth. Uh so we should be careful with that and take benchmarks with this shadow or some other kind of tooling to actually really assess what is the what's the limit that that we can get to and what is a statelessness solution uh that actually can work on the long term if we bump uh throughput and gas limit up. So basically have bigger blocks. Um stateless fossil although

sounds contradictory suffers also from from low entry barriers at the same time and this is related to to what we were saying previously. Um notice that it's good for me to have a lot uh less requirements in regards of hardware but at the same time it's a lot harder for me uh when or a lot harder for the network let's say not for me when I have those requirements because it becomes a lot more difficult to set the dull for a lot of parameters. So for instance uh when validators need to download all of the information that we were showing previously that can just turn out to be too much information to download depending on the bandwidth you have and depending on the connection that you're having at the moment. So basically if if we have 50 megabytes per second uh sorry megabits per second we should be fine

but the problem is we might not have this bandwidth all the time it might vary. So if it varies when we are doing some operation that is critical or we are testing or we are know doing whatever uh this might result in an issue also the bigger the state becomes the bigger the proofs will become so we should take this uh into account the biggest risk of course is that we have peers that just lag and drop out and decide to not participate on consensus anymore due to that we have also the problem of griefing attacks. Uh so for griefing attacks, one of the main issues that we have is that uh imagine I'm a stateless node. I query some full node or third party or whatever for some information.

It turns out that what it returns to me is just invalid or I didn't receive it correctly or whatever. I need to query again and I might need to query again to do a witness computation of a transaction. So in that sense I will for sure not be able to include that transaction uh within the next IL. Um, so that's definitely some kind of not sure if attack, but definitely a problem that we should be aware of because it doesn't even require it to be intentional. It just needs to happen and can happen. Finally, there's some uh small validity windows in strong statelessness that is related to the previous thing that we were saying. So for instance, imagine that I have a transaction that

comes with its witness at t equals z. Then the state changes this transaction is no longer valid at t equals to and so the includer might need to just recomputee the witness for this transaction because it's managing its mempool. If we put that task on the top of the includer, it might actually become an issue because the includer will not have one transaction on the meool but might have hundreds of them and so it will need to query full nodes or whoever has the state in order to be able to recmp compute the proof for the transaction so that the claim include the transaction on the IL. So the more transactions we have on the network, the hard the harder it becomes to to

actually do all of the duties correctly. And this is to me at least one of the hardest and most problematic issues that we have found um on these um weeks of discussion which is basically stateless fossile leading to an IL uh quality lowering. So basically the pretext for this is fossil is built on top of the assumption that the mempole is always working correctly and it's maintained or pruned. Stateless mess uh come with a lot of trouble because as you can imagine pruning a mele when you have no state is not an easy task and can imply

a lot of different things. So basically for pruning uh we have uh the issue that we need to query uh these super nodes or these nodes that have all of the state available. We need to do that for every single transaction. Otherwise if we are a stateless node and we are running the mempool there's no way for us to be sure that the transactions that we have inside are correct. So it's very easy for an attacker to just plot our meool and me as a stateless node that is including transactions. I will just get get garbage all the time. Like it's it's really difficult for me to figure out what's a valid transaction and what's an invalid transaction if I have no state to query them against. But at the same

time if quering to another node now has a delay because I need to send the query through the network get it back and do the computations. So in weak statelessness, this just becomes like a big pardon. But in strong statelessness is even worse because the only people that hold the or the only entities that hold the state are users, wallets or dabs. So it's it it really becomes an issue to know who to who to query, when to query, when to just leave the transaction, what is valid, what's not, and at the end it just ends up with that are completely full of garbage.

This is the vulnerability that we were mentioning which is the mele flooding attacks. Uh if we have per transaction validation then we have an issue anyways because as we said if the transaction comes with a valid witness but we jump into a new block state changes and the transaction witness becomes invalid. We need to regenerate it anyways. For that we need access to the to the network and access to the network will be expensive. So we fall back into an issue. So hopefully the way not maybe not the way to solve it but a way to at least suffocate these issues and allow for a decent stateless solution

that serves us for the short term and midterm will be presented uh now by Tom. But the idea that we got at the end of the study was basically that it will require a lot of work from a lot of parties that it's not just us or it's not just protocol to actually support a fully functioning strong statelessness or even weak statelessness which in in the sense of not just having a chain that works but actually actually having data that is available for querying uh for like the major public which is what what most of us need to do, right? It's not just following the chain, but actually getting information about it and about transactions that

happen inside of it. So, that will be the conclusion. I think that now the presentation uh from Tom will just showcase a solution that basically avoids all of the problems that I mentioned while having all the benefits that uh statelessness and fossil interaction should provide. So, I will leave the I will leave the floor for him. Uh and yeah, if you have any questions, feel feel free to ask. Thanks a lot. Yeah, this this was great. Um it actually covered a lot of the presentation I wanted to give, so it's perfect. Uh because mine can be very very short. Uh and yeah, I mean one question that came to mind immediately

is like what are your thoughts on um you know ZKVMs and having a snark uh and what's the impact on bandwidth then? because yeah I agree one of the big trade-off is like trading this for bandwidth uh and I wonder like where do um snarks fit in now within that picture like in is it very small I mean it's constant size but is it still like bigger because it actually also proves execution like where where does it all stand so if we go to snarks uh within GKVMs because vertical is also based on snarks but but doesn't rely on a CKVM to work.

Um the main benefit that we get is that we get proof of state transition and proof of execution at the same time uh which you don't get with vertical you you basically need to re-execute the block and you can then just trust the state changes uh thanks to the proof. Um the main problem that GKVMs come with is the fact that they are all using slightly different parameters and that impacts basically how you how you verify the proof the proof format uh and things like that. They are also not based all on the same protocol although most of them uh have some have definitely chosen certain protocols over certain other ones. Usually the big problem is that if you want to make the proof really small,

you need to recurse a lot. Meaning you need to verify the proof. This gives you a proof. Then you verify this proof. This gives you another proof. And every state that you do on this on this fashion basically shrinks the size of the proof. I think now the goal is to go to 128 kilobytes or 256 kilobytes. that that's I think already pretty ambitious but that's where I think we could get to uh if we don't explore things like latises or stuff like that I think it's it's completely unfeasible to go even further the main issue in my perspective at least is that what GKEVM do we support meaning there's plenty of teams building this we

should at least have different formats and we should support all of them we should just select one or two and set those as like the standard for Ethereum and then we ditch the rest of the world. So it's very difficult to come to a conclusion of what what exact solution do we pick because all of them do the same but not all of them do the same in the same way or with the same security parameters or stuff like that. So I don't know if that ask that answers much. Um but the DLDDR is there's a scrutiny being done but there's a lot more scrutiny that needs to happen and we need to figure out if we just accept all of the participants let's say and everyone can submit proofs

and we have some uniform format which will come at the cost of uh less specialization and therefore less speed and probably more size or we just select the best and we reduce uh we basically reduce diversity uh at the at the benefit of having the fastest and smallest. So that's that's how I see the landscape of CKV and statelessness at the moment. Nice. Yeah. No, that's that's great. Thanks for that. Um are there any other questions?

If not, I will uh quickly present vops. Let me let me show my face first and then share. Um Can Can you guys see my screen?

Yep. Yeah. Yeah. Yeah. Okay. Nice. All right. So, yeah. Um, yeah. I mean, I guess as I said, uh, a ton of the presentation I wanted to give was already covered by Carlos, which is very, very good. So I can just like skip through it and get to VPS which stands for valid only partial status and which basically is proposal of a solution for um how nodes and meool maintainers like can still sort of like deal with accepting

only valid transactions in their meool when they are maintaining it. um uh without necessarily relying on like other parties uh that will provide the state needed to to do that. Um and yeah, I think it's important to also say it's an interim solution. It's not proposed as like an endgame solution. It's more of like an in between as you'll see. Um but yeah, okay, so let's let's dive in quickly. Uh let me see what I had. Yes, I had yet another diagram of what uh you must be very sick of uh by now which is falsehold is in a stateful world. So yeah, you have the public meool, you have the includers,

detect transactions from the public meool, the build IS, the broadcast the builder needs to include the union of all transactions in those and testers make sure the builder actually included um these transactions in its payload and if they if it didn't uh then they don't vote for the block. If it did, all good. Um and yeah, so one very important aspect of this um which we don't really think a ton about uh when we don't deal with like statelessness where versus like stateful worlds but is the assumption that transactions in the meool are valid in the first place because yeah today includers are

validators. So they are nodes and they have an execution layer client and they maintain a memp pool and um and yeah the assumption that all transactions that are actually kept in the meool and that enter and are and remain in the me pool are valid is like a very very big one uh that we rely on very strongly because in the current fossil proposal includers don't don't do any additional checks right like they already like check for validity when doing their mele work. So they can just like build and assume all transactions are valid. And of course like the builder will still sort of like make sure like transactions are valid or not um when it's building the payload.

But still like this assumption is like it's quite important. Um, and so yeah, then I'm going to skip this, but um I'm still going to highlight this quite um useful post by by Julian that like kind of went back to a high level protocol view of statelessness and was also mentioning the different flavors of statelessness. So as Carlos mentioned, you have full or partial and then strong and weak. Um and so yeah, I was going to highlight sort of like um that the current direction seems to go towards weak statelessness mostly, but it does have some crucial uh issues. Um, and the

big issue I think I want to just reemphasize this one because I think it's very important is that if you have includers and nodes more generally like let's say includers and testers and nodes um only the block producer hold the full state for example um yeah then includers like don't know whether transactions are valid or not when they build their inclusion list and that's really really bad because it means an attacker can just like flood the me pool with garbage transactions and then the includers will just like include a ton of garbage transactions in the inclusion list and this completely negates the positive effects of false right because now you are as like a transaction that is maybe being censored you are

completely crowded out by from inclusion lists so you never even like make it in yes you make it in the map pool but like uh yeah you are with like a sea of garbage transactions so it's very hard for includers to pick the right ones. Um and so now yeah um you have a ton of garbage transactions in the me pool. You have a ton of garbage transaction in the inclusion lists and so it really does not play nice with censorship resistance which is something we have to be quite careful about. Um so I loading yeah other than the fact that of course relying on like two centralized builders to do yet another task is is very bad in my opinion. uh we just like should not

do that. They are powerful um uh enough uh that we need to constrain them with like upgrades and protocol things like fossil. So maybe let's not add responsibility to these two very centralized entities and yeah if you move towards like a strong test statelessness world as Carlos mentioned um then it it sort of all works out like it's great because like the transactions will actually come with their witnesses attached um but then the big big problem is like who is responsible for actually generating with with these witnesses so holding the full state and like generated fresh witnesses uh that users can attach to their

transactions. Is it wallets? Is it dabs? Is it the portal network? Is it like sub some nodes that are like I don't know staking 248 E? Is it all of the above? It's it's very hard um to decide and it takes a lot of research. And so um I think this should be the research that keeps going. But until then maybe we can go towards a more like yeah temporary solution. Um and that's what I'm going to present now very quickly.

So this is VPS valid only partial statelessness. And so it it exactly follows on on the sort of like intuition that we both gave that nodes actually need to have some crucial minimal information to determine whether transactions can enter the main poolool or not. And turns out that this information is is not like heavy in terms of of storage. It's basically the address nons and balance triplets that note would need to store. And so this is a partial statelessness solution because um you will ask nodes and testers and includers to only store the address nons balance um uh without like storing any

additional information. And so this by by having this um they can update this they can keep this uh information updated um by relying on block producers to provide block level witnesses. Um so how it works is like yeah nodes all store the address nons and balance triplets and then you have block producers that every each block they provide like block level witnesses with like the fresh information and that allows nodes to keep storing and also updating the address nons and balance triplets to either keep or prune transactions out of the meool. And since they do that then the whole censorship

resistance for thing can work as it does now because we are back to assuming all transactions that are in the meful are actually valid which is kind of nice. And yeah the thing that is I guess a good like the the highlight of the proposal is that um today it will actually mean just like storing the minimal information. So the address non sub balance fields will lead to a 20x reduction in storage um from like 233 gigabytes to 1159. Uh and those are like rough numbers sort of like theoretical numbers that uh well the not the 233 but like

the the reduction can probably even be improved with with compression because it this is uncompressed. Um and so yeah um that's basically the the crux of the solution is like you still ask nodes to um store some part of some parts of the state but only the part that allows them to determine whether transactions are valid or not uh according against the pre-state route u and you preserve all the CR properties given by fossil and you also um reduce storage requirements by 20x which is kind of And this works with any of the proposals like whether it's ver or miracle proofs

or zkvms like it's all the same thing. Um you only ask nodes to to store partial uh state. Um, one thing that needs to be figure figured out a bit more is like how to do to deal with 7702 transactions and more generally like account abstraction and that's something we are looking into. Do we need to like maybe store like an additional field um or not? Uh, and what we will would it look like in the future is something we need to to look at. But uh other than this uh yeah uh we'll see how it goes and if uh the post is going

to come out very soon. So if anyone has feedback or wants to contribute and participate uh let us know and that's it. Thanks. Any questions on this? Uh I realize we've gone um quite far in terms of time. So um yeah, let me know if there are any pressing questions otherwise we can take it online offline and and also like keep going on the implementation side of things. No questions. Okay. Uh all right then implementation time. Uh I haven't

seen a lot of uh and yeah thanks Carlos again for the presentation. It was great. Um I haven't seen a lot of uh discussions in the discord these days. So yeah, I feel like um K Jacob came back and he was asking whether like there was some efforts done on testing and I I I didn't think there was yet um because everyone was focused on interrupts. Uh but uh yeah, I just don't have much to say myself. I just want to like check on progress. Uh how is everyone doing and is it time to make a big push on tests uh and try to make

progress there or are there still a lot of blockers and just like getting devets uh Okay. Anyone um does anyone have updates or things they want to discuss? doesn't have to be, but maybe just like to know where everyone is at. If everyone is very busy

with other things, that's fine, too. But just to get the vibe check on Nethermind side, unfortunately, not too much progress. We've kind of been focused on other things around Perra and various things, but uh yeah, just need to make a few more code changes and then start testing really. Cool. Okay, sounds good. Uh, still trying to test on the inter part of things, right? Not not the testing. Yeah. So, we I got the code reviewed and there was a few things that needed to be changed. Um, so I'm going to finish up with that and then work on interrupt.

Yeah, awesome. Sounds good. Uh, same for Terren and Prism. Okay. And then Jun, do you have Yeah. Yeah. Maybe I can share my updates. So, Terren rebased Prism to V6 and I reflected that to uh my PR and I also fixed G bug. So, it should filter out blood transactions, but it wasn't before. So uh I I I updated Curtis's config to spam out blood transactions and make sure G doesn't include blood transaction in the

ILS and I also look into the um interrupt issue between Prisma and TEU and it turned out that TEU TEU calculates inclusion list root differently from Prisma load star. So all three clients produce same influential list committee members but somehow tech calculates through route differently. So maybe can you look into this and I think in parallel I can uh start working on testing if it makes sense. Yeah, sure.

Thank you for reporting that because um yeah, I remember I had some issues when calculating the committee road and uh if I'm not wrong, I got inspired from by the um prison code. So yeah, I'm going to have a look uh that cuz yeah. Okay. Uh I keep that in mind. I have a look this week. Yeah, I try to modify tackle code to make it correct. But yeah, I can share share the log if it helps, but yeah, sure. It will be much faster for you to take a look into it. Yeah, cool. Cool. Thank you.

Uh, sorry. In um I I looked at your guest PR. Is someone from GU actively to your knowledge actively looking into this uh reviewing your PR and and stuff? No, not to my knowledge. Okay. People from GU, if I remember it correctly, gave a review, but I guess they are usually busy with other commitments. Yeah, Cena Cena gave a review, but um doesn't seem very Okay, I'll I'll chase him on that. Thank you.

Yep. Awesome. Thanks. Okay, thanks for the update and yeah, didn't know that there was a problem with the blood transactions and cool to know there is something to look at with TEU as well. Um on any any other clients uh have updates to share if not yeah maybe what's the best way to go about the tests now? Uh do you have ideas Jun and Jacob? I know you mentioned it as well, like how should we

go there because we've been talking about it for a while. Um, and there was a of course a bunch of things to do in the meantime, but is there something I can I can do or like how should we move forward with this? Um, yeah, I'm going to try to, I guess, reach out to the folks working on some of the EPBS stuff and see if they have any experience with that cuz I think it' be somewhat similar. Um, but yeah, I haven't had a chance to yet.

Um, like you mentioned, yeah, I've been gone for a few weeks, so uh can start taking a look at that. Okay, nice. And then yeah, that's for so there is the steel team that can still be helpful and I think they were like ready to help also on the execution layer side, but I'm not so sure there is like an equivalent for the CL side of things and that might be like the most tricky part. I don't know. Uh but yeah, it would be nice to like does any of you have ideas of who to reach out to for C related testing stuff?

I don't think for EPBS we have done any tests either. So it's not like a good example to look at. I think for the EL it's like Peter Davis and those steel team which you guys mentioned. For the CL it's typically like Justin U from the security side. So for the CL we have the spec merged. I think we just need to generate a set of spec tests given what we have that's the existing one and clients can run those. Um we also need to write new spec test as well. That's something I think it's a hole to be filled that we can do it. It's basically Python right? You write you write the Python test vector and it generates bad test. So yeah, if anyone's interested um feel free to take that item and there

are also um documentations on how to do it. I haven't done it before. I've done it a few times but not extensively. So yeah, but uh Justin um from the EF security is the person to talk to here. Okay, perfect. Yeah, that makes sense. Uh I can I can ask him what his bandwidth looks like. Uh I know we also have someone else that's now looking at the specs a bit more at the EF in the same team. So maybe we can uh scheme as well. But great. Okay, that's helpful. Thanks a lot.

Um and yeah, if there is nothing else, well, is there is there anything else before I close this off? No. Okay, great. Uh, well, thanks everyone for coming and uh and see you guys online or in two weeks. Bye. Bye. Thank you. Bye. Bye.