JSON-RPC Standardization Breakout

Transcript

all right shall we get started welcome everybody um we are here to talk about RPC Json RPC standardization there is a uh channel on the Discord R&D Discord on just this subject you'll see a lot of recent conversation on the matter um the tldr I think is that the world of RPC for interacting with an ethereum client is far larger than our execution specs would imply um so that means that there are a number of methods that are out there that people are using that they're finding useful um that are underspecified not specified at all Etc um this spacee hasn't really been

updated in quite some time um so I think one of the things that uh Felix is kind of driving here and I'll turn it over to you if you if you like Felix um there's there's uh maybe time for a little bit of refactor redesign and expansion of how we uh work with our rpcs how we get different stakeholders involved um Etc so um is that an acceptable intro Felix yeah I guess so I mean for me it's mostly just about the specific so I mean the I I've written this document and I mean there's a long kind of view there but there's also these short-term items that can very specifically improve Pro

the situation in our uh limited Circle and I think these would be kind of preferable for me just like figuring out the details of certain rpcs and for example with the tests and the specification because yeah for me it's just very frustrating I've been authoring the specification I mean helping with that and uh I also maintain the test and um it's just kind of annoying when these tests basically never work work I mean they work for GU but that's because gu kind of generates them right so that makes it easy for us but and we use them as regression test as well but then it's kind of like for the other clients there's always some issue that prevents them from really

being like I mean some of them work but they are like depending on the client various issues with it and I really want that thing to you know like be working because only then we can start actually making some solid decisions so yeah that's basically what motivated me to to start this conversation but obviously yeah the long points are also quite important okay so maybe we should talk about the RPC compat test themselves because that's that's a really good point that seems like table Stakes right so let's let's all get on the same page get those tests passing and care about them before we start proceeding with um additions subtractions you know

refactorings Etc sorry was that a question no I was actually opening it up to the room how do people feel about RPC compat as a subset of the hive tests are your test are your clients passing them do you find utility in it is it worth going back and making sure they all pass to kind of establish a baseline of RPC usage before we move forward I mean From basu's perspective yes we think that there's value there we're not currently passing them I think we're

breaking so early that we can't even tell how much of them we're passing we we suspect that we're passing a lot more than we can actually tell at the moment this is um yeah but this is specifically I think because of the um because of the uh prag Fork so because in for this Fork cycle I actually made the somewhat controversial decision to just include the prog stuff in the RP test a bit earlier than last time so for the last Fork we only really included it there after the fork was already like fully defined but for this cycle we've been sort of more proactively updating these tests but it means that like since for example on hive 2 the clients just run from their default development Branch if some stuff isn't there on that Branch

then basically we'll fail to load the chain so this kind of an expected thing and I'm fine with that I think from B's perspective I think that's kind of a good thing frankly um I'd be curious to hear how other teams feel about that concept hello from nether mind as for nether mind yeah we are willing to fix this test uh and we are experiencing constantly experiencing issues uh compatibility once uh because mostly our client uh is

accessed using go libraries which uh uh well mostly uh adapted for usage with guest and uh it breaks a lot so we are trying to fix this as for this tests in addition to fixing them I would actually add more um to cover more transaction types probably uh this is the most the hotest topic right now uh which we are trying to fix um because um well for example specification contains such field like uh transaction type text type

or type not sure about the specific name and it's it's marked as required and other fields are marked as required and in Json PC uh spec I guess but actually they are not required and guess even does not use text type so uh I would uh discuss maybe in Discord or separate call this part of the API and uh for sure we like to fix these tests yeah yeah thank you so I mean I kind of know

what you mean but basically I guess you are talking about the get transaction by hash or estimate uh call uh estimated guess oh I see estimate guess and call yeah so they do not have the transaction type that's correct yeah so I am actually I have I have it open for nethermind right now and then for example so for nethermind uh on these tests um I see um so nethermind is able to successfully import the chain and the failures in the test are mostly related to um some error conditions so this is one thing like for the error conditions we do not always agree on the error

