Remote procedure call specification

Interfaces
21

I haven’t thought super deep on the implementation details. In general, anything that requires a private key to complete should be part of the signer API and antsything that requires chain interaction would be part of the other API.

This does get murky when you want to do things like verifiable signing UIs, because the signer needs chain access. In such cases I would argue that should be part of the signing API, as the signer can gracefully degrade if it doesn’t have chain access.

22

we have been working on a solution that is now at 1.0.0, it is akin to openapi but specifically designed for JSON-RPC.

here is the EIP PR

love to get some feedback and see how we can work to standardize JSON RPC descriptions.

3 Likes
23

@bitpshr How would one go about updating this specification? E.g. https://github.com/ethereum/EIPs/pull/1898. Just submit a PR modifying eip-1474.md?

24

@charles-cooper: That works for me. If you tag me in a PR, I’ll be sure to review it. I’m also open to adding an additional EIP maintainer to 1474 so I’m not the sole reviewer and don’t be come bottleneck.

25

I posted something similar to this in the EIP PR for discussion on OpenRPC, but can these OpenRPC documents be composed? i.e. if we had a standard set of documents “these OpenRPC files represent the standard eth_* RPCs for 1.0” can I then publish a document on my node that includes the standard RPCs and includes my server specific endpoint name?

My reason for asking is that a spec for this should not consist of “please use OpenRPC” but instead it should be “here are the standard OpenRPC mappings for EIP X, EIP Y, and EIP Z, they live at URLs A, B, and C, and here is a sample of MultiGeth composing those into one endpoint.” Otherwise this EIP is noting more than “OpenRPC is cool, please use it.”

1 Like
26

Yes! Excellently phrased. Same goes for GraphQL and anything else.

@bitpshr want to take another crack at making a separate JSON-RPC repo? I don’t have time to lead this process, but much like devp2p now has a separate repo to gather interested parties I think this would be valuable.

This one is basically empty and can be ready to go: GitHub - spadebuilders/ethereum-json-rpc-spec: Working group for the canonical JSON-RPC spec for Ethereum clients

But obviously any home base repo for the spec & related standards/implementations would work.

27

@shemnon I’ve added the entire openrpc.json for #1474 + #1436 and eth_getRawTransaciton* methods to the Pull Request here: https://raw.githubusercontent.com/ethereum/EIPs/dbf64faff4dfe2f832d752292a39b8d7b9b46d2a/assets/eip-1901/openrpc.json

And to answer the question around composition, yes its possible, having relative paths is a bit of an edge case, but see my comment here: https://github.com/ethereum/EIPs/issues/1902#issuecomment-488075648

I think that having 1 canonical EIP that contains ALL the methods will help get everyone on the same page, rather than breaking it out to separate files. The same way the #1474 gets updated. Any client can easily extend it.

1 Like
28

My concern with one canonical EIP is then clients that do not implement all the endpoints will need to edit the canonical file to remove them, and if clients are chopping up canonical files their value is diminished.

As an example Pantheon does not implement eth_send* and eth_sign* methods because we do not integrate a key management system for wallet keys in the node (this is a deliberate security decision).

2 Likes
29

I like the idea of just removing eth_send* and eth_sign* (except send raw) from the specification altogether. I’d rather users not be able to keep their funds in clients either.

1 Like
30

Took the time to put this repo together let me know what you think: https://github.com/etclabscore/ethereum-json-rpc-specification

Hopefully this addresses the comments above.

2 Likes
31

EIP-1767 (the GraphQL EIP) also didn’t implement the send and sign transactions as a non-essential call for nodes. There appears to be some consensus on that. A second file with those APIs may be useful to clients who do implement it.

2 Likes
32

eth_signTypedData says that the second parameter’s type is Data but it is not, it is a complex object.

33

Here is the talk from EDCON 2019 on OpenRPC and how we can level up the ecosystems tooling:

1 Like
34

The draft says the following with regard to eth_getLogs -

Note: The return value of eth_getLogs when retrieving logs from eth_newBlockFilter and eth_newPendingTransactionFilter filters will be an array of hashes, not an array of Log objects.

I think it would be nice to clarify how to use eth_getLogs with block/pendingTransaction filters.

35

Bumping this topic up, and calling for people from various organizations to participate in the OpenRPC standards development process that is being run (as sort of a pilot project) by OASIS (see https://github.com/ethereum-oasis/oasis-open-project and OASIS-EIP stewarding process).

Is OpenRPC important to you? Do you see anything in the current spec that you’d like to change or improve? If so, please consider supporting the OpenRPC standard development process by joining the Technical Steering Committee. Contact me for details.

1 Like
36

What’s the expected behavior of eth_getLogs if the blockHash does not correspond to any block? This is not just a theoretical consideration, since chain reorganizations might cause a blockHash to no longer be valid.

I’ve seen implementations which return the error code -32000 (invalid input) with the message "unknown block", I’ve seen implementations which simply return an empty array. Perhaps -32001 (resource not found) would be a better error code, but I didn’t see it in any implementation.

I think that the behavior for unknown blocks should be standardized.