Dencun Interop Testing #31

Transcript

[Music] foreign [Applause]

to our 31st testing call um yeah so I guess we can start with any updates on devnet 8 then Mario you had some um some updates from the testing team and after that uh the main issue we had for devnet mine to discuss was that the empty address handling and I think Peter you've got some uh thoughts on that um yeah I guess anything people wanted to share on the on devnet 8 from the past few days we seem to have had some issues with the

military is being run on different machines this was not intended so it might it was probably a mistake that I've done um we're going to be looking into this another thing is I really have had good finalization in the past week I think most clients were able to keep up there was some issues within prism but they both have been enrolled since and they were able to stay at the head there is another issue with Aragon where Aragon was returning uh some wrong invalid payload index for a specific

call and I think even for payloads that were not invalid so I think there's a fix that needs to come in from that and that's it pretty much the EQ anyone else have anything to add on that yeah I would like to comment about the the issue in Aragon yes we um there was a problem in the code that we um like there was a transient error uh like something akin to a lot of memory I'm

not exactly sure why it happened but the problem is that uh if if we have things like like out of memory we of course should not return invalid for that block it's a transient error so now we've fixed the code so that we don't treat such and entrance sorry transient errors as as invented block got it uh Justin oh I don't know we can't hear you Justin oh okay uh in the meantime okay Justin's

fixing his mic uh Andrew is the fixed merge somewhere um yes it is uh but I think you know devil there are some changes for devnet nine so I'll point you to the like pre devnet9 comment yes I'll do that or something all right check you guys hear me now yes okay yeah so real quick um we're doing okay on dead net eight one of the things that's curious is that we're keeping up the Nimbus basic pair is keeping up just fine but it's slow like it's kind of struggling so that's going to be investigated but nothing else to report anything else on devnet eight uh yeah

Marcin yeah so uh in Netherland after last awkward deaths we added filter to have only marked 16 transactions per one Center 16 block transactions and right now it's uh since Friday is running on on devnet right I was spamming the network a bit and looks like we are behaving while building blocks not missing spots and generally it looks fine the next step is like we have it already implemented implemented but it's not on devnet yet it's the functionality with storing blobs like process blobs until finalization so it needs a bit polishing and

would be added to the net ad in a few days and internet nine scenes very beginning awesome things anyone else so for Lighthouse we've been um looking into some like raciness we have with single blocker blob lookups and trying to like reduce the number of

lookups we're making because we're right now like over querying um and then looking into this we realized some of we're handling some of our caching incorrectly specifically for the scenario where you get a blob that's valid on its own so it's kzg commitments are valid um but then you later see the block and the kcg commandment commitment in the block doesn't match the blob so like evicting this correctly and also making sure that like um we're able to import the block when we actually get the correct uh matching pair so we're still in the process of fixing

this stuff it hasn't been stuff we've observed on the devnet but I think these types of scenarios would be good to like test maybe on devnet9 um that's pretty much it um one more thing I wanted to mention was that we uh cleared and updated the prism uh bezel as well as the prism ethereum.js mode I think and at least the prism bezel's still been sinking since the morning um it's kind of slow for such a small Network could someone have a look I can take a look after this

cool anything else on devnet8 okay so okay uh then in that case uh next up Mario uh Vega you had a couple updates you want to share on the testing front shared a lot of those uh on the agenda but um yeah do you want to quickly recap yeah of course yeah definitely um so yeah just like a brief update of

how we are standing on the devnet 9 updates for the execution specters And Hive um so yeah the first uh thing is that we have the 1153 that has already merged for the nine so that's covered already which didn't which we didn't had for uh the date um so that's good and we have the update for the 4788 um the newest address that is on the current draft PR for the EIP so we have the VPR ready but we are missing the transaction details but I already been like lying about this um so once that merged in the pr we can I'm sorry in the EIP we can update the pr for the

execution specters and merge also and we also have a PR for uh 75 16 which is the blob base fee opcode we already have test for that and it's ready to emerge we will be merging soon maybe today or tomorrow and once all of those PRS are merged we are going to make another release which will be the devnet dime release we'll uh contains all of the changes for W9 and um we also will be updating Hive to contain all of these tests plus any other definite 9 related Hive updates um we are looking to do this in the following couple of days so we can start running uh the midnight ready tests for the for the clients