code or on the like existence of the error in the first place and then um there are also some differences in the default parameters for each call so basically for nether mind there is thing that one of the environment options for the call like the gas prices or whatever it is the it's it differs from G you have to figure out you know like if you want to standardize on that or not but either way this is what I can see and um yeah for estimate gas it's kind of the same I mean it works but it's not um it doesn't come up with the same result notably we have um something new

in the spec that still has to be implemented in the test where like some of the tests are marked to be spec only so basically they should not fail because they are just only there to check that the result matches what the spec says it should look like for example for estimate guas is not required to use the same algorithm on all clients so you can consider these to be passing right now we just have to uh update the testing to ensure that um this error will not happen so basically will not be marked as failed and this is something which I am doing but then mostly what I'm seeing is that for example the nethermind returns the chain ID for legacy transaction so that appears to be uh a

difference and um it then there's also oh wait so it does not return the chain ID so that's the thing it does not return the chain ID for legacy transactions even though it probably should and uh it also does not return the V this V field for the signature values um uh this is because yeah the V thing is kind of I mentioned that in the document as well there are some um basically it's a legacy field but we decided that because there are so many client libraries that still use it we kind of want just want to make a part of the spec anyway it's kind of the interchangeable name of this y parity and um

yeah so we thought that maybe could be something like if for example netherite were to add the V field then they would be passing like a lot more chest so that's something to consider anyway if it would just would be pretty easy to so do do we have enough flexibility in our schemas uh to allow for both the example that you just cited with the uh V becoming y parity um as well as some of like the gas estimation stuff you were talking about you're you're talking about tests that you don't necessarily care about the results but you do care about spec compliance with them right um because they are necessarily you know uh uh nonprotocol and there could have

different implementations different algorithms right so I guess I guess my question is is this a good segue to talking about how we specify those return values with some flexibility that allows for both ignoring values in cases of gas estimation but also maybe synonyms or aliases for um Fields uh things that would allow us to do backwards compatible specs I don't know I mean I would say that for example for the for the for this for get transaction by hash we want the output to agree in all of the clients and it's not just about they it

shouldn't just be that the the the client returns something according to that is guaranteed anyway because we we basically check all of the test vectors against spec already so basically we know that the output that's in the test is has been validated by the spec U that's a precondition for committing the tests into the spec so that part is is kind of done it's more just uh for some things such as estimate gas the result is a single number but how we can come up with this number is like up to the implementation but for transactions I think they should just look the same and then when we say for example with the signature value V it's just you know in the old days it was called V and uh now it's called y

parity they just kind of changed it and I mean yeah obviously we can try to force that change but for this specific case since it was kind of a it's just like very hard to estimate who has updated the library and so on so we think it's just easier to return V and be done with it that's kind of how we see it in that particular case so we feel like that basically every client should just add this field and then it's fine and then there are some other cases like that as well where basically gu doesn't return a field that's returned by uh some some some other client uh for example um there is the thing with uh returning the author so in NE mind it returns this

field author for the CL for the block and um gu doesn't return it so I mean yeah technically we could just add author there and then I guess NE mind would also pass that test so we just have to make a decision like do we want that do we just want to codify all of these current differences into the spec and sort of make them final so we have a stable baseline or do we want to actually fully resolve each of these backwards compatibility concerns and yeah I let me let me kind of rephrase my question do we like that we're testing both spec compliance and fun functionality at the same time with the same tests I'm I'm of the mind that we

do um but i' I'd be open to arguments to contrary and it sounds like there aren't any yeah I don't really know okay don't really have much choice we used to have this other test suit the RPC test suit that was specifically for you testing like the I would say let's say It was supposed to be this more relaxed test suit where it wouldn't really check what the individual responses were it was just kind of checking that the normal sort of like flow of using an RPC Library would kind of work like that's

that was the purpose but these tests because they require the click block production uh we will basically disable them so they still exist but I mean since that stuff is all kind of deprecated now we basically think that this test suit is a bit over and we would rather focus on the RPC compa tests and make them a bit more a bit better interesting okay so that's an interesting bit of History I did not know so we tried to do a pure spec only test and then failed to maintain it sufficiently is what it sounds like no it's not that it's more like just

