Add JSON-RPC proxy for nlpn

[kdeme]

The Portal Network client will need to support a subset (still under definition) of the eth JSON-RPC API.

First focus of the Portal Network will be on sharing the state data. Right now, nothing is even shared, so none of the eth JSON-RPC API can be used.
For this reason, it would be good to have a JSON-RPC proxy added to the nlpn client. So that, at first, all JSON-RPC methods can be forwarded, but eventually, we can start supporting locally those based on the data we get from the Portal Network (as mentioned, this would be state first). This way, the client can already be tested in combination with wallet or other functionality.

It should be (at least) possible to:

• Filter out which methods to relay and which ones not.
• Provide the JSON-RPC endpoint at command line (whether a local Ethereum client, or a centralized service running those).

I believe ideally the actual proxy gets implemented in nim-json-rpc repository: https://github.com/status-im/nim-json-rpc

A similar proxy exists for Go: https://github.com/gochain/rpc-proxy, with some additional functionality.

edit: create also issue status-im/nim-json-rpc#102

[jlokier]

@jangko had some ideas about formalising nimbus-eth1's JSON-RPC using schemas to make the implementation more solid and type-checked, starting with this comment: #610 (comment)

Eth1 JSON-RPC has a working group that aimed to standardise the JSON-RPC calls, to deal with the fact different eth1 implementations have some calls in common, some differences, and a lot of copying each other. Here's that spec: https://github.com/ethereum/eth1.0-specs/tree/master/json-rpc

If you are implementing the full suite of Eth1 JSON-RPC calls to proxy them all, it may be worth taking into account the above spec as well as whatever schema typed mechanism nimbus-eth1 may offer, i.e. making that mechanism suitable for use by the proxy as well.

I don't know if GraphQL is also in the nlpn goals, but it has become an essential part of the Hive testsuite, so perhaps some RPC clients will start to expect it. There appears to be a mapping between GraphQL and JSON-RPC: https://eips.ethereum.org/EIPS/eip-1767#backwards-compatibility, and this is implemented in nimbus-eth1 already, well enough to pass Hive. Just in case GraphQL is something that ought to be included alongside JSON-RPC.

[kdeme]

If you are implementing the full suite of Eth1 JSON-RPC calls to proxy them all, it may be worth taking into account the above spec as well as whatever schema typed mechanism nimbus-eth1 may offer, i.e. making that mechanism suitable for use by the proxy as well.

Eventually, a Portal Network light client will support a subset (to be defined what that subset is) of the JSON-RPC API that you link. So yes, we will be able to reuse some of the work you are doing there now, and/or further work on it.

But this issue is rather about having a proxy, where you can select ("register") certain methods of the API, not to be handled locally, but instead forwarded to another JSON-RPC API endpoint (say a local geth client, or Infura, etc.). One could do this right now by handling the forwarding in the actual RPC method, but I rather have something simpler that doesn't require this step and just takes the raw json data and forwards it based on method. So that no marshaling steps need to happen at the nlpn client.

[kdeme]

@KonradStaniec

Can this be closed? Or keep it open after https is there to fully test?

[KonradStaniec]

I would keep it open, and close it only after https client pr is merged in json-rpc package. ( and we are able to get some data from infura

[KonradStaniec]

for now I have tested it with websocket + infura and it seems it works as expected.