RPC Standards #0

Transcript

hiy everybody Welcome to RPC working group call zero I have posted the agenda in Discord I will repost it here in the local chat for folks to take a look at um does anyone have any last minute addendums to the agenda they'd like to get on the list before we get started okay all right sounds good um so taking it from the top here hi everybody happy m uh does anybody have anything interesting to report on their client passing of the RPC compatibility test Suite um for instance Basu has been

looking into getting this running correctly we found that right off the rip we're not starting up because we have older um system contract addresses in our uh uh I forget exactly where where that's conf in the test uh workflow uh but that's our problem at the moment so uh we're going to be fixing that does anybody else have anything I think the ask is you know are you passing these RPC compat tests are you looking at whether or not you're passing the RPC compat tests are they useful etc etc because moving forward with these discussions in this initiative I think that's probably going to be our um you know the our most important indicator of compliance

yeah I mean I think G filled most of these tests so by proxy we end up passing a lot of them I'm interested to see as more clients come online and really look at the tests there is going to be some deviations and it doesn't always mean that the clients response is incorrect I think RPC Capa is very strict because it would be nice to live in a world where you can swap your clients in and out and you don't really notice that there's a difference between the clients and that was kind of like this vision for being very strict about the compatibility across clients um so like everything down to like the exact number of fields the

exact ordering of fields and the RPC requests are verified this is not like necessarily Jason spec um because Jason doesn't care about the ordering in an object and like we can look at yeah we can look at reducing the strictness of these checks if it ends up making sense yeah so for us we're passing pretty much all of them I think there's one issue on the access list that we've made a change that's caused the order to change in the output and yeah we can fix that yeah actually I looked into this so there's some non-determinism in the response and this is kind of what causes it to break because we in on some runs we also generated them in the opposite order

basically because of the hashtable iteration order which is random and go I think this is going to be very relevant when we get on to our next subject for um error codes I think that's what light client is hitting on as one of the cruxes of of our of our problem um so thanks for that light client anybody else yeah there's one thing I noticed uh like in the exess list in the order matter y you're super super low I can't hear you bud oh okay well well second oh that's a little better is this better yeah yeah okay great U like indeed in the exess

list test uh the order indeed matters in the test because if you swap two items around then the test fails but I was wondering is this actually part of the official spec like I don't remember that the ex should be ordered like storage slot should be ordered I mean it's not a part of the spec but obviously for us it's kind of like the testing framework it can only approximate uh the correctness in a way and for us we think it's a trade-off that basically we can all just agree to order them by the address and the output and then it will be possible to test it in our approach but we cannot make custom test verification for

every uh method or at least that's not really wanted yes that's true but I'm talking about the storage keys in this uh uh this case and that is actually an array yeah I know what you mean so basically okay the the way the test work is they just compare literally to the output and so there is now I've added a tiny modification there where specifically for numbers you can have them like with or without the decimal point but I think in general the idea is that we want to agree on the outputs even if it means having to for example sort it in the clients or something and um it's definitely

possible to come up with the correct output there otherwise if if we didn't have it then in the test we would have to basically I don't know sort the results inside of the test and then compare or something but it would be like a custom logic that only applies to this method yeah I see I see yeah but in general I would agree that we should make like these outputs like very sck so indeed if you agree like just make these storage Keys increasing or something like that that will be good yeah cool all right thank you uh anybody else want to comment on what their client's current status is

with regard to the RPC compatibility test I know we got some folks joining us a little bit late that is the current topic of discussion okay cool all right shall we move on to error codes I think I think so to elaborate a little bit more on um what like client was saying earlier today um I dug into error codes they're not they're not specified for starters uh um and when they're enforced for instance if you take a look at you know an eth call test that's in the um execution API test in the RPC compat sorry in the RPC compat

tests if you look at Neath call uh it fails it asserts on the error code and the error message for instance right um so that well correct me if I'm wrong um I see the error message is in uh the expected response whether or not the error message is excluded from the comparison thank you Felix yeah that's exactly what I was hoping for um so then the the issue that kind of remains there it's like all right great um if we're going to enforce error code compliance with the existing tests and it sounds like we are we just need to add more tests that cover those error code cases but we also need to document what those codes are what they mean and include a