that we had we had this idea basically there should be these two types of test so one is checking the one is checking the outputs of the client against some known output and this is what RPC compat does and I think that is very valuable if we can agree on this output but the agreeing is the hard part I think and the other thing is we kind of we could also have these s sort of like integration test in a way where basically we just use a library such as ether JS and we try to access the API and see if it works like that kind of thing and we can make this work so

that's something that can be done and uh we have done this for the go e client which was also mentioned uh by nethermind so definitely this is what this this old RPC test you was all about Bally just using the go e and check if it works against like the other nodes like not just G and it mostly worked but this test suit with the E client is kind of on its way out I would say because the way this test is set up doesn't really work anymore and we would have to make some extensive changes to update it to the current world where we have the beacon chain and so on and this hasn't really happened yet so basically we would have to launch like an entire little like devet within this test suit to make it work and

that's not that's kind of just like beyond the scope of the time that we have right now for working on this so we would rather just drop this test and it was always a bit brittle anyways but yeah I mean these kinds of integration test would be very valuable also because then we could at least see that for example for a specific version like the latest one of ejs it actually works with the nodes that's a pretty important property but I feel like ultimately if we can agree on the known output of the API it's much better because it just means we know exactly what they will return so it's a much stronger guarantee and just having this weak sort of like it works type of

thing okay thank you these RPC compat test are these um do they match the spec in the execution uh spec rapo I'm not sure if that's the right okay yeah yeah so basically I can maybe also explain a little bit how these tests are created so um the way this works is um the test themselves they are contained within the um execution specs uh execution apis repository so you can see them here uh I will post a link as well um so basically this is where the tests live and um The

Hive Runner tool it just pulls these tests and executes them against the node which it launches and in order to run these tests the client has to import the test chain which is contained in the same directory so there's this genesis. Json file and then the chain. ROP file and um The Hive tool kind of removes the hard part of basically configuring the client with his Genesis file and the appropriate forks and so on because that process diffence between the different execution layer clients so basically that's why we use hi for this because it means we we know that we can initialize all of the clients and um then um basically we just perform these interactions and then we check that the result is correct but then for some of

the tests for example for estimate gas we actually have a little note on there on the test that says the test is spec only um I will post a link to that as well just now so here you go and then for this spec only uh things like if it has this magic comment in there then uh basically we know that this test is not supposed to be matched directly against the client output but it should just be validated according to the specification uh although like I said this part is not implemented in the test Runner so at the like this is kind of a recent addition with this spec only thing like we didn't used to have it but it's kind of added and and I don't think we're imagining a

lot of instances of these right no no no no no this is mostly just for things like estimate gas and possibly for call so the thing about call but I mean it's also kind of boring because honestly with call obviously the result is going to be a hex string but the content of that hex string is very important so I would hope that we can come up with some test cases where we actually see what the output is and I've tried to highlight this a little bit like actually so this is where the tests are stored but the tests are actually kind of um generated by another tool um which at the moment it lives in this repository here I mean this is also all kind of documented so basically here we have this tool and these test

and the test cases there are created um against a test chain and this is generated by this tool called Hive chain and Hive chain it generates basically a chain that contains a bunch of interesting contracts as well where that can be called or that will basically be executed as part of the chain progression and what this means is this test chain will actually contain for example uh multiple transactions of varying types and it contains uh logs and and stuff like that so we can test all kinds of functionality so that's kind of why we have this test chain so we basically have some known outputs compared to we could technically also use like a test net but the advantage with something like hi chain is that the

test chain can be very short like it's only 20 blocks but it contains basically everything we need so that's the thing we don't really want to wait like 10 minutes for the client to import this chain to then be able to make the queries so that's why we have a synthetic chain there but um yeah I mean maybe it would be easier if we used like a test net because we know the clients can import it but at the same time the test Nets usually don't have so much interesting activity in a very short range so yeah that's that's why anyway this is kind of how the test come to pass so technically you guys could all just like import these test in your unit test like you do with for example the execution spec test and uh this would give you much tighter feedback loop than