um that's on the buy spec uh side of things on on hive we have uh we create yesterday we created the um the test case for the issue that we were seeing on on get on on the mainnet so basically uh the issue and why we didn't catch this in height is because all of the pre-merge blocks are marked as zero for Hive just for to make everything uh easily considered configurable and the issue was that uh and may not that that is not true we have the London block that is more than zero obviously so what we did in in this PR is to try to make uh at least one of

the pre-merge forks number greater than zero so we have one single test that hardcodes the London block number to one just to be able to catch this issue and it was able to catch the the get issue before and and now get this correctly passing this test after the batch so um I we also run uh the test this same test on uh old clients basically and we already notified if we found anything on your client another update is that the mock Builder is the nav ready we already started testing with a bunch of the CLS and basically most of them are passing and

we've had we found a couple of issues on one of the of the seal clients and we have this a hive simulator which is the DPR at the bottom of the of the command that we have on the on the issue um so if you go in this PR you can see how you can run the Builder API test on on the CL on whatever CL do you that you want to run um this is a very simple test basically it's just making sure that the network starts so you have the El and the ecl both configured on the left at the first Epoch I think and then it starts sending blobs and then you have your uh Builder configure which is the mock Builder so

this Mac Builder what it does is basically just requests from the El a payload and most of the time it contains blobs so what it does is just passes along that build to payload to the CL in the form of the Builder API so we can test that uh back and forth interaction with with the CL and the and the and the Builder API um so yeah that's basically it um I posted the link also to the mock Builder if you guys want to take a look um we have some options to make like uh this mock Builder configurable so it can induce errors for example um just inserting the incorrect Beacon

route in the payload or whatever this is is like a server so you can basically just instruct the server to just introduce errors at on demand basically so if you if you guys go into the into the the repo please take a look just uh any ideas on what other types of issues we can inject with this mock Builder will be greatly appreciated so yeah that's basically it thank you okay then I guess moving on to devnet

nine uh so the main issue we had on Awkward devs uh last week is this discussion around touching accounts and um and uh yeah how do we deal with uh the the system address at Peter you wrote a doc in uh High candy that you shared in the chat that you maybe want to walk us through that I just posted it in the link in posted the link in the chat um yellow can everyone hear me yes ah excellent so Yeah so basically the situation empty accounts um is that they've only existed on a few um really old networks

um ethereum mainnet ethereum classic um and a bunch of test nets all of our test Nets that I've ever had um empty accounts are gone robstein had them I don't know if anyone will have them um so basically at this point like it would be accounts are like a effectively a testing artifact in the sense that people keep writing tests for them um despite the fact that they cover situations that can never happen in production so what I think we should do is rather than continue going through this um situation where we're writing these tests that people have to argue about or what should happen in this weird Edge case that we've come up with um is we should just like assert as a matter of principle that you can't have

a merge Network that has an everyday account of it um this is quite straightforward um because either if you're we'll have to manually check like the at the merge there were nobody accounts on mainnet I'm pretty sure it's true um I did check it with a defunct flight called a cooler at one point um but we'll have to do that again it's not massively difficult um then simply for anything else um if the eip158 block is zero which is on everything that isn't mainnet um and you didn't put any account to the Genesis it's not possible for Ebony account to be created on that Network ever

and so there can't be any if we like accept that principle we can then just like assert that there are the empty accounts on merge networks shouldn't happen we could declare that any test case that puts empty account to the pre-state and relates to merge networks is just invalid um yeah that's like the basic summary do people like support this as an approach sorry I couldn't find mute so to be clear the existing rule that if an

account becomes empty and it's time to commit it to disk nothing gets written that still exists uh yes so the current rule is it is not is is that is not possible um for an account um to be created empty um the um I think the EOP is slightly vague about whether during the transaction like and every account can exist and it then gets deleted at the end of the transaction but that's not an observable Behavior like you could if you decide that as a matter of principle you're writing a client we have a data model um doesn't even acknowledge the possibility of an empty account existing that's completely compatible um in a world where they've all been deleted um they can't be created the only

question is whether ones that existed prior to spiritus Dragon are still around um to respond to like um like client's Point um yes so there's basically two there's basically two places you have to check that um every account haven't been created um certainly if you're um creating a network you have to not put any of the accounts of the Genesis Outlook and you have to make sure that you started late on the spurious dragon um the second one is that you have to go and check that like you if you have a test the test doesn't put an empty account in the Genesis Outlook um this might be a like