yaml schema for them so they're actually presented in the rpcs right now if you if you open up at an RPC in the documentation and look at its request and response it's always a happy path um so who has thoughts on you know a general error handling section for the spec where should it be do we need to build an error yaml schema for inclusion um what are people's thoughts on that Felix so um the test that I want to clarify so there is only one error code assertion in the test and it's for this specific case so we don't have a general mechanism for error codes it's only for this and I added this specific error

code because it's basically one of the very few cases where we actually need it so for example we don't really care if the server raises like one error code or another error code for example for the invalid parameters it's just I mean technically we could Define it but I mean it's the these are also kind of covered by the Json RPC standard but for the E we have the specific case where the contract reverted and it's not actually the the the users they want to have a feedback in this case in order to for example be able to parse uh the revert reason and this is why I propos quite a while ago to um add this error

code three uh to cover this and um it's actually also um something that I brought up on the all C devs before but then basically we just deferred the decision because we didn't have enough decision power that day or whatever to figure it out but this is pretty much like in for example in metamask it also returns this error code and so on so this and it's in some of the client libraries and so I think it's pretty obvious that if we can agree on this one error code it's a good start and then there's an open po request for adding it into the spec as well so I just added the test sort of like proactively I guess because it's the default behavior and at least in gu to

return this error code for this specific case Okay so does anybody have thoughts about you know kind of not formalizing error codes via yaml scheal in the spec and leaving it up to individual tests I think um maybe the first thing we should do is really um well make the spec because the spec is I think not complete like in last call we also mentioned like things um like for instance for the block like I think never mind has the all for field and uh

the spec as a minor field or a coinbase field I I don't remember but maybe that's a that's actually a a first start before we can actually discuss expanding the tests uh sorry the spec okay any other opinions thoughts on the matter I'm not quite hearing a hard decision on error handling yet so I do think that in general yes you're right we should add it to the spec but it's not really we don't actually have a lot of defined error cases that's what I mentioned before so there's only like a handful probably that we can come up with that makes

sense to even specify because most things are actually covered by the Json RPC spec itself so for example if you if you call an invalid method then there's a standardized error code for it and we're not going to test that in the RPC compat we could but it's not really something that we that is in the realm of that so it's only about these like ethereum specific error cases and there really aren't a lot okay so maybe we don't need a general error handling section of the spec sounds like that's kind of what we're advocating but we do need the capacity to optionally more strictly specify errors within each RPC call yeah so it's possible with open RPC so it's definitely something you can add this

like it has a facility for adding these error codes and I did it for this one case for each call with a revert and um then like in my Pro request I'm basically trying to let me just try to uh find it it's something that was basically added but um wait yeah so it's in here so this thing I I pasted it into the chat thank you Felix you can see it yeah go so there is the there is the thing that you can Define error codes

and you can find the error data and I think the handling of error data is like the thing that is also interesting in for the for the error handling because um for this case where we want to capture the evm revert um the goal here is basically to Define it in the spec that the client is supposed to return the raw evm output uh uh which like the the evm uh revert data because at the moment like the specifically for E call the definition of e call from the beginning was just that you do call and you get back a hex string that is the return data of the VM but um for revert you actually don't need because it's an

error in the Json RPC you don't get a result like in Json opbc you can either get a return value or you can get an error but in this error we also need to give kind of the return data because it's the it's actually not the return data it's like the revert error data from the evm and we need this because on the client side you want to be able to then parse it according to for example the contract ABI to figure out which event is it and so on and the client ethereum client it doesn't actually know usually um the uh the contract ABI which is being called but the the I mean the the the ethereum node that's running eth

call doesn't really know the ABI but on the RPC client side they will know the contract ABI that they interacting with so they are in the position to decode it and that's why we need to add this raw data into the output okay okay cool this is this is awesome okay so uh let's all take a look at the pr that he posted and I think that's a great um you know first pass I think I shouldn't say first pass but I think that's a good approach that we all seem to be happy with uh for air handling should we um Felix you said before there's maybe like a handful of other places where we actually do care about the error code like this

um perhaps we should collect those open an issue here and once this PR is approved and merged in cite it as our way for implementing the other ones yeah there were a couple people who raised their hand so I don't want to interrupt anyone okay you're Kon go ahead um wello so uh not sure if this related but uh I've been trying to uh standardize our nether mind clients uh juston RPC errors uh error messages to uh to adjust it to