waiting for Hive or checking Hive or whatever but in practice it's not really required either so like I mean we also don't do it in G basically I just occasionally check um Hive and see like where how we stand and there's currently one issue for G because but it's a test issue so now that's kind of that yeah okay cool I think um because you said like these tests are based on the specification that this means that if other clients do not pass these tests there likely is uh a Divergence in the U well the spec and um yeah they simply do not match match the spec so I think it was already mentioned in on Discord or

somewhere else like it would be really great if you indeed can get all the clients to pass the current test so that means that we indeed have like a base um yeah like yeah a base that we can agree as that to expand like the specification um and also for like this thing like estimate guess I think that yeah would also be cly the only example I would know um where there might be a difference in the output of these clients and that would only yeah no maybe not only be on the yeah like the because the output of estimate guess that's only the yeah the the the guas uh propos

right like okay you should you should use this guess and then uh if but like how the clients come up with this guess like especially for smate gas it's really not something that we can specify because I agree yeah so that's that but for for call for example it's quite interesting like the C so we have some we have this like if you see it like basically ref and might both have this thing where they return like a different output for this one test which I will link now for re here so here here it is and this one is uh kind of interesting because it it makes a call with no uh input and then it will it just kind of sees how the how it is configured and if

you click the link there that's also in the test but I can also show it you can also see the contract that it is calling and in this contract we just return for example the uh different parameters that that are part of the evm chain environment for example we return the block number the chain ID B and so on and then so we can see that for example for reth and nethermind since they can currently execute this test we see that it has a difference with G I guess in the base fee or something like basically there's a zero there where in gu there's no zero or something so this is a difference where I would say would be interesting if we can agree on this because obviously people would want to rely on these proper in their client libraries at the moment it's really not

safe to rely on these defaults even though the fields are optional in E call if you don't specify them you're going to have a hard time because it means you will basically get like an arbitrary result yeah because like if course you definitely be deterministic but I see that it's being called with latest and that might might be the problem that it might be called like a different block no that's not the case because in this test the the the chain is known and it does not move so basically we expect that like when the test is launched the client is exactly located at block 20 of this test chain and it's the same it's a known chain so this is not the the difference the difference is one in the

client configuration somehow like it somehow has uses a different setup basically for this call right okay yeah but yeah that that's that this should definitely be um yeah the client should agree because this should very be deterministic so this is well I would say somewhat alarming actively yeah and then the other case that I'm trying to highlight is actually kind of interesting is for example this is something that came up very recently and I've even tried to bring it up in in in ACD so there is this situation where um one thing that one area that um users have very often asked us about is this

thing when you perform the E call and the execution will uh revert and then in that case it's the interesting question what will happen uh like what will be the response and um in in E call like typically the idea is that if the call fails it will return an error like a Json RPC error but then what what is contained in that error can be quite important for example a lot of people want to see the actual raw revert data so that they can parse it on the clients side and um yeah this is something where basically um the um it's we don't all agree like

how to actually do this so for example if I post this test here you can kind of see it as well uh so for nethermind here for example nethermind returns um you can see it with like the lines which have the minus in front of them they are what NE return ones that have a plus are what uh the test expects and notably the test does not compare the error message so the error message is excluded because we will never agree on the message but it does compare the error code and the error data field and you can see that interestingly so for example nether mind it returns in in a different error code than G in this case and it also returns these sort of like

decoded uh uh ABI error so it has already determined that this ER error is a um solidity error of type user error and it does not actually give access to the raw bytes and um yeah the same is true of the uh next test so this is something uh which is I think these types of differences are very hard to resolve because we would have to like agree on the error code and the data and so on and we haven't really been able to do so successfully like even though I tried to bring it up in ACD and and so on we never really fully managed to yeah like get to a result where we're like yeah this is how we're gonna do

