Parity-ethereum: Re-define `pending` state in RPC

[tomusdrw]

Currently our pending state definition is quite pure: It's the state of a pending block (currently mined block) or latest canonical chain block if the node is not creating the pending block (light client/no mining/no --force-sealing).

For that reason we had to implement custom parity_nextNonce method to get a next available nonce for particular sender (including transactions in the queue).

Perhaps we should create some exceptions for methods like eth_getTransactionCount(address, 'pending') by default or under some CLI flag.

Problematic stuff: pending receipts, balance, storage_at, code_at, call, estimate_gas.

[5chdn]

I'm tempted to close this as _stale_ unless someone steps up to join this discussion on the pending state.

@paritytech/core-devs Please assign this issue to someone and decide on a deadline within 7 days, thanks.

[danfinlay]

Sorry for not jumping in sooner. Getting the current number of pending transactions is currently a difficult problem for consumers of the RPC.

The parity_nextNonce method is nice, but since it isn't cross-client compatible, any code written that uses it requires Parity as the backend, so it doesn't seem ideal to me.

Adding pending as a parameter to some transaction methods, like getTransactionCount would be very powerful, and allow remote signing clients to more easily set their nonces correctly.

Since the definition of pending right now is very pure, maybe a new parameter value could be chosen for this meaning, like pending_mining, or pending_inclusion.

[tomusdrw]

Related: https://github.com/paritytech/parity/pull/6942

By running with --infinite-pending-block all transactions from the queue will be there and all RPC methods with argument pending will be able to respond "properly".
NOTE this executes all transactions in the queue and may require quite beefy hardware.

[folsen]

@danfinlay (Going through stale issues here) Does @tomusdrw comment above satisfy your requirements in any way. I agree that anything that is dependent on parity-specific RPCs isn't going to be very nice to use, have you thought about opening an EIP for adding this? I would certainly support it.

[danfinlay]

At MetaMask, we've addressed this problem by tracking pending transactions locally.

This makes sense for us because we point at a load balanced cluster, can be pointed at different clients, and keep a transaction queue.

If we were the only ones holding this open, it could be fine to close it.

[tempofeng]

@danfinlay Can you share how you guys tracking pending transactions locally? We're having this nonce problem as well.

[danfinlay]

@tempofeng We calculate the next nonce like this:
https://github.com/MetaMask/metamask-extension/blob/develop/app/scripts/controllers/transactions/nonce-tracker.js

This thread is probably the wrong place to discuss this. If you have a question about how MetaMask works, please open an issue there.