guess error messages and uh I um I noticed that guess has some weird weird error messages uh I send it to chat so uh for example for uh call and eth simulate V1 uh it has some um format of uh applying some suffix and prefix like air and uh gas uh supplied gas and for for example for eth uh estimate gas it has different but the meaning is similar so uh can uh guess do uh uh remove this uh formatting at all or I don't know uh

to uh make it one format uh I haven't checked all the uh other um apis uh so uh maybe there are more uh some other formats of formatting errors and also these errors are only for transaction uh errors uh the errors from uh VM uh they are not formatted uh like uh revert for example that we were discussing before so this very interesting question but why I mean first of all why should you standardize I mean I agree that maybe our error text could be could be better but why should the error text be

standardized for example like I don't really fully understand it is it required or is there I mean we shouldn't there should never be a need to standardize the error text uh because I uh so I've been working on um uh testing tools like uh execution spec tests and one more uh I don't remember the name but uh there are lots of uh multiple uh clients uh like uh yeah multiple clients uh that uh gives T tool that uh generates error

so uh they they all have different error error messages and uh I was collecting all of them and uh like writing and I thought it might be nice to have standard uh errors for uh each case and yeah that's it yeah so I I definitely agree that like the errors could be better but we don't really want to yeah I mean this is kind of part of the problem like what what F also mentioned there in the chat this is like a this is like a huge issue we don't really want to be like the gold standard for error messages especially

in G and this is also why I removed for the RPC compat test where I remove the error messages from the comparison because there's no expectancy that the error message should contain like any information if there's some machine readable information it should be contained in error data and for the um for E simulate V1 it's actually very very completely specified so I think including some error codes so simulate V1 is probably the best specified e uh RPC endpoint we ever had because it even had its own spec process and so on and its own series of calls so I think it might make sense to like if

there's any need to look at these error Mes in simulate V1 it seems kind of weird to me like because we could just change it it's so well defined already Merck you had your hand up you still have uh something you want to comment on not really because I think Felix covered what I wanted to say so we should adjust in my opinion we should adjust and standardize error codes but not necessarily error messages and we should whenever we see such situation when some Library uses uh error message we should ask to support error codes because we have we had many situation

probably many minority clients as well that um someone reached out to us that hey uh you returned something different than what we expected and it it broke our library or whatever right uh so I I think this is known story for for Basil for Aron and and um other minority clients no all right so I'm going to take an action item to uh let's aggregate what what the blast radius of that is like what are these tools in libraries that we think might actually be looking at error messages and um start start the communication process out to those teams uh in order to focus on error codes and not messages

yeah so um just quick addition I think um from this if call and if estimate gas are the most common uh points of complaint in ter of error messages but probably something obvious yeah e estimate gas and what was the other one if call right and by extension it will hit us with e simulate right yeah so I think e simulate is kind of I think it actually does have some defined error conditions but like for for example for for estimate gas or for um send transaction things like that they

actually have some error conditions the other things not so much they because the only real condition could be something like like it in the uh in most of the rpcs they are just uh basically database accesses and in all database accesses we have this convention in the API to return null if the item is not found and this is so it's not an error actually like if you try to access for example a block uh which is uh which doesn't exist then you will get the null response this is like another area where in the future we could actually extend it but in for example in some cases it's kind of useful to be able to return an

error uh but in General as when the client returns a non-error response it is pretty sure that for example the block that was requested doesn't exist or something and if there's actually like an error in accessing the database for example a dis error or something then it will return an error response instead of null so these are the most important cases and we do have tests covering this like not found case with returning null but then for E call and so on because they are more interactive and also estimate gas they have maybe some more error conditions for example if you try to send a transaction type that is not supported for example that could be an error condition that we Define or um if like for E call yeah well I mean if you run out of gas for

example then at the moment it just tells you that it was out of gas but there's actually no error code for that and then so that that's something that we could add and then for um for sending transactions there are some cases like for example if the fees are not uh do not cover what's required by the node then we could probably also Define error codes for that like if you try to submit a transaction but it's too cheap for the node and you would have to submit it with a higher fee at the moment you will get a text error and then this is a case where we would again need an error code for the client in to know that this it failed because of the fees and they at

the moment they can only get this from the um from the text okay trying to think of how to collect that into an action item it seems like we need to open an issue to outline which RPC calls H how how would you phrase that Felix what do you mean the action well we need to make a list of the like error situations I guess yeah and I mean I listed some now but definitely this is something that we wanted for a long time just to have this