um non-trivial amount a slightly non-trivial amount of work um for the Legacy tests because there are various like empty accounts in places um there are tests that aren't even about MD accounts where like someone just decided to make um the empty account um okay yeah so um like if you look at the doc I linked there's a draft Eep at the bottom um which says that the T the net the tcd block is invalid if it contains any the merge block sorry it's invalid for TTD block contains every empty accounts um and that um but yeah try and client literally just have to check that there are no

empty accounts in Genesis I was proposing to actually make clients do this check um because it is fairly trivial I.E you either check that Xperia eip158 thought block is zero um the Genesis file uh the genitalic has no the accounts or you check that the mer on mainnet you check that the merge block is the mainnet merge block um Andrew um yeah uh to me this approach is fine um but I would change the execution spec tests not to include the AMC accounts in in Genesis because there are there are a

few test cases that do that yeah I mean that kind of needs to be in practice there needs to be a sort of two-pronged approach here firstly like where there are tests that contain empty accounts um you know they need to be rectified um either by deleting them or in some cases altering them so the account is no longer empty um and secondly we should make the tooling just refuse to accept that there could be empty accounts it should just be if you write a test if you try to import a test of the test got an empty account the tools should just complain this test is invalid contains an empty account on a post-emerge network

uh Maria yeah that's definitely doable I think it's super easy just for us to include an assertion somewhere yeah if they if there's an empty account just reject it because in this last example I think it was um one of us that wrote the test I think it was me probably uh and we just didn't realize that there was an empty account so it sparked this discussion but it was completely uh none we didn't mean to to do this so yeah I think doing just a simple assertion in index expect this it's just so this doesn't happen again it's just fairly simple yeah and the um there's a weird Edge case involving what happens if coinbase is an everyday

account and that is tested completely by accident there's a test that's actually about um oh uh pairing put the pairing pre-compile um that just happened to set coinbase to an empty account and if you want to pass that test you're required to like delete the empty account as well as like do what the coin device speak about is so there might be like a little bit of like tidying up work just to deal with the fact that like there are test cases like floating around that are weird because they happen to container it um an empty account by accident um most of the ones that were actually testing of the accounts you just need to put a condition that says this test shouldn't be run if you're testing post merge and just say it's a free London and earlier only test

yeah I think I think the moment that we insert the assertion it's going to be flying a lot of test cases automatically so yeah and then someone just has to go through it yeah yeah there's a I've written like a draft deep that says that you know empty accounts are invalid from most networks if I just like make that an EIP we could then like try and like get it through the process um there is one uh mild complication which is that we have to decide like um what process of checking needs to be done to ensure that

um my claim that they're in that all the empty accounts on Main Network deleted before the merge is actually true uh because obviously the consequences if I'm wrong um could be quite severe like I think conceptually it's quite easy you just there's a command called gef dump that will like you know print adjacent of every single account in the state to standard output right but you need a you need like an archive node at the merge block basically uh you don't need it yeah yeah you need yeah yeah yeah and like currently like I have like invested each one of my like tasks to investigate getting historical state to these sorts of things available but at the moment I think the easiest

thing is just to get someone to sync um a gif node to somewhere between the block where the the accounts got deleted and the merge and just iterate over the how how quickly does get take the second archive could you use Aragon or wreth um so okay so the the issue I could look into so the thing is there isn't an API endpoint in that I'm so I don't think ref has the capacity to iterate over every account in the state at all although I that could be implemented

um Aragon does implement a debug end point that allows you to iterate over the state uh um it is very slow um to the point that you yeah although again if gef is going to take 13 days and also like you don't actually have to get up to the merge you have to get up to um like block 40 million or something which was under London uh dragon uh that exactly is needed what we need do you need go yeah continue sorry yeah what's needed um we need um a reliable process that iterates over

all of the accounts um in a state Pro after this 40 million something blocked and before the merge um that will reliably check that none of them are empty and the main significance is that we need to do this in a way that people are prepared to like you know write to their clients on the assumption that this is this is correct uh basically we are saving the here's something one table inside the database that's like change sets train sets are basically the previous value that got changed

so iterative those changes should be the way to verify there is no empty accounts before after 40 million block actually to be fair if you did that um against uh I could do that against I haven't thought about it that way that that would like also be quite easy if you just like iterated over the entire chain set and like basically kept a tally of all the current empty accounts um yeah which yeah like I mean the main issue is not proof is not actually proving that it's TR is not actually like running the code it's like persuading people that the code is correct because like yeah it's like it might end

