Add chain_id to get_info and push_transaction requests

[abourget]

This would be tremendously useful when we have IBC active between two chains, but want to keep clients dumb about how to reach each chain.

As BPs, we would like to run all chains that make sense that are attached to the mainnet (through pairs of contracts). We want to offer a single endpoint and route your transactions to the right chain. For that, we'd need to know which chain you're targeting when you get_info (to prep the tapos headers), and when you push_transaction. We would reverse proxy it to the right nodes node based on that info.

Without these parameters, a client would need to have the chain is (that is true in all cases) as well as some http endpoints and network routes to match those chains.

If BPs or other entities run http endpoints for clients, and use apps on multiple chains (or do cross-chain trxs), they at least could offer a single endpoint.

[wanderingbort]

As it wasn't clear to me on first read, I would like to note that one use case of this is to be able to run a reverse proxy in front of the HTTP-RPC services for multiple chains which can correctly route to a backend based on request/header parameters alone.

For that purpose, it may be worthwhile to consider adding it to the URL path or parameters and not the payload. Those components are part of the HTTP headers, which is a more convenient location for layer7 proxies. Otherwise, proxies must parse (potentially reassembling from a stream) the payload in order to route. That introduces latency and burdon on what should be a simple pass-through layer7 proxy.

[nsjames]

There's another use case as well. In Scatter it would allow transactions and accounts to be referenced to the chain instead of the node/network the app is connected to.

Take for instance a user interacting with abc.com. When the user authenticates with that website the website gives them the network they are using to contact the EOSIO chain, user's must then map their account to that network within Scatter. This is used for building whitelists and making sure networks aren't changed on users ( for example an app changing their network from a testnet to the mainnet, where an account could be the same, and suddenly the user is using real money without knowing it because all hash fingerprints match regardless of chain )

As far as scatter knows that node/network is on its own chain, so when a user goes to another app at xyz.com which is using the same chain but a different node (owned by the app) they have to add another network and duplicate their account mapping even though it already exists within abc.com's mapping. ( which would be common, since most apps will have their own processing/witness node )

Having a way to get the chain id would allow a mapping of (chainId -> account) instead of (network -> account) or (domain -> account) which would give a better user experience and more secure whitelisting of actions.

[abourget]

I agree having that in the querystring would be even better. Nodeos could default to the local chain_id if the parameter (would be chain_id I guess?). Or not, forcing it to be transmitted always.

The important bit is that cleos and other libs take the habit of transmitting that value in a standard way. If it's not forced, it might be missing.. and if we can't rely on it, it's of no use.

[abourget]

Could be a url parameter, /v1/chain/push_transaction/01010101011010101010101010101...

We could have /v1/chain/get_info AND /v1/chain/get_info/101010101010101010101010101010101...

One when you don't know the chain ID of the node (it would return it), and one when you do know.

[brianjohnson5972]

get_info now contains the chain_id (#3415)

@wanderingbort Is chain_id still desired for push_transaction? If so, should we keep it open or should we close and make an issue for what remains to be needed?