EOF Implementers Call #69

Transcript

I'd like to W welcome everyone to EF implementers call number 69 um March 19th 2025 um the agenda we have today uh we have the testing road map um client updates EF devet one and EF devet 2 um any requests to add to the agenda before we get going forward how's everyone doing as my microphone working yep I can hear you fine cool all right so let's uh go to the first agenda item testing Mario you

typically leave that off got anything for us hey yes um I been um away for last week so not that many uh regarding East but I reviewed uh I think a single PR yester yesterday um and it got merged um just to comment that I'm skipping reviewing uh PRS that are currently in draft there are a couple of them but if you want them reviewed just uh move them to to ready to review and I will take a look there are two right now that I will be taking a look um is uh 1331 and 1330 no sorry 1329 uh so that's those are the next on my list but but yeah apart from that not that many um uh many many many things to add unless we want want to jump into e

testing road map to discuss that okay um there was a mention on the eof testing Discord um about blockchain PA engine I was just wondering if there could be some clarity as to what that is you mean the blockchain engine tests corre correct blockchain test engine yeah right so I defer to testing team I haven't seen that question uh but the question is whether we require to

run blockchain test engine basically for UF do they give us anything so I so yeah let let me I can just clarify what blockchain ands are basically it's just uh using Hive to run um via the the engine API test this is basically just blockchain tests but for for Hive and for the engine API um there's not that much of a difference um but for example the container tests they are not run this way uh yet uh if I'm not mistaken uh because we have to fill them using um using um estate test and then blockchain test and I don't remember right now if that PR is merged but yes

in general just um uh yes just engine API testing is is basically the same as as as blockchain testing uh but yeah the different consumption method not that many differences so for now the clients can skip testing with this I mean uh it's it's nice to have definitely uh but it's not going to tell you more information right now because since e is purely evm uh is purely evm based uh differences I think running from the engine API um I I can give you an example of when that matters for example when there are new uh new payload uh arguments to the to the for example engine uncore new payload uh that's

that's when it matters but since e is purely evbm changes there's not going to be that much difference of running that now it's it's nice to run we're going to run them eventually uh but it's it's not going to give you any more information right now yeah in my opinion at least yeah thank you okay was that your question about the testing road map 2 in Discord was that for me or uh that was for Ben I think Ben had that question in Discord when I was talking about the agenda let bring my Discord no it's my

Discord I un wted my Discord that a bad thing I think this wasn't related to the testing Ro M okay I guess it's going to bother me until I look it up now so I'm on my [Music] phone oh yeah that was from P planing to discuss have testing your map in more depth yeah yeah so so basically it's about answering a bunch of questions like by when do we want a certain kind of testing ready to to say that we're ready with eof testing and be confident

about it so what do you want to be ready by the fusaka scope cut of day what do do we need done by the first test net and what do we need done by the main net launch whenever that happens so if we can lay out like the various deliverables and and think about whether um um you know how we can uh plan for them being delivered uh that's the general theme I want to discuss now okay Mario got a hand up yes um I I can just comment on my perspective um I think one of the things that we have to

complete is checklist I haven't checked the uh the completeness of it but I think that's like the first uh deliver that we can show uh in the in the ACD call that we have like a complete checklist and and we have reviewed this checklist and then we have uh implemented all the or ported all the tests that are in the checklist um another thing is that we have been discussing on adding like um uh require requirement for um code coverage in in in eels at least and ideally in other clients too I think I think the approach for e is going to be a little bit different because um we have uh code coverage for the container validation

and also for the execution so it's going to be like two things two different things that we have to fill coverage for but I think this having just this like a check check mark that we have done uh code coverage and the in the the tests are basically doing all the all the all the required line cover as a minimum as a base minimum is is another confidence uh booster in my opinion we are planning to do this for for other eips uh for pectra eips uh we we we have done it with the help of eels froms Guru from Ms has helping us uh just basically running all tests and and just checking line coverage and see that everything is every p is covered um it's different

from Branch coverage uh because I I think I think the the line coverage is is the very minim and and just showing that we have this is is a is a nice is a nice nice thing to have um yeah that that those those are my two comments right now okay but these are things that you want to you sort of would like to see done before when relative to the U plan in general that's a good question I mean as soon as possible or um right just to just to be able to say that we're on track or uh by some time we we got we can we can you