basically like this basic list it doesn't have to be complete even it's just something that at the moment is literally like completely undefined client just returns like a generic error and some text like for all of these cases okay my understanding there is an error m uh here can correct me if I'm wrong because you explor that in t8n tool and this sounds like a good starting point to check the list of error messages and how different clients map to different responses so I think T1 tried to handle it somehow and maybe from this we can

from taking a look at those moppers uh we can try to discuss what should be the correct response message here can um also the benefit of having all one error uh for uh all the cases that uh for example in state tests and blockchain tests that are generated by uh execution spec tests uh there is a field uh in the post state that uh expect expect exception and this exception te text is uh in the format of uh python project uh that is not uh in format of any other client and for now I

checked in our client that we do not check uh for uh exception message like uh we don't check this field and uh we only check for the state rout uh much and I believe that all the other clients does not check the this uh this field uh expect that uh exception so uh in the future if we uh have the same uh same errors for all the clients then uh we can regenerate all the test casys and it will be uh checking uh the tests more strictly because uh transaction might be rejected uh by different cases but it will not be checked uh for now like uh

yes so I think I think to Felix's point though you know I think error codes plus the data leads us to a sub error code that maybe we would want to formalize um does does that give you the the Precision YY that you're you're looking for um because we kind of want to avoid asserting on the the message itself because it could be free text and in the case of like kind of generic errors you know you might have to describe a situation that um is unique to your client right um so I think we you know I think we're starting to want to avoid asserting on messages in any case um but Felix did I did I paraphrase that correctly yeah

well I mean in I kind of wanted to respond also so I mean with this t8n stuff it's like it's not really something that I think can be uh specified uh I don't know it's not really super related to the um to [Music] the one second one second one second yeah so the the t8n cases they are not really um related too much to the apis because in the API we actually don't have a lot of these situations like e call for example is

not the same as adding a transaction in a block or something so it's hard to say if these error cases will truly be the matching ones I do think that it's I don't know it's useful to be able to Define uh these error conditions also for t8n but we have also seen maybe as a count example we have seen it in the engine API test that like being too strict about how all of the errors should be handled just leads to this like hellish situation where we have to basically match the behavior of the spec like to the letter in the client and it's very very annoying to do for very little benefit so for example in the engine API which is sort of the poster child of RPC specification because

everything is specified in the engine API every little error situation has its own assigned error code and you have to absolutely follow them and it has a kind of complex error handling model and we have seen it before that it can it's basically very annoying to implement this correctly and for example G also still failing obscure tests with withdrawals for example because we're not performing all the checks exactly in the correct order and so on and I wouldn't really want to have that in the in the user apis like this situation where you have to make sure you absolutely check everything the same way everyone else does it as well it's more like we should be agreeing on some common cases and Define codes for them but not try to be maximally prescriptive

about every error situation because then that leaves no freedom for the implementation at all love it thank you okay does anybody have anything else they'd like to discuss with regard to error codes or air handling all right I got a bonanza to-do list items in uh in my notes for this so I will collect that and ship it out later who's ready to move on to data fields awesome I knew you would be all right so um I think this is a kind of

similar situation right where we're we're looking to collect misalignments across clients um likely via test I would imagine these would arise via test failures or maybe caveats and tests um is is why parody the most glaring example of this um where we rename V to Y parity but then we also accept V in in some cases but not others um how would folks go about collecting the list of data fields that are under specified via test fail we can just look

at the test I think right now so there there's this thing there's a limited like three or four different things there and that's kind of it so we have this y par thing that is mostly fixed I think and we have these like what was mentioned before with nethermind with the block author and we have some other stuff like for example in W they added this proposal for this I think it's called this like log index in block or whatever it was the like a it's an additional field that they return for logs and so these are basically the case I think in I'm not actually sure about aricon because the test don't work but probably like knowing Aragon they also have something like this and it's I think it's just like this handful of

cases and we have to make a decision should we like drop these things again like from the clients or should we and this was my original proposal in the document just enshrine the current behavior and just Define it as canonical whatever it is like if we can't agree on uh removing some stuff because of backwards compatibility issues we could also just uh basically make everyone Implement whatever is the current set of fields because I think it's more important to agree on the fields than it is to uh try and be uh sort of like minimal like we we really just want to reach a state where

