Skip to content

Instantly share code, notes, and snippets.

What would you like to do?

Feb 10, 2021 Eth1 JSON-RPC Standards Meeting

  • Recap of last meeting:
  • Tomasz: should we discuss broader future changes to Eth1 JSON-RPC as part of this standardization effort? There are discussions about moving to GRPC or REST.
  • Artem: [Describes GRPC]... "GRPC is the de facto standard for connecting microservices". GRPC has better tooling, industry support, is robust and performant, and we use it in turbo Geth. So I think we should double down on it going forward.
  • Mike: GRPC is more complicated to load balance than REST. If we want to enable more people to run their own infrastructure, we might prefer REST.
  • Felix: I think it would be good to keep this discussion focused on standardizing the existing JSON-RPC standard. We don't have a definitive standard for the existing interface, so it might be messy to transition to a new system before specifying the old system.
  • Micah: JSON-RPC is difficult to specify with a great deal of explicitness. We had to put a huge amount of effort to build a JSON-RPC with no compatibility issues. If we move to something like protobuf it becomes much easier to specify.
  • Felix: It's kind of true what you're saying, but on the other hand, we have some existing specs for the JSON-RPC which are pretty detailed. I don't think it becomes easier in protobuf-what happens when gas isn't specified in an eth_call? It's all things you have to specify either way.
  • Danno: I would like to vote on switching transport as being out of scope for this discussion. We'll never make progress if we get caught up on a transport-layer discussion. There are a lot of users already using JSON-RPC, and it would be a disservice to them to not improve JSON-RPC as-is.
  • Artem: There is a saying in Russian "There is nothing more permanent than temporary". If we focus on freezing the JSON-RPC today we will never revisit this discussion. If we want to get a transport change done we have to do it perfectly and correctly right now. I think this is a soft rejection of GRPC, so I disagree with this approach.
  • Danno: It's not a temporary crutch. If we do this now we're going to bike shed over a huge number of details. We can come back to it.
  • Tomasz: I think the best thing would be, after the call, to ensure there is strong support for the proposed GRPC change by reaching out to the maintainers to ask if they would support a separate branch of standardization. At the same time we should stay loyal to the original plan of improving standardization for existing JSON-RPC standards.
  • Tomasz: Lets move to the next item on the list. The maintainers suggest that their site would be the best place for the golden source of the spec to exist. And they also offered help in editing and maintaining the spec.
  • [People seem generally fine with this]
  • Tomasz: If we prepare a spec now, should we define a versioning scheme for it up front? Or can we launch without a versioning scheme? How should we think about versioning the spec?
  • Felix: In the existing system we have a per-module version approach, but it has never really been used. After version 1.0 things have changed many times. It would be good to start with a spec that says "this is version 1" and then we should start bumping module versions as we make changes. It would be good to version individual modules like the eth namespace for example rather than the whole API, since some modules will be much easier to standardize than others (admin and debug will be hard).
  • Micah: I am going to say something i will immediately regret: If we do versioning in the spec we'll need a protocol for handshaking JSON-RPC requests between clients. That is a big can of worms. If someone wants to tackle that it would be good to see proposals on it. GRPC does handle this for us, but it'll be complicated to do ourselves.
  • Felix: We're not talking about handshakes. We're talking about the version numbers of the spec. Most clients support an rpc_modules API that says what module versions it supports. I think it's not going to be possible to make backwards-incompatible changes to the JSON-RPC. We should standardize the existing thing without changing it.
  • Micah: I agree with most of what you said but I have different conclusions. If we can't do backwards-incompatible things, all we can do is add. Which puts us in a very similar boat to browsers, which are un-versioned because you can never remove any APIs.
  • Dragan: I think versioning is important because there will be a transition between the RPC we have today and the standardized one we will have in the future.
  • Tomasz: Can we create some actionable items where we immediately remove things from the spec which have not seen support in a long time, for example Solidity compiler support?
  • Felix: Compiler support is obsolete. In order to support this you would have to bundle the Solidity compiler. Even in the original release of Geth it was an optional feature that could not be relied on because it would only work if you had the Solidity compiler installed. Nobody has the Solidity compiler built-in. I think it was an early bad decision to include compiler support in the API.
  • Micah: I would propose that we do the opposite. Each thing we add to the official spec, someone should argue for it. So don't add anything that nobody would argue for. I think the Solidity compiler is an extreme example that nobody would argue for. I think there's plenty of less extreme stuff that most people wouldn't care about, and so if we go forward without making people advocate for what is included, we'll end up porting forward a bunch of cruft. Every RPC that gets included in the spec should at least have somebody nominate it. I bet there's plenty that just nobody will even nominate.
  • Nicolas: we don't support compilers at all in Besu.
  • Tomasz: neither does nethermind.
  • Tomasz: I will compile a list of methods and make space for people to add comments on what should be included. Then we will clearly see the ones that nobody wants to defend. I would simultaneously propose that we just agree now to remove compiler support from the JSON-RPC spec. Lets see how quickly we can just wipe it out entirely from interface definitions and specs.
  • Tomasz: In regards to the collection of inconsistencies which were mentioned last time: the debug tracer from Geth supports javascript-based plugins. Is this a good example of something which we should standardize?
  • Felix: This was added because there was some use-case where fine-grained tracing was required, and were meant to be an alternative to the system provided by Parity where you could get internal calls. Some block explorers were asking for support in Geth to do something like that. At the same time we wanted to solve our own problems with existing tracing, but in hindsight I think it's bad that we added this. It's really complicated and nobody ever documented it properly. The documentation is still bad and the interface itself is not great. Tracing is a need that many applications have and it's a complex topic of how to do it properly. It's quite important to have a discussion about how to do tracing APIs, but it doesn't necessarily have to be Geth's implementation.
  • Danno: Two questions: should we specify the tracing stuff before specifying things like whether we keep the pending block? Should we prioritize how and where we are standardizing APIs? Also, do we have any client libraries here like web3js or ethers? Because they would be an important voice for us to hear from in terms of hearing from downstream what people want from us.
  • Juan: I have many people who want to use tracing who are confused about the different client implementations. This is a pain for me, having different clients with inconsistent implementations of this. I agree it's good to ask downstream users what they want from us... Maybe there is somebody using eth_compile!
  • Tomasz: I've added a separate issue on tracing. It seems like a big issue we can work on in parallel.
  • Tomasz: We'll have another call in eight hours on Asia-Pacific time. Thank you for attending today!
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment