eth/server: Dumb down finding balance. #2020
Conversation
|
Also ok to rewind the jwt endpoint. Just offering this up as another option. |
|
Are we absolutely certain that specifying the apis via |
|
Seeking clarification from geth devs: ethereum/go-ethereum#26406 |
|
Looks like #2023 is preferred, so closing. |
| // reason, so we'll have to use CallContext and copy the mimic the | ||
| // internal RPCTransaction type. | ||
| var txs map[string]map[string]*RPCTransaction | ||
| err = c.caller.CallContext(ctx, &txs, "txpool_contentFrom", addr) |
There was a problem hiding this comment.
I haven't found any publicly available (paid or not) RPC providers that have any methods from the txpool namespace available. I'm thinking we can have server identify which method to take on connect via the CheckAPIModules function you added, however I'm not seeing rpc_modules supported anywhere either! Perhaps using a third-party RPC provider with server is gonna be trickier than I'd like.
There was a problem hiding this comment.
Yeah, when I tested the modules request itself was only available from geth.
There was a problem hiding this comment.
Been stewing on this, and I think we should revive it with a mini project to support an RPC provider that does not provide txpool, but use the smart balance if it does.
The aim would then be to allow the operator to use a third party RPC provider that they trust, ideally with their account's own API key so rate limits aren't so prevalent.
This is going to be key to make testnet or just mainnet "testing" less of burden. At present, it's ridiculously difficult, time consuming, and expensive to get geth+prysm running on either network. We are currently blocked on this.
closes #2016