up being that I that I will like write her an implementation that like iterates over a ref archive no over a ref archive node which I have available um and someone else will say gef over a week just because if we do it twice like the chances that anyone makes a mistake and then some of the account somewhere is lower but I would really even need like for the history State uh shouldn't we just like take the plane state check if there is no empty account should like because we are talking about the future in the future that we don't have any empty accounts not just in future but presently so should we just like iterate over the place to check if there is no empty

account there should be like good enough assumption for the future aips or even future tests I mean to be fair that that is actually a point that like you would do to some extent to some extent like most of the risk is covered if you check the current state obviously you can't then eliminate the you know principle there's like some outside possibility that there was an empty account that existed at the merge and then got deleted but yeah I agree that like you could basically cover all the risks just by taking a current gef node running gef dump on it um and iterating the like 10 line yeah five line python script that checks that none of them are empty what other others can say about this for

me it should be fine like just to verify that there is no uptick out yes the significance is that the EIP um says that you can write your you can write your um your post merge code um on the assumption that there are no empty accounts and so if something happened with an empty account between the merge and now in principle that would break your client although I agree it's not likely to be a security risk in the way that if there are still empty accounts in the state it would be to be honest we probably shouldn't be bothered by that even if it is breaking if there is

if there is the case that something is found like that we can change the IP to introduce that like new information but it even that can be like special case for account I think we are talking a lot and invest a lot of times something that can potentially happen but it's not there isn't any ebm that's just up to the merch yeah no I I think that we I think that's reasonable the the main thing is that yeah the thing is all the the yeah and also if you break the evm um in a way that it doesn't work on some

historical blocks like people are going to notice like people test their clients by running them on historical by seeking mainnet so they're going to notice but yeah I basically agree it's this seems like an incredibly achievable goal um we just need to like do it in some process that people are comfortable but the state doesn't contain empty accounts so I mean isn't it a little orthogonal if the state contains empty accounts though to what we're talking about 4788 because it's not does the state contain an empty account is is this ad or the

specific address the system address empty so the present issue that the issue that triggered on devnet 9 can actually be solved by inquiring about the one again which is not empty uh the more like long-term issue is that we if we don't like implement the seat that says that there are no empty accounts anywhere every time someone changes um the way the evm works there is the potential that they will Implement a new Edge case for State clearing which we will then have to have a discussion and the goal is that by like drawing a line under empty accounts we can save like having to have this sort of conversation

which will otherwise continue in perpetuity sure I just think it's something to look into but not on this call Chris specifically yeah no I yeah my proposal is that like I'm going to go away and like actually produce like a formal proposal um it seems like people are up for doing all this work and it would probably be worth it in the long term but I agree that like from the point of view of like testing we just need to check that um the account that um all F's e is empty on mainnet and then not not empty on mainnet

and then you know that resolved the issue here we can immediately delete the test case that Mario has caused this problem um and be safe and that will give us time for people to spend a few weeks dealing with the rest of us Dano so my quick read of this is it's not the test case there's a problem the problem is we're using accounts in a new way having an account be a sender without incrementing the notes or having any other required state in it which there's no other way to do and this is just the natural Fallout of doing new things so I'm not as concerned that you know we're hitting edge cases because this is expected because we're doing brand new stuff and if we don't go through the process of figuring out

what doing new stuff means in edge cases then I think we're not being diligent in um applying new Innovative things to do evm or we should stop doing new Innovative things with the evm I mean that's the other option we could you know increment the notes every time we call the system account so I think the issue here is that um so the issue here which is like you agreed like very mildly somewhat orthogonal to the the present issue is that like empty accounts are a particular source of like really annoying and subtle edge cases like there's a lot of there's a lot of technical subtlety in uh what conditions does the empty account clearing trigger

and since there are no empty accounts the answer to when does empty a clear account clearing trigger is entirely boot um and it would save people Dev time because we have a choice here we either like either ever gone have to modify their code just to support a high professional education that will only go in the test case test Suite or we have to say that we have to assert that this Edge case can't occur and like it's quite common um yeah it's quite common for um these situations just not involved so and like it's quite common for like people to find new ways of potentially

clearing um empty accounts like they keep coming up um they keep getting tested and like there's special code um in um eels just to handle one really Niche educate involving um a hash Collision where one of the things is an empty account despite the fact that like in production practice hash collisions and empty accounts do not occur or when you call a system account we make it behave like every other account when it's the start of the transaction we increase its notes and it would never be empty then I mean you you could you're going to end