this yeah yeah I see I just a small note I also think that um like the importance of this is like underestimated because these RPC calls are not part of our consensus so if you implement something differently like the chain is not going to fork or to Hal or whatever so I think uh yeah this is um felt to be like less important but yeah I mean as you say it here I think it is actually rather important because it would not make sense or it would actually be pretty dangerous if like one client reports this uh on the RPC call and another client reports something else so I think it is indeed very important to standardize this and to to to Really make work of this yeah I I

would agree with that I in fact I would propose I'm starting to collect agenda items for subsequent meetings eror error handling is likely an entire discussion point would you guys agree we should we should spend some time in future meetings defining it and incorpor incorporating and designing ways to formalize it I guess is what I'm trying to say yeah makes sense yeah I agree and I yeah I think like a very good starting point will to D okay let's really get all these clients on the well yeah let's get them running these RPC

compat tests and then inde find those differences because like also on things like like we have like this very simple chain um and yeah just thinking about it I think just a simple chain and then running on some some calls on it I think that in should cover most of it but maybe there are also like some very weird edge cases with like parameters um for instance like like the depending parameter for instance for an RPC call is also something which I think clients will disagree on um so yeah that that would be a very good starting point to see where do clients diverge um and use also that to yeah to to really start standardizing yeah these

RC specification yeah cool uh does anybody have anything else they so I would like to reserve sometime and we don't have to get to this right now but I would like to talk about where we see this meeting going and when to start including external stakeholders I think that was a subject that came up a bit in the R&D where we think about you know the customers for these rpcs uh RPC providers right um wallet devs daps l2s um all of those so I I would like to earmark maybe the last 10 minutes if possible of this meeting to

discuss when we want to get them involved um but does anybody have anything else they want to cover before that yeah um I would like to add that I think this meeting would be good for also discussing uh future changes and and new features I mean we have on the spec repo a bunch of issues ues that regard to uh changes not not just like for consistency purposes but also for uh for users like new features uh they are different in scope

some are about adding a new Fields uh some are about adding new methods I think uh this group would be well suited to discuss things like this just wanted to bring it up since um it was not mentioned a lot since the beginning of the call yeah I I definitely think this is good that's going to happen um I think once we set the table and have our kind of processes and things in place this would definitely be the place for that um I think along those lines one of the things that we talked about is like okay well what's the process who gets decid

on the on the extensions how are we going to take these things back to all core devs uh Etc and I think that's kind of why we wanted to have the first meeting just the just core devs and and not really extending it to those people who are going to care about the features right um so I guess I'm yes anding and and just saying we need I think we need a little bit of time to get our feet under us before we start um pulling in new features but but I I fully expect that this would happen here anybody disagree with that all right anyone

else well I mean we could talk a bit about the spec itself I mean that's kind of the other thing so we have um the specification right now like I mentioned in my document it's basically defined as like this group of yamama files and um I think the spec itself is okay right now for what it is but actually accessing the specification is very hard like if you really wanted to access it like as a user or something you'd have a hard time because it's not very readable so it's more like a data file I would say and um I mean this is it's good to

have a specification at all but I think specification has to be readable at least a little bit and um it also the thing is that technically the spec is complete but practice it uses the Json schema to define the um outputs and what I found is that Jason schema is kind of okay for writing down how it should be but when it comes to actually seeing like a validation error is really hard to use because the errors that the outputs are horrifying basically so you if you for example if you forget like the worst case is actually if you try to we've hit this a

couple times from making tests like you when you specify uh a transaction result from get transaction by hash for example but you forget a field or you have it a the a wrong one it will output I don't know like a 100 lines of of error and you won't really get like what you did wrong for example so I think the Tooling in the spec is super bad right now and uh this is mostly because well it's using the open RPC tooling which I mean it works but it's not great so this would be another big item it's just like how do we actually figure out something that works for us so at the moment like I was said there

is this viewer app one second one second Felix so what you're what you're describing is a gap in are is it specific to error reporting cases that we have bad tooling for do you see other areas where this is happening and go ahead well I mostly just mean the spe it's just not in the greatest shape that's what I mean I mean obviously it's it's it's kind of okay but there just isn't really anything better right now for yeah like that's thing so yeah and and I appreciate what you're saying like there's a lack of narrative there's a lack of like written documentation and

