Repository navigation
Add the capability of running --rpc-methods safe/unsafe RPC endpoints on different ports #12846
Description
At the Polkadot Barcamp in Lisbon, we hosted a workshop session on Substrate node operations. One piece of feedback we received is that to expose 2 endpoints, 1 with rpc-method=safe (usually public) and 1 with rpc-method=unsafe (usually only accessible to the node operator), you will need to manage 2 nodes as for each node you have to choose whether your RPC endpoint will be safe or unsafe (by setting the --rpc-methods flags). To solve this it was suggested that the node could expose 2 different endpoints, 1 safe and 1 unsafe.
I wonder if recent versions of jsonrpsee wouldn't make this easy to implement, especially as the current WS and HTTP endpoints are getting merged into one. ping @niklasad1
For example, we could use 9944 for the safe endpoints and 9933 for the unsafe one. This way the dual endpoints would no longer be about the supported protocol but about method safety. We could also use a totally different port number (eg.9955) for the rpc-method=unsafe endpoint.
Personally I think having things set up this way, would make it less confusing and less likely someone would mistakenly expose unsafe RPC methods publicly.
Activity
niklasad1 commentedon Dec 5, 2022
It should be quite easy to support but the CLI configuration sounds quite tricky if we want to keep
--rpc-methods.I'm down for removing
--rpc-methodscompletly and use--rpc-port-unsafeand--rpc-portinstead but might be tricky if one wants to just have unsafe methods and which one to enable by default.There is also
unsafe-rpc-externalwhich works in combination with those as well.The mixed WS/HTTP server shouldn't matter here, we could just start two servers on different ports.
PierreBesson commentedon Dec 5, 2022
One way to provide this feature could be to add extra flags such as:
--secondary-rpc-port(eg. value 9933)--secondary-rpc-methods(eg. valuesafe)Those flags could also be used for the planned backward compatibility with the current dual http/ws ports. Please confirm me if this would work but we could potentially set the secondary port value to current --http-port and the primary to --ws-port while warning the users that the
--http-portand--ws-portflags are deprecated and need to be replaced either by migrating to a single port or the secondary port solution.Also the fact that the
unsafekeyword refers to 2 different things in Substrate is extremely confusing but this is a separate issue.niklasad1 commentedon Dec 6, 2022
Fair enough, sounds good to me
but we can keep
--rpc-portand removews-portthen introduce--secondary-rpc-port