know uh say that we're ready to to ship this are all these uh things you've listed now like we should have them done before faka cut off to say that we're on track ideally yes I think but uh I don't know if you have but is it realistic even I think yeah of course two weeks away or one week away from now some of these things I think are like Final Approach items like the code coverage metrics um as long as we're building um it defin one we could start considering it once we get that done um and I think those

are like you know once we freeze the spec and have all the implementations um that's that's my uh my take on some of these metric things I think a more relevant question question I think for Pat was trying to get to is when we want people to have implementations of the devet One features ready when do we need to have the initial uh set of of East tests ready um because we can't do code coverage if the East tests aren't written um Spencer and Peter yeah I just wanted to uh jump in and say that having I mean having a high view instance with uh all the passing um I guess the test with the dev Nets is um like a good sign of um like

having that public interface and just being able to show hey like all the clients are passing I think would be would be good to have um and I also have a question this is maybe more for Mario actually um can we run the eof tests in Hive as I understand right now that UF test are ran using a specific uh command client is that correct yeah so uh we have two types one very different type of test that we use for EF which is container validation and this one requires a special consumer uh from each client I don't know if they all have it implemented I think I think they do correctly correct me if I'm

wrong than um yeah all the clients have that um that's the a that's interface we use for f testing yeah so I think I mean we could use consume direct uh but I think I think the I I think I can can run consume Direct that's one option and the other easier option for us in in terms of General infrastructure is basically just running re refilling the the container e of container tests as state tests or and then also blockchain engine tests and then just run that I think that's that's the easier approach for us it's we don't have to like code anything else for consume direct for UF and it it's it's basically just plug and play um so I

don't remember at the moment if I merged that PR to be honest um but there there was a PR that converts every single EF container test into into into state test and also indirectly into blockchain and test so once let I I I'll I'll double check that and then I can tell you and we can definitely just run those in Hive so let me write this down hive discussion um my expectation is because we have devet running that all the four clients that are on there can be run in a hive um because they all use the same engine API that is used in production so all testing needs to do is just set up a hive instance run point the um East test um that produce the hive blockchain test

set that we get results I think we're there I don't think there's any changes that need to be done in the clients uh because Hive is testing basically production environment and eof devet one is a production environment I've got a question like one what is the checklist I'm not sure I know what you been here I can give you the link I'll show it right now this is not the tracker MD uh yes I meant tracker yes you mean tracker in the okay and it's in

the The Docks I think let me let I I'll share the link in a little bit but are you saying that we should have completed the migration from ethereum test to East by by end of March basically so that's a good question um I think if not if it not possible I think just having theum test is just is just enough and just mark them that we have the problem with having like two separate sources of testing is that we have to make sure that everything every test is is is run and executed by the clients so refilling them it's like a it's it's it's it's a process that can lead to

some tests been missed uh so ideally yes if we can if we can Port everything that would be nice um but I yeah I think I think it might be unrealistic to be honest let me let me will check and see the and see the the current state of the checklist yeah I think there's there's a bunch of items missing there and I'm also not sure if tracker actually is complete but um could we could we somehow ensure that the theorem tests which are not yet ported are run for East for example by including them in East releases somewhat uh um like in the CI process that we just download the

ethereum test fixtures and just include them in the release somehow would that be feasible because I I I kind of see the point that the clients not always usually stop on on running East test and don't don't go into ethereum test or any other yeah I I think I mean ideally we should have like a a way of filling everything we don't have right now in CI we only fill East tests and we only release that um but we're working on uh two solutions right now we are working on um the first one um running uh in Hive just using consume just fetching

from the ethereum tests repository and running that that's one solution and the other solution is we are working on a um a reader to to get the etherum tests fillers and then just fill them uh ourselves and then put them with the with the release um so those those two are work in progress I think we will have a clear revew on which uh which solution we're going to use next week we're still working on on on how to make this but yeah ideally if we can provide one source of UF tests that you can just simply point to and run and make sure that the C is correct that I think that's that's just the best idea yep okay okay cool that would be

great because we could then treat the migration and coverage um as sort of orthogonal tasks right yeah definitely and the other question is about coverage because you've mentioned e coverage but we have also been talking maybe like EV ev1 coverage could also be a an alternative that we can use because we already have that coverage line coverage of course yeah absolutely I think that's that's a great uh starting point the the the only advant Advantage I mean the the main advantage of of having e coverage is that uh the python code is very readable and it's really

hard to like hide missing coverage in heels whereas e evm one coverage if you have it we will need like U some help from you guys to help us par through the actual missing coverage uh but if you you guys can provide that I think that would be very very valuable just basically uh give us give us the current evm one coverage uh uh that is container validation and execution and every test that we have just pointing out to us which uh uh we what what's the missing missing line coverage that is actually important in the in the in the ev1 source code I'm not sure From vm1 perspective

we have any any missing line coverage I haven't checked recently but I think are we at 100% now we have one yeah one yes it's one yeah I think I I found I found like three three missing things and two of them were kind of implementation defects so there was like usually double checking the same thing in two different places yeah so it should be 100% in terms of line coverage or like Source coverage it's character based but uh W that's details uh I also applied some uh some

mutation testing to ev1 source code and it actually found some missing cases so there's like short report somewhere for e one interestingly internal ev1's internal unit tests actually are not really reporting any missing covering inform mutation testing so uh this is something we can we should investigate later um uh but in terms of like General yeah cases and Source I think the East covers all of all of it in evm one I also wanted to quickly go back to this uh like old tests the old test

reple um I I would say this not really important test left there first of all they are only uh validation tests so I think they are actually less important because like kind of fathers are are coverage this as well in in quite effective way so I think they're not critical uh and secondly I there's only like maybe like three or four different group of tests that's probably already covered I can check for the next time or like even for the next week uh and this two

request that Mario mentioned in the beginning it actually work to actually bring it back to to East so these already two groups of test that are already submitted for inclusion in East and and maybe two or maybe four similar Pro request like this will cover all of it that is already there uh so we kind of me and hug are working on this and I expect this yeah I would like to say it like with 100% confidence uh but I guess we can have proper report for the next call which is like the beginning of April

that what I so like finally I think clients might may ignore this uh Legacy test repo for E because I I think we're relatively within some two weeks or months we'll bring all of it which makes sense to to move to the east so that will be done and I think think we shouldn't bother clients with the information they should also execute these tests okay so two good news like first

that the migration is actually much more advanced that I even thought and the second that we have this coverage in vm1 would that be a good stop Gap coverage metric for for now I think I think that's amazing that's that we have full coverage in in even one I think that's that's a great point to have I mean uh in my in my experience um if you if you got if you give U uh client developers a a a full like uh line cooperation and and checklist everything it will be it will still not be enough so maybe um I think we we can at least from the testing team what we can do just encourage uh client

developers to do the the code coverage themselves in their clients for them to like have extra certainty that the tests are doing their their job um but um but yeah I think having this this this uh this 100% line coverage or or close to it in even one that's that's a great statistic to have and we if we can provide the report it's it would be even better um as for the checklist I think we can we could add a remark in the checklist in in sorry in the um um in in the in the in the tracker sorry that we we believe that the the depending ports and the pending tests that we have to Port from ethereum tests

are redundant with what with what we already have in East um for for the reasons that you described P um but yeah that's my you m okay so we need a time box this but I want to end it with one observation that we're talking about two levels of testing there's the testing that we need to validate our initial implementation and there's the Final Approach testing what I would call it where everything's been um implemented for the first time and get a minor level of validation we do the final deep validation I don't think we need Final Approach testing go to devet one and devet 2 um probably need to have some growing level of devet of Final Approach testing going into the Paka but I believe we would definitely need before main net so while we need

this this testing it shouldn't prevent clients from Shipping things for devet one um and I think what we need to do what I'm going to focus on when I when I when I get off of Twitter um is making sure that we have uh some level of uh e testing support for our devnet one features which includes the change to existing tests um and then the new coverage for TX create but you know again that's initial testing testing is always a question of degrees um there is no end to testing you can always test forever and for some things you probably should test forever we're not going to shut our FS down when we're done so um given that we spent half the call on testing um I think we can move

on to the next discussion go on to client updates um anyone have any updates that they want to bring up as a clients evm one oh sorry go ahead then um yeah another mind passing all tests um up to date with pectra as well on top pector um including all Hive tests existing hi Hive tests okay um let's see uh Basu you got an open mic um yeah so I think um so devet one

um I think it should be ready as well I mean I mean you you can give the update then now I think you need most of the work there um yeah um regarding devet zero is also good right so yeah so no no other yeah waiting on yes um I I will run those on on that that Branch so the CES test will fail on devet one there's changes that need to happen because of the changes didn't one um who else is online um Andre yeah that would be the evm 1 scene evm one who wants to talk with them uh I think we're preparing theet

