Inconsistent gas spending

[rajeshsubhankar]

• Parity Ethereum version: 2.1.7
• Operating system: Linux
• Installation: built from source
• Fully synchronized: yes
• Network: private
• Restarted: yes

I was studying the behavior of PoA based private network with 5 nodes w.r.t. broadcasting a set of transactions to a single validator vs all 5 validators.

My expectation was if I distribute my transactions to multiple validators then I will get better throughput (TPS) as each validator will now propose blocks full of transactions rather than empty blocks.

As you can notice, if I distribute my transactions to multiple validators (image 1), I am getting only 5 transactions per block with gas spending per block reaching block gas limit easily. Whereas the same set of transactions hitting a single validator (image 2) gives 49 transactions per block with very little gas spending per block.

Extra configuration details:
From genesis.json,

"stepDuration": "5",
"gasLimit": "0x5B8D80"

From .toml configuration file,

[mining]
engine_signer = "0x00Bd138aBD70e2F00903268F3Db08f2D25677C9e"
reseal_on_txs = "none"
usd_per_tx = "0"
tx_queue_per_sender = 100000

And in both the cases, I am firing transactions every 0.5 seconds.

[jam10o-new]

The order and speed of transactions getting verified has more to do about which accounts send the transaction than which validators the transactions are broadcast to. If you accidentally send a transaction to a validator without its preceeding transactions, it won't be able to include that transaction in the block until it sees the preceeding transaction confirm, whereas if you have all the transactions from a specific account on a single node, they can all be sealed and ready for inclusion on the blockchain at one time.

Does that by chance help clarify what you are experiencing? Or are you already segregating accounts to specific nodes?

[rajeshsubhankar]

I am already segregating accounts to specific nodes.

[jam10o-new]

@rajeshsubhankar we've improved this logic in a few ways recently (ie #10051) - are you still seeing this on recent versions or have you come across a workaround you can share?

Let me know and I will reopen this issue.