explanation like you know here here's why you would use this method here's an example etc etc it almost seems that the specs right now are almost too machine generated um yeah I mean it is handwritten but it is kind of the the thing that the the the spec is is not the documentation and we have this viewer app where you can technically access it and uh I mean you guys have probably seen it I mean it's here so but you can if you actually drill down and you try to use this just to see then you'll quickly find that as a developer for example this can be very frustrating because this app is just yeah well it's just not very good that's the thing basically it's just an

a tool that allows you to see the schema but the way this is executed is questionable I would say like you have to click basically you have to click all the time to figure out the information and then the actual information is I mean there's a lot there but it's just also very dense basically it will tell you for any field ultimately what is the regular expression that should match this field and that's nice but it's not really the most important information for someone like if they someone wanted to figure out for example like what does this field mean probably they don't want to know what's the regular expression they want to know like what's the purpose of it or when is this returned or what could be a value here or you know like

why would I need this and none of that is present it's just very technical we do have some examples and we do also have this interactive inspector thing with that would allow that allows you to make queries against an endpoint so that's all very nice but it's just like improving this thing would be awesome like if someone can figure how to improve this app or make a new one or whatever like that would be great like this app is yeah this feels like solved problems somewhere right like anybody using open Json RPC or what is it called open RPC um would have this need and well I mean what you have to understand is that open RPC has kind of come together because of

this API maybe something you might not know but like I mean ethereum classic created open RPC to Define this API so it's literally this is what it was built for yeah good point yeah well thank you for leading that elephant into the [Music] room yeah I know it's not so great I mean there's no easy answers that's kind of why I propos this it's kind of it's just I mean we we cannot make like a lot of progress very quickly I just mean we it would be cool if we made some progress at least so it can kind of start with like making some more test pass figuring out like what tests to add stuff like that I mean as far as I

understand the RPC compatibility will always be like work in progress we will basically never really reach a state where everything is perfect and that's fine but I do think we should like improve it a little bit so that's kind of where I am because even if we make updates today when it comes to external stakeholders they will have to either replicate these or figure out uh if it Mak sense and there's also too many people to really agree on on all the changes that's the other thing like there will always be some level of backwards compatibility left in this API M it sounds like an argument for deferring external stakeholder

involvement for a little bit further yeah well I mean at least until we've kind of figured out like what we want to where we want to go with this yeah good enough okay well then I don't need that last 10 minutes it sounds like that's a bigger question than we should open up today so um you have anything else you'd like to cover Felix or anybody else well I would have a question maybe so um I'm a bit curious about things such as e send transaction so um it's it

may be an interesting thing but e send transaction is easily the most interesting method U we do not have tests for it and uh the reason why that is is because send transaction itself would require like in order for it to work it requires the node to sign a transaction and um I mean we have support for it in gu but we have always wanted to remove that however we have not done so because we know it's also a heavily used method in some use cases and notably the wallets also implemented so e s transaction may still be one of the major entry points into a wallet so then the question is kind of like which nodes actually do support it I guess bisu and

Ne mind support each send transaction in some way but I would be curious about your experiences with that or if you are also planning to remove it at some point oh no we don't want to remove it no in fact you know that's one of again L2 is really going to care about that one right like we're actually building more methods that are like eend e um sorry send transaction like we're building bundle methods that work on bundles of of transactions now those are all pre-signed um but yeah we're not that's not going anywhere from our perspective so this yeah with a pre-sign is something else that's something that could be added but

the value one of the values in each s transaction was also that it kind of comes up with these values for you so for example if you don't specify the nons in a transaction then it will be assigned by the node that's kind of the original purpose of East 10 transaction anyways and I was more curious about this kind of stuff I that's a good question I should probably take that back to the team frankly because you're you're pointing at the past where the node was also kind of the wallet right where like people were really setting up their nodes because they were going to use them to generate keys and sign transactions and all that kind of stuff um I kind of want to remove that part that's the thing and yeah it's not really clear so I mean there was this