one changes the T creators lined up I guess baring uh the Creator contract redeploy we have also uh the Zer xff data kind and U have create stack order lined up and the hushing change also there's just one thing that's still not covered which I don't remember now increase in container sizes to B is in progress to yeah it's in progress good yeah okay um let's see is everyone from ref on the

call no East Felix I see you're on here hello yes I'm here um any updates uh for client updates for UF devet one I don't have any updates okay what up sorry the East is you meant you meant e East I meant eels sorry I got excited with the double e um eels is there anyone from eels on the call I do know for eels it's currently

um based off of an older version that e fork and has been brought up to the newest version of eels um so hello it's Peter here um hello Peter the person who um is the best to ask this is um Guru who I don't think is here at the moment um who's done all the um eel stuff um it should be like hopefully relatively straightforward um to update things but um yeah we need to go and like I to go and look at what the changes are and probably gur needs to invent it ideally it's just a bunch of packaging name changes from what I've seen I will make a note of that

okay um no one from WTH no one from gu no one from is there anyone from um Aragon Aragon recently reported they're passing East test for def zero this this new release not sure if there's anyone on okay all right any client of solidity let's get us solity update okay so we basically released the Prototype last week but other than that there's not that much happening uh the next thing we would like to work

on basically to make the low leveler functional but uh other than that not much so we get correct code we just don't get optimal code again we get correct code but we don't get optimal code right yeah exactly all right um do we have anyone from Viper on the call okay hearing

um so next I any from client updates before we go on to discuss devet one okay first question TX create in a nit code transaction ction how are people um what are people's progress on that um any concerns questions anything we might need to change um the feedback on it with the latest changes has been quite positive I think a lot of people have expressed

complaints about it and then realized that they were resolved by um the latest changes okay yeah I think it's in a great place okay thank you thank you everyone for participating in this um we we haven't implemented it yet we haven't implemented any devap yet all right um so that's just so for for for devet um if we could get people implemented it

by in 3 four weeks that would be good um we need I'll I'll make a point to get tests available in two weeks by the next call um depending on how much time I get carved out for other things like school meetings right after this call just to remark that as we are doing the implementation in vm1 we also working on East tests for the dev Net One changes so for example the East um the changes to East for the you have create stock order I think are lined up uh the ones for the ZX FF data section kind are in progress and

then yeah so we also try to to to contribute to the east test for deit one as we go okay so you said stack order and FF FF is under under construction and sometimes it's easy to to make because it's for the UF create order was very simple to do but sometimes there's also hardcoded bite codes which is which is more difficult to modify okay my indentation is not working there

we go um payout code that was discussed yeah so there's um I I'd like to propose bringing that forward to devet one um there's been a a lot of well some push back on EOS that payop code addresses that um it provided more clarity around um issues that exist without it um so I think it would make a lot of sense to bring that forward uh I've implemented it in nethermind and it's

you know like a hugely trimmed down Co lock kid so it's not it's not very complicated um so I think it's very worthwhile Fria I mean at the same time people have been complaining about the number of up codes right so I'm not sure what the net is for this one right I think that's why go ahead there's there's basically there's basically a sort of potentially a security hall

um anyway you can provide more detail I think Ben nailed it um I know Charles was pushing for um last year um and it was the argument that there's too many op codes but we didn't really add it because it wasn't really outlin the security aspect that it was going to help address U it wasn't until Willie Morris came on and made a very persuasive argument focusing on the security argument that I think people's minds changed um it was always in the overview of the of the um the EIP but I don't think it was until will came on made it very clear that no this is the problem this is what it solves we're not doing this just add nice things um and specifically it's a so pay

up code was for regular evm it's kind of nice to have for leg Legacy um but eof without it actually creates a an issue and that's problem and it solves okay anyone else want to talk about the pay code any any dissenting opinions other than the to many op codes any other things we need to worry about is this enough to to ship in a in a next upgrade rather than

one no I don't mean devet I mean main net work oh move move it out to Amsterdam I mean yeah would this be good enough or not really so basically another mind Express aort and Dev one we could move it to Amsterdam um the concerns are um that nobody will use eof they can't do safe sense yeah if that's the case yes but I mean I don't I don't see what moving what moving it to gramster down would achieve other than I mean the main right the main premise of