up with like I mean so like that's the new space we're creating is a system account you can do this like root level account calls without doing any change to the account which no other eoa supports that we're creating a new class of transaction system account and we're not following the rules that elas follow so this is the Fallout well I'd rather not do it because we already use some system transactions for gnosis chain and we don't increase uh system address uh the denomce of the system address there but the problem on gnosis chain doesn't matter because there can't be of the account for nurses checked so this

doesn't come up well I think for for nurses chain actually this problem uh is probably matters because there was this problem with the empty system account or nonsense chain and they had to introduce a hack into Aragon for for losses chain but because I mean we could discuss it but I think for for on this call it doesn't matter too much but yeah I would rather keep things similar between like how system transactions are implemented for ethereum and Analysis change just makes my life easier

um I would argue a little bit against don't increment because it it feels like unnecessary additional unnecessary State change you can go it without it well before against whatever thing we do we're doing a different way to start the transaction so right I mean that they were running into empty changes is not surprising I mean technically it's not really a transaction I don't know how other clients implement this but I think you know we implemented this way where we process a transaction first and then normalize the transaction into a media

message call and it's sort of the same structure that we make internal calls within the the normal transaction cultures if the user calls the call op code and I assume other clients are doing something similar to this where they process the different types of transactions put them into this call format so we're kind of skipping the transaction portion of it uh where we're updating the nods because the nonsense update be updated because you have this uh the signature and you have to deduct this value from this account instead we're like skipping directly into instantiating a call frame so I I don't know if in the increment the nonsense is really the right thing to do here

it um the AAP also says like uh you know clients could implement the like State changes directly which would also be like like I don't see why that would have to like that approach to implementing it would have to increment the nonsense uh touch the account whatever right that we're we're changing the account today through a new means that it's yes as we're learning today a little underspecified yeah I we could I think outcomes should be to make a decision on how to do this kind of in different I mean it is

specified on how to deal with this I think the problem is is that guests did not implement the specification I mean 161 says an account is touched if it is the source or destination of a call so technically the source here is the system address and it should have been touched it's just that we don't implement this specific aspect of 161 because it always occurs due to the fact that uh if the transaction is coming from an eoa then the nonce is updated which then creates the touching if it's called within the evm context then you know it has to be both the source at least the source and the destination of a call and so as destination of a call something is getting touched there so it

really the reason that we're even having this debate is because we didn't implement the 161s back to the T there's no obviously there's no issue with the with the mainnet implementation because of this nonsense thing but I just wanted to point out that it was specified I mean the point is so this this is then you get into the fact the like uh 161 is a bit vague and very confusing because what 161 actually says that it says that if um an account is subject to a potentially stage changing operation um then it's um then um it gets marked with deletion

and then if it's still empty at the end of the transaction um it means it gets deleted um whether like whether one six um where the question then becomes is um does sending a message from the account uh doing this special transaction thing does being the source of that count as a potentially State changing operation and then confusing the eop161 then lists a bunch of what it thinks are potentially stated State changing operations which you know caused a whole bunch of Confusion And I think we would be better off just eliminating the possibility of people having to deal with

um uh empty accounts rather than trying to work out what constitutes a potentially State changing operation I think it would just be better for like you know be more useful use of people's time if they didn't have to continually argue about the semantics of 161. I agree I think we should yeah resolve that at a later point I think for now we should just say we're not going to allow empty accounts in Genesis and that's going to really resolve all our problems for 4788 yeah let's say we're not going to allow um we are not going to allow people to make

many SE be empty in a test Suite or anywhere um and going forward this is the same thing and then going forward I'm going to like push a CIP which means that we can finally not have to think about the accounts at all that sounds good to me where should we write this down where is the spec for if this is allocation I don't think there is a spec for that yeah all right

well we just yeah they do have their own I mean if all the clients agree just to now go and write some PR that makes it check as you're loading the genus allocation that you're not adding accounts without a balance code or nonce then we can just yeah follow up on Thursday or next Thursday or something make sure you did it or you'll fail the high test I guess can we have a we could have a hive test for checking to see if clients accept an empty account in Genesis yeah so I guess a test should is there