idea with the profiles in my document where I was saying that like some things are make more sense in one context and less in another context for example if you're a wallet then you have to implement this but if you're the node then you don't have to implement this but then it's kind of the question like which other bits of functionality are sort of this like wallet space and at the moment in G it's a bit weird like we never really know like what we should support and what not so we don't really support much Beyond I mean we have estimate guas obviously but then there's also things like e create access list that we uh so and fill transaction is another good example I'm not actually sure did we ever M that to spec failed transaction F fi transaction I don't

no no so this was kind of maybe I can highlight this so this this fil so e fi transaction was like our attempt at sort of um replacing I mean get suppos this method and has for a long time and so the idea with e fill transaction is that it would basically give you the default setting ability of e send transaction without actually sending the transaction so basically it would be a way for you to Leverage The nodes State knowledge to fill out a a transaction that you want to send but you wouldn't actually have to then um send it so basically if you don't know the nons of an account and

you don't know uh the base fee and things like that you could basically do e fill transaction and just say I want to send uh two e from this address to this address and then the no will return you all of the parameters that you would have to set in order to make this transaction and then you could send it to send raw transaction if you wanted to yeah well you have to sign it first but that's on then so that that was our idea basically this is one part of like our attempt to figure out this whole future Beyond eend transaction it is kind of a useful feature but um I have no idea I mean we I think there's an open pull request to add it to the specification as well but we haven't I mean Cena says

you we haven't added it so I trust them anyway it's one of these things that basically we think is is very important because this stuff oh yeah F transaction is not there so it's mostly because uh well like I said so e send transaction is a very important one and we do think that like some of it is super useful but then like other things are less less useful like for example the signing and so on so yeah okay there there's maybe one point which I want to bring up um what we might want to actually do is to want um to keep the um the base G specification like uh as low as

possible so for instance like I'm thinking about this field transaction thing like this should technically not be necessary because you can also things like okay if get balance get transaction count to figure out the um the vales which you should use um and yeah yeah I think my main point is um that we should likely keep this specification as simple as possible um and then let like the yeah the well let's say the end users like the wallets just quer the methods which they want to use and then use that to do whatever

they want instead of yeah filling these these things in like this this field transaction idea yeah okay uh FL LC I have no idea what's your name but you also have your hand raised yeah yeah you can call me f uh so uh I just wanted to mention that this method seems very useful uh to generate blob CES and stuff probably uh we would try to add t one in other might at some point I mean field transactions uh but I raise the hand because I wanted to mention that it would be cool to uh to

iterate through spe through transaction uh format specification which Fields uh are required uh formally for different types of transactions because uh if we do not post for example access for uh blob or uh 1559 transaction uh it will be okay but this field is marked as required uh in some specification internals as far as I remember uh additionally this TX type field should be excluded or agreed to be uh like respected by all the implementations like that because

this is the most complicated object and it seems like it's not specified fully at least for me so can I quickly ask are you talking about e send transaction when you say with the type uh or is it more about call estimate gas methods uh reive this object to right and uh ah okay so it's about estimate gas and it's about uh um that's actually good point so okay so estimate gas and send transaction they they seem to require the TX type I mean that shouldn't be the

case um yeah yeah yeah yeah yeah I I get it I mean this is something we can look into yeah in this spec that's that's that's good uh yeah we have like a common objects right for transaction for method is it the same for estimate guess and send transaction maybe the same uh I'm checking it right now I think it's the same so we have in Fe Market we have e no no no no wait wait wait wait yeah okay yeah so estimate guess

and eth call actually have the same so this is maybe also something that is hard to it's not really maybe I mean it is captured a little bit by the spec but it's probably the same in all the implementations so the input object for E call and E estimate gas is the same one so that's that um and also for send transaction so it's basically this like transaction input object I would maybe call it but it's not called that in the spec and the spec it's called a generic transaction and as far as I can see the type is not a required field there so it has no the generic transaction does not have any required fields in this spec uh okay I will find the place where