the specification and the clients agree so I have a very very very weak preference um and it's purely aesthetic for going back and standardizing things um but I honestly don't see a ton of benefit in that and I think it's just as good as just enshrining past behavior and then trying to correct it moving forward like if it's a historical wart on the on the um specs I kind of don't care but you know it's a wart does anyone else have an opinion or is

it kind of just we don't care make it go away yeah I mean we still have to agree on these specific cases then so we should maybe talk about them so we have this author field I saw it earlier here in the chat that uh I think M mentioned that that they are NE mind is considering to remove author in block and in favor of basically just returning minor which is the name that is in the specification as well so that one thing um give me some time and us some time and we will come back to that I think it's likely that

this field is not used anymore uh but you know we need to confirm it okay so I will just check the test right now and see what else is there oh damn it yeah I can't actually with B so it's still not I think maybe in the de5 now it's hurting me big time that I that I uh added the added the prog test into it because I can't really check like for most of the clients yeah okay so bisu doesn't really want to load the chain in the

test so I can't really check for it but for NE mind I can see that well mostly we have ah yeah so there's also this thing with the gas price so this is something else so when in um this is I think just a box so basically in nethermind it appears that it's not returning the gas price for blob transactions like the effective gas price is not returned the V is not returned because it's Legacy I guess and

then for legacy transaction it doesn't return a chain ID and I think this is just an artifact of the implementation so in G the way we do it is basically we have a single kind of output routine for transactions and then the way it works when we when we uh perform a transaction related operation we will basically parse the transaction into this kind of like output format and this means the output format is the same for all transactions except for some stuff for example if the for blob transactions we return some additional Fields because they are you know they have the blobs and so on but the basic fields are the same for all transactions and I think in

nethermind obviously checking the test it's very different it has a custom output routine for every single transaction type and this means it it can lead to the situation where for one transaction type the fields are different from another one and it kind of mirrors a bit how it's done in the spec but honestly I think the way the spec is written right now is very annoying like the way it does it is it defines in the in the open RPC we have an output object for each transaction type and it's basically a union so the the the the out puts for each transaction type could be very very different if we wanted to like if we added the new transaction type five right now it could have like basically completely different fields from the other transactions but I think this is

is not really a very intuitive way to do things because most transactions actually have like basically all transactions have an effective gas price because that's how they are executed by the ethereum uh evm and um so obviously you do want that gas price in the output and it's kind of the same with some of the other things so it's hard to say like what's a better approach but I I think that for example specifically for nethermind it has this issue that basically because of the way it's implemented some of the transactions return different info from other ones do you know if this is uh NE mind only or um like other clients might uh

respond I mean I just said NE mind because these are the tests that I have open right now okay okay I can check uh oh actually I see that Aragon no oh wow Aron actually managed to run it someone actually fixed the Aragon test chain loader so we can actually check it it has very few differences I see yeah okay so it actually has mostly yeah okay that makes sense so Aragon has no differences as far as I can see yeah so Aragon is completely aligned with the RPC test except for some special cases when it comes to invalid

input and so on and then maybe WTH we can also check yeah reth has quite a few differences so they have in the transactions they have o interesting they um okay so I think re at the moment is a bit broken like looking at the looking at the test results in Dev Net 5 it's kind of broken but looking outside of the devet 5 I think they we can see that yeah I mean basically they the only thing is they have they don't actually have this transaction issue so for re they agree

with the transaction output format in the test so for them it's only about to receipt and for nether mind it has let me check if it has some differences in the received so this is curious Felix how did you so quickly um determine that Aragon is the closest align to the spec and can other clients use that process so I I the way I did that is literally I went to the devet 5 uh Hive instance yeah yeah and then just open the the this the test suit the latest one with with Aragon so I posted the link and then I see that it only fails a couple tests basically and I know these tests like

like what they are like I know the intention behind the test so I know that for example if it says this like not found then it's supposed to like for example here you can see in this if you click my link you can see that there's this failing test e get Block receipts get Block receipts not found and I can see that for example in Aragon for some reason they implemented e get Block receipts differently from all the other clients because they return null for not found but they return an error and that's incorrect like they're supposed to return null okay so there's no easy category of error there's no easy category of error that we could use to help teams triage these cases no that's that's it's kind