the pay off code is to avoid reentrancy is that correct for sending e yes re-entrancy that's that's the the concern yes but there's like isn't isn't it like a brutal way to avoid Ry or also there other ways to avoid reny like uh distor load presumably and the AL like the alternative reality would be that UF gets adopted but the r entrance is avoided differently not by sending Zas I mean you sometimes want re-entrancy and so if you're just guarding every

single thing saying it's not re-entrant then you're you potentially go in wait but if you if you use pay then you you know that you will not have Rance from from that but you know you might be calling another contract and you you do want re-entrancy you want them to be able to call back in um yes yes but we were talking about a pay op code so that's I guess a sub ited for sending zero gas with the call or or limited yeah or limited do we want to do some sort of

data um analysis of the chain to see how people are like what people are actually doing to send e and because like I have serious doubts that the the gas typ in so like making a call with a little amount of gas is actually as used as some of these claims make it sound so I don't think that this feature would be a deal breaker for eof adoption if we could have the data right now that would be good we have um limited capacity and sort of

about pushing it out to glamsterdam was um like on the same premise that it would not be actually hindering adoption but yes it would be great to have this ahead of time I mean I'm not sure it would change anything then because it's still desired and pushing out GL down is just pushing out for I know politics not it's not it's not a difficult thing to test or

Implement so I don't know if it it's not it's not buying anything other than um people arguing yeah so the the I have nothing against adding it um I just feel like it has been an issue to justify things with arguments that end up not being very sound so I I would avoid the argument that oh nobody will use eof without this because I just don't think that's true but it's definitely been requested and um I can see some people using it well um so it would be interesting to

know exactly what percentage of people will not use EF if this not doesn't make it in um so in terms of guesses we it would be good to have numbers instead of guessing um but I thought that I would like to know what's the re-entrancy solutions without this that that are out there I thought e kind of remove the ability to to set uh the gas to zero call like guarding guarding all your functions with um either um T store T load you know setting a flag

saying you can't um you can't you know this this functions act this contract's active so fail um but then that that's the Cent for previous it was estor SL but that's like a very heavyweight solution because now you are preventing anything from being reent

don't is your Bluetooth working now should we yeah my headphones are working now okay well my headphones aren't working I just took them off and went to my computer and a different microphone in case I sound different I swear I've not been taken over by North Koreans all right um so so I guess I've been reading the the Clos caption and I'm not quite sure are we in favor of adding it to devet one or not adding it to devnet one if we're going to add it to devet one we need to have a decision probably today or tomorrow I see a thumb up up for

Ben don't have a full list of all the people and the other votes vote again if you vote a thumbs up from Lewis um why why can't we keep the definite one as it was proposed keeps we changing the plans every every two weeks yeah okay so we put it in DEET to then there right it is there D was supposed to be the the E that we would like to have shipped if P

us says we're ready and we want to ship the next week or something yeah I don't think pay is you know we kind of on board that there's uh there's utility but not the same degree as as the de One updates so far because yeah there are it's I think it I think it's in the same boat as um TX as EXT code address and EXT codes type um there are solutions where you can go out to Legacy and get it although less so because we don't allow that delegate calls but you can still do it but who's

you're doing delegate and depending upon gas restriction you're in trouble anyway so yeah I'd say it's more def to all right my opinion so let's put this in down that too so we can ship oh go ahead for me it's still still like lot of work for defit one and I mean the implementation is the easiest part of all of this so implementing payop codes it's easy but uh just making any kind of test for it it's really a lot of stuff so the more we change like the mind like what is supposed to be in definite one it will just move it like

more weeks ahead and I think that's not desired outcome okay so in order to ship tests we're going to move it to devnet 2 because as as we've learned from um yeah I know people want it earlier but I I do syze with the testing as as we learned from the first half of this call testing is going to be more important than implementation all right um contract size update we we got 10 minutes uh yeah I mean so we we

talk about how eof one of the thing one of its advantages is being able to increase the contract size limit easily so but we're you know pushing out so why don't we just bring it forward and do it as part of usaka um NE mind strongly supports this okay so one thing I want to do is there's a number of proposals going around I think