something we want to add to 4788 as well sorry do we is there something we want to add in 4788 I don't think so I mean this is not really related to 4788 specifically especially if we're going down this path if we don't want to think about 161 in the context of 4788 then I definitely don't think that we should mention anything we should just simply not have the scenario occur okay does that make sense to everyone okay perfect plenty of thumbs up uh

I think that was the last thing we had on the agenda um but I guess uh one thing I wanted to check in on is uh so we added these two eips on all cordovs last week uh the the churn limit and then the uh blob gas uh no so devnet9 is not still happening tomorrow so but we decided on how Core devs last week was that because we added the two new eips um we would try to get everything implemented in all the clients by Thursday and then Thursday we can figure out uh when we want to launch the devnet so I wanted to see does that still seem realistic the teams are there people who feel like we

we can't reach that for some reason okay so we should be good uh there was another this conversation in uh all core devs about renaming the opcode and if people want to have a look at that um I don't think I don't think this changes any single uh cement any single thing in the in the implementations except the name so um yeah we can probably uh yeah wait on that and then okay uh Terence you're saying you're Weighing on the specs release uh I think Danny said on the call that it

would come Monday or Tuesday like client I'm not sure I understand your questions your question yeah I was talking with Mark last week a little bit about something like this and I I'm under the impression that during optimistic sink of Lighthouse actually determines what withdrawals are supposed to be going into the execution payload header and then compute the Merkel Patricia free route so they get the withdrawals hash which is in the execution layer header and then they hash the execution layer header to make sure it matches what's in the execution

payload I was wondering if other clients do this because I think that there's a similar situation with uh 4844 because with withdrawals we sort of have the situation where the CL tells the El what should be in the withdrawals but then the El puts the withdrawals in its header and as long as that data is always coming from the CL it's okay but during optimistic sync the El goes to the network to actually retrieve the blocks and so it never receives new payload that says these are the withdrawals that are supposed to be in it and so it doesn't really know if the withdrawals are right it can make sure the state

transition is correct but it doesn't know if there withdrawals themselves match with the CL expected and so I think that's why Lighthouse is doing this check in during optimistic sync but the same thing is true for 404 where on the beacon block you have the kcg commitments which are you know basically the version hashes that should be in the block so you're telling the El via a new payload uh hey here's the version hashes that should be in the block verify that the transaction has those version hashes and the El does that verification but if you kick them into optimistic sync and they go to the network they don't know what version hashes were supposed to be on the Block so you again have this issue where the CL should probably

compute the transaction try root after doing the verification of what version hashes were actually in the block okay it's prism doesn't do this any other CL teams so yeah I think Lighthouse during optimistic sync doesn't do the same for versioned hashes but um I also was talking to Mark a little bit about it and I think it's something we need to implement I remember that when I was testing the

Builder API most of the clients if not all of them rejected a block with animal withdrawals root on the blinded header so it would seem to me that most of them are doing the check on the withdrawals but I'm I'm not sure I I just remember that most of them did the CL so I built a one of the one of the tests was just corrupt the withdrawals route send the blinded header so without the withdrawals and see what the ecl did and most of them if I remember correctly were rejecting my blinded block because the hash didn't match what they expected

um so yeah yeah I mean yeah that's interesting that kind of makes sense okay anything else I guess like one other quick question originally when we talked about versioning the engine API we it seemed like we were trying to not closely associate the org time stamp with the method specifically and now I noticed that yeah most of the

methods have the gating both on are the parameters that you expect to be there given the fork there and is the time stamp for the fork active and I was wondering if there was like a real specific reason for both of these checks or if it would be it'd be okay to relax the timestamp check and just verify that the parameters that are necessary for that fork are not null so like a concrete example is four or four Choice updated V3 if you call it with attributes that don't include the

beacon root you would just say that's not a valid uh poor choice updated V3 call rather than then also checking is Cancun active or not this is in relation to a high test this is real in relation to a split of high tests but I mean more generically it's it's not really about Hive it's more about implementing clients and yeah I'm just noticing that it's getting a little unwieldy with how much

conformance checks we have to do for these methods and we can you know make it a little bit better but I don't really see the benefit of checking both the fork time versus you know uh the time of the uh whatever object is being passed in versus doing like semantically checking like to me they do the same thing they're making sure like is it correct to call this method right now yeah it's a big problem I mean that's not problematic it just seems like duplicate checks great yeah

other comments okay I guess we can wrap up anything else before we finish up okay well thanks everyone and talk to you all soon thank you thank you bye thanks bye foreign foreign