I saw that maybe it's not visible on UI on that UI you provided recently but uh no it's more like um I'm checking the source so yeah I was checking this thing I posted the link here so it doesn't Mark these things as required no you mean generic one yeah generic transaction yes and as far as I understand that is where that is where yeah this is the input object so in it in this spec it's not required or maybe it just requires all the fields

by default I have to check this so I mean this is something I will I will ver I will verify this maybe there's a maybe there's a problem with the maybe there's um transaction types for specific transaction types there are lists of required Fields but not for this one mhm yeah that's true but the uh the that's that's kind of what I mean so the um the transaction schema is kind of split so we have transaction inputs which are for E call E estimate gas and E send transaction but send transaction I'm not sure if that I think that's in his spec but yeah so basically um this input object is a generic transaction and then we have the

transaction outputs as well and there we have the the spec is a lot more complicated so the spec uses a different object for each transaction type with different fields and this has actually been a source of confusion in the past because at least in our implementation we don't handle it this way we only have one transaction object and that generates the output for all of the types and in the spec is different so there will sometimes be these differences in the test because of this but um yeah in in the output objects for transaction types certain fields are required that's true but I think that's fine also because these fields are actually returned by the node as well and what should be defaults for these fields when we do not pass access

list or gas price or anything like Val you in transaction yeah so what should be the defaults so that is kind of a good question that's what I meant earlier so should we maybe agree on that so that's the thing at the moment we in gu it's kind of a complex area so for example we will basically try to guess the transaction type based on the presence of certain things so for example if you send a transaction like a value transfer and then you will um include an access list it will create an access list transaction for you but if you uh include the 1559 parameters it will become a uh 1559 transaction and so on if you put blobs it will become blob

transaction so it's kind of like this it's something that the node then has to do some guess workk to figure this out yeah we're now doing the same yeah depending so this is kind of what I meant it's super it's super complic at because in the end this logic isn't really tested anywhere there are no compatibility test for S transaction because it requires accounts in node but at the same time it's one of the most complex areas of the spec so this is kind of annoying situation like if we had fill transaction in Spec we could add tests for all of these cases but we cannot really do it right now so that's an excellent segue we got four minutes left I want to propose something maybe stupid maybe kind of Awesome

if send transaction needs a little bit of work and Phil transaction could potentially provide new mechanisms for us to work with it with less you know Cru would that be a good first candidate for us to kind of do a vertical Spike on refactoring that getting together next meeting and saying all right what does it take to to bring Phil transaction into the execution spec and deprecate send transaction as kind of an experiment for us to figure out our process to refactor and improve upon the execution spec yeah well it works for me but we already have it

so I'm not I'm not really talking about implementation details right like that's kind of not the interesting bit for us to be testing out here like I actually very interested in how do we document this how do we deprecate it how do we communicate it out how do we specify it in the spec all that kind of stuff when I say vertical slice I'm saying a part of the process that touches on all the different layers of getting the work done so that we can look at it and say great next time we need to do this here is a loose process for doing that does that make sense

yeah yeah I guess it would be kind of similar to how we did it before so basically we have to figure out the specification of it um that's already where the problems can start I mean we would have to yeah I mean definitely I kind of I want this for sure like I'm totally on board let's try it awesome but yeah it's difficult okay so I'll take that as an action it for our next meeting um I'll post these notes somewhere maybe I'll talk to pu about the best place to post that um um yeah and then we can continue the discussion async uh on on um on how to how to work through

it I would also propose to set up like a next meeting sure um is this a popular time window for folks and just want to reuse this moving forward in a recurring fashion or I mean we' got pretty good sence it works for me what's that yeah this this works for me okay good great well that's not broke so we won't fix it I will get it on the calendar and that is our time thanks everybody it's great to see so many people

interested in our PC stuff how does two weeks sound two weeks one week for the next one um I guess two yeah two weeks is fine awesome awesome great see you on Discord and in two weeks thank you right great call thank you by