we need to give full consideration to another EIP which is Charles's EIP uh 7907 this um because hasn't published we got to see all the comments switch to happy VI so this proposes essentially a variant of 5027 which was an older contract proposal where everyone is charged for Stuff Beyond 24K and it's otherwise unlimited um this is proposed back in Bogota um get shut it down without much discussion in eth magician even though

the original author how a full implementation um so if if you know this might be the moment where it goes out and I think the thing we need to consider is we can either do 7830 or 7907 um do we just raise the the 7830 was there any change in gas price raise or we just raise the limit I think there are some issues with this

uh the cost kind of increase proposal the choice one and I don't know I think it I think it has to be presented at all at least but the issue I see is that um so the the size of the co code will affect some instruction that previously were considered safe and now the cost of this instruction it's unbounded uh maybe there's like you can compute what the cost the box cist but the IP doesn't specify any limit so for example if you have X code size to check if the some address is a

contract or not now this cost of this instruction has no limit yeah it becomes variable based on theide so I mean it's some security consideration at least uh so I think people has to check if this is actually safe change because if some contracts can break because of that because they use it to do some like inspection of uh unknown contracts someone can redirect them to the address of codes that has very big code size and suddenly some changes are

happening to the assumptions previously that were valid and there are a lot of contracts um where testing for a contract was I mean in open Zeppelin it was contract size code size greater than zero was one of the tests to see whether something was a contract and so now they could all suddenly cost the huge amount probably not the huge amount the first but maybe at least the IP has specify some upper limits for the code s so it's all of these things that someone has to figure

out um one of the things that EOS with sections potentially uh helped with is in terms of statelessness where if if code is organized which it can be with e um then it could be done by section chunks where as um at the moment Legacy contracts have no no structure at all so you can't easily isolate a chunk in use all the the stateless proposals I've

seen for code are typically straight like seven byte or 32 byte chunks um as far as size and performance so I you know adding the eof code section I know would help because they're also very tightly integrated into um packet sizes for for some of their extensions too particularly verl was designed around 32 by chunks on at the leap of the node and that's why you know the 3132 was viewed as optimal because it fit in their packet size so I like the idea that code sections could be used for stat less but I I'm not sure it'll it'll survive contact with existing proposals that have more um sway in process

So based on where I put on the agenda there is one question we need to ask do we even try it for devnet one or push it into devnet 2 what are the kind of functional changes we need to do change the code size detection inside the TX create and the eof create actually not even eof create it's just TX create is where we need to change the size checks um well maybe no EF create has that too because we B that in the size we need to check the sizes in EF create and TX create probably actually return code is also where we would need to check it because the NIT code yeah the NIT code and the return code could both be

too large so we need to do the change in the op code um we also need to change a lot of tests some tests we actually test up to the code size limit right now um for things like um uh nested containers um I would think if we unnest it we would also need to consider maybe a maximum container nesting or we need to be sure that we can support all the clients can support efficiently um Unbound container nesting up to some absurdly large contract size like half a megabyte um those are the things we would need to do so I think testing again this is another case um where it's an Iceberg where the implementation is like the tip top of the iceberg and the testing underneath um is where the real danger

lies do you mean with unbounded or with uh the other one so we could do a size limit um but the size limit always implies an unbounding because if they hit the limit at 24 people going to start writing contact tracks and eventually they're going to hit the size limit of um 128k um or 64k or whatever we present it as um you know some of these Mega do everything contracts um I don't see shrinking I mean we could just one thing we could do is we could audit the system and look at all the diamond contracts and do the size calculation if we um brought in all the diamond limitations I don't know how how we could you know do that effectively that be something for a real good code spelunker but that would give us an upper limit for what the

actual um max is today and I think it's probably fairly large because diamond pattern includes lots of sprawing code so does everyone have a vote button in there what are vot options I reactions can't see my reactions you know when you're sharing a screen you don't have reactions stop my share uh we don't have numbers how about heart if you're in favor of

devnet one and to dot if you're in favor of devnet 2 say again what was heart yes for devet one um Tada no for devet two only P [Laughter] voting I mean given the argument from pav on the on the pay up code to testing would that be also argument for this one yeah I was I was about to press the just

because just because the capacity is maybe not enough to to properly look into this or we find more resources for testing yeah I mean I would I would say since we have two potentially competing things um to De that to to resolve which way I need to drop off I have another call I need to go on for for school stuff so um sorry to cut this discussion short you can continue discussing after I leave um but we won't have time for the rest of the agenda thanks