Add the capability of running --rpc-methods safe/unsafe RPC endpoints on different ports

[PierreBesson]

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.

[niklasad1]

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-methods completly and use --rpc-port-unsafe and --rpc-port instead but might be tricky if one wants to just have unsafe methods and which one to enable by default.

There is also unsafe-rpc-external which 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]

One way to provide this feature could be to add extra flags such as:

• --secondary-rpc-port (eg. value 9933)
• --secondary-rpc-methods (eg. value safe)

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-port and --ws-port flags are deprecated and need to be replaced either by migrating to a single port or the secondary port solution.

Also the fact that the unsafe keyword refers to 2 different things in Substrate is extremely confusing but this is a separate issue.

[niklasad1]

Fair enough, sounds good to me

but we can keep --rpc-port and remove ws-port then introduce --secondary-rpc-port