of on them but I do think that Aragon seeing it now that basically they are able to actually run the test they weren't really able they had like basically everything failing before because it just didn't load the chain so there was a bug fix and Eric that makes it load the chain so now we can actually see the result and it seems they are very close actually yeah B so uh the the thing is that uh I'm right now just quickly checking so mostly what I'm seeing is that with nethermind we have this thing with the with the fields so nethermind has this transaction Fields issue because the fields are different for each transaction type so that's something that NE mind you could fix I guess

but basically just make sure that the same fields are returned for all transactions like the same basic fields and this means you for example will return the chain ID even for the Legacy transaction and you return the gas price even for the blob transaction and so on so all of these basically need to be but I actually see the gas price generally it also not returned for the new set code transaction from 7702 so it's it's just an inconsistency basically in the implementation you just forgot to add it at some point and this is so I guess it's pretty easy to add that and then it will also pass and now I'm also checking a bit for the um for the receipts but it seems that actually for the receipts we do

align with like nethermind has no errors in the receipts output so it's only reth who has that error okay um we got about 15 minutes left uh I think this is really good to drill down into the the data stuff I think the tldr might be get your tests running and you know compare them to the other clients to uh figure out where these uh you know field inconsistencies might be we will take a look at the tests to make sure um any um client specific assertions uh get surfaced and discussed across teams does that sound fair and we think there's only a handful

of those no awesome okay uh so moving on uh you know what I'm going to actually um there's a a note on the agenda to discuss e fill transaction and E send transaction but we only have 15 minutes left do we want to open it I guess let's ask folks do you want to do an open discussion on PRS that are um going into the execution specs and discuss those or do you want to dive into using fill transaction and deprecating send transaction as a vertical Spike towards a new slightly improved RPC design process option one

option two I I mean I'm not sure if we it's going to be very productive to look in into the PRS okay okay so uh last meeting we discussed eth Phill transaction uh and I believe I believe we were saying that this was already present on gu but it hadn't made it into the specs is that true yeah that's true there's a PR but it's not um added okay and the intent would be hey we could actually deprecate e send transaction since send transaction is

super um is super depend on clients being configured with keys and kind of operating on the wallet etc etc so we want to deprecate send transaction and push people towards e fill transaction how does our process today accomplish that is it sufficient and do we need to make any adjustments around the process if not can you come again what do you mean with the process when I mean the process I mean you know user proposes uh an issue PR into the spec we look at it we you know Pull It in like like what like how well defined is that process

and is it sufficient you know this is this is an example Improvement to an RPC that we want to get better at doing and faster um are there things that are missing in our current specs like error codes uh that need to be re Revisited or need to be I guess evaluated when some somebody submits a new RPC for consideration I don't know I mean I do think that it's not um it's not sufficient right now because we have it has kind of failed for us this process I mean we have this we have raised this PR a while ago like my colleague did it and

it wasn't really we we just weren't sure ourself like what's the next step I mean we have implement this we know that like it's it's a suitable thing that can be working we've tested it for a long time and so definitely it's something that I mean the thing works but the the question is just then like where do we bring it up so this is kind of where the process currently fails right now I mean now we have this call so obviously we could discuss it on here but in the past we weren't really sure like should we bring it up on all C devs when we did bring up RPC stuff on all C devs the reception wasn't great people didn't really respond to it in a way basically

everyone was just like yeah you know I don't care and if there's if not a lot of people care then for example in in ACD then Tim will not really make a decision it's not like you can't you can't just force a decision on ACD by not having anyone respond like people have to at least have some kind of response and it never really occurred because it's kind of a weird for Forum to make these decisions in that's the thing so I guess then the other option would be to raise an interface category EIP and this is something that has done has been done before as well but then it's kind of your back basically doing that would open the floor to then having like a specification Proposal with a rationale that can

be widely circulated you can have a forum like magicians or eth research where you discuss the proposal and so on like that's something that that that could be done but in this particular case we actually haven't done that so that's something we could do and maybe it would lead to more like this gaining more traction at the same time it is very hard to explain the use case for some of these things so for example if we just generally propose to say let's remove e send transaction very few people will maybe understand what we really mean or so I think it's kind of hard to find an audience for this discussion as well I mean you guys Now understand it very well because you're on here but it's

just like something that you have to see that this is not something that is so easy to find anyone to actually discuss with okay so what I'm hearing is maybe it's not so much of a process problem as it is a coordination and investment in the existing process problem IE we're looking for process plus plus not new process I mean we want to we want definitely want we want to have a process and the at the moment this call is like the closest we've ever been to

having like a process where people gather who actually care about the RPC like this is the main failing has just been there isn't like this forum where we can discuss these things and even in this particular call we don't have all the stakeholders here like we would need a significant representation from one or more wallets actually here in order to understand that or we would need a representation from for example uh the RPC providers and then they would have to be able to give their input like you need some a call like that because people need to you know all of these people are involved with this API and it affects them very much I mean I think it would be great if for example I don't know in fura or uh quick Noe or whatever they would they would add this kind of fi

transaction endpoint and say you know if you need to send a transaction you can get your defaults like with this you still supposed to check it on your side and I'm pretty sure they do implement it actually it's just that we don't really have them on here PLO you want to go oh you're back on mute okay so I need to I'm actually trying to see um it seems that inura has been merged with NE with metamask I I can I'm in contact with um

in F folks I've made them aware of this call and I'm encouraging their participation as much as possible no mostly what I'm seeing is like I I clicked I tried to click through the documentation on the site on on the inora side and it lands me now in the metamask documentation could you send me that link cuz that's not good I mean that's not really I mean if you if you go to infura doio and you click access docs you will end up in the in the metamask docs because now infura and metamask are the same as far as I understand like they are they are

literally the same okay so so it's kind of like yeah okay so I mean so they don't have it anyway I checked it but then there's I don't know like we can check I don't know yeah quick note might actually be an example they probably also have this documentation right yeah they do yes okay okay so fossil has appeared in the chat apparently having microphone problems sorry to hear that uh saying want to propose to collect some metrics and share them with the community and Implement in more clients like this

method is a call than than previous approach and it preserves privacy more yeah it's this is a good point like how do we know what our users are doing yeah well I mean you don't but you can definitely I mean I think in a case of fi transaction it's mostly just that we don't want to support send transaction in the nodes so this is where I mean the the wallets do support send transaction and they do it because obviously for them I mean it's the main entry point like you want to they want to definitely capture the app intent to send a transaction so they want to keep supporting it it's just that the nodes shouldn't be supporting it and these send transaction can be implemented in terms of fill transaction and send raw

transaction it's kind of the same it's just this process broken out in two steps so this maybe opens up this like if we were to just introduce fil transaction in the nodes and say you know we're not going to support s transaction anymore I think the world would be fine like people would adapt hardly anyone uses their node to call E send transaction I mean I know a couple people who maybe do it but it's not really a realistic option today so we could just make that choice in this call but then it's a question what happens with the spec should we just give up on specifying send transaction I I don't really like that should we have it as a kind of of optional thing with maybe this like profile thing where we say as a wallet you want to implement it but as

someone else you don't want to implement it and like this all of these things are basically bit unclear right now but I do think that with Fi transaction it's just a matter of implementing it like you can implement it in the client no problem and if you have the feature and you know some advertisement happens for this feature then it will also be used okay I'm going to treat this as to be continued it sounds like we have more discussion to do and the answer just be something simple as push an EIP in the interface category and in bold print at the top says we intend to deprecate x with this new RPC y right and it's just a thing that we talk about and then it's it's part of driving uh consensus from

the RPC providers from our audience from our users etc etc uh in the broader context of uh introducing the EIP but it does not force uh or delay implementation of you know for instance eill transaction as we wait for eth send transaction to be deprecated I like that it's more of a just process Improvement than trying to build a new process cool all right we got four minutes left um one thing I wanted to ask real quick I mean we use all the time but sure this is uh you know one of our earlier calls um I was going to propose should this be a half hour call as opposed to an hour call but I don't I don't know an

hour kind of feels right at the moment is anybody upset with how long this meeting was it felt pretty content dense to me I mean it's interesting but we do need to get more people into this meeting so I think that's the thing you just need to I mean this is something that we need to figure out how to reach other people you said it before and then it can totally be an hour but we have to hear it from other people well like what they what they are do no changes for now then all right cool I think that's a good um stopping point but three minutes

if anybody wants to take the floor all right rad I'm going to post my own notes as well as a list of action items in the RPC Discord on e&d and this was recorded it'll probably find its way onto YouTube and uh historically AI generated summaries of meetings have also been posted as well so be on the lookout for those if you need them

cool thanks everyone uh see you again in two weeks or on the e&d RPC Discord Channel