• Geth version: 1.8.12-stable
  • OS & Version: Linux/OSX

Expected Behavior

Transactions to distributed to network right at its sent block number and deployed within that.

Actual Behavior

Transactions are delayed one block time to be distributed over network and consequently deployed one block time late.


I have a small cluster that is connected to private Ethereum chain that uses POA and block time is fixed 15 seconds. The cluster has four nodes that all nodes are connected to each other. Please note that, there is three signer nodes on my cluster.

When I submit a transaction from a node; the transaction does not reach to all signer nodes on the current block but it is transferred onto the next block. But, I observe that the sent transaction was received by the non-signer node right after it is sent.

For example; when I sent a transaction within the current block, it will not deployed on the current block but on the up coming block. So this forces network to deploy a transaction in 2 block time which is in between 15 seconds to 30 seconds.

So if I sent my transaction on 1st second of the block, first I need to wait 14 seconds for next block to come. And wait additional 15 seconds more on the next block for that transaction to be deployed, so in total I need to wait 29 seconds.

Example case: alper@home is non-signer node and other nodes are signer node.

I sent a transaction within block number 869,334 from node named eBloc@netlab (signer-node) and transaction shows up right after at alper@home named node (non-signer node) on block number 869,334 but it does not show up on the signer nodes even on the node that I sent it from.

enter image description here

On the next block (869,335) I observe that all nodes receive the transactions.

enter image description here

And finally on block number (869,336) the transaction is deployed.

enter image description here

=> If the transaction was distributed to all cluster right after it sent it should be deployed on the block number (869,334) but it used 1 additional block time for this.

[Q1] Why the sent transaction received by the non-signer nodes right after it is sent but not by the signer nodes?

[Q2] Is this normal that the sent transaction won't transfer to all the network right after it is sent but it takes additional 1 block time even all nodes are connected to each other? Is there any way to force to transfer a transaction to all my signer nodes right after it has been sent?

Note: Further discussion could be seen on a opened issue on go-ethereum.

  • Would have loved to get the bounty though :/ – Nikita Fuchs Aug 4 '18 at 16:40
  • As I understand from developer's comments, my example case is a normal case for the mainnet, where signer nodes obtains and signs transactions 1 block delayed, the system forces this. But this implementation also covers testnets so no matter what system forces transactions to distributed to signer nodes 1 block delayed even the block is completely empty. On my question I was searching a solution for this issue, but I guess I am dependent developer's decision/implementation for a solution. @NikitaFuchs – alper Aug 4 '18 at 18:02

In a public (proof-of-work blockchain) network, it's not in the interest of miners to include transactions as soon as they're gossiped to them. A reason for that can be derived from the following excerpt from the yellow paper (Page 7, EIP 150 revisioned release):

Because the nonce must satisfy [the block validation] requirements[s], and because its satisfaction depends on the contents of the block and in turn its composed transactions, creating new, valid, blocks is dicult ...

In other words, when trying to find the block nonce, the miner already needs to have a merkle root of all the transactions to include into the block. Would he constantly add new transactions, the root hash would change and he would have to start mining from the beginning.

I do not know exactly about the two-block-delay between broadcasting and mining, but here is what I assume: If Block n is the block your transaction is mined in, then

Block n-2: Transactions are being broadcasted into the miner's mempool.

Block n-1: Miner picks and executes/validates transactions as fast as possible, to have "everything ready" to compete for mining the next valid block, only waiting to receive the parent block hash.

Block n: Miner got the parent block hash, nothing else changes in his block candidate, he mines the right nonce and seals the block.

One could of course change this behaviour in the mining node client, this would require some skills in go or rust, of course ;)

  • 3
    Please see (github.com/ethereum/go-ethereum/issues/…) ; I guess, this (functionality to immediately include transactions into blocks if there is still space) would be considered to be implemented in future for the testnets .@Nikita Fuchs – alper Jul 30 '18 at 12:46
  • There is no miner node on Proof-of-Authority hence there are only couple of signer nodes. The issue is I am observing transactions can be distributed to non-signer nodes right after they are sent, but no matter what transactions are distributed to signer node in 1 block delay time even block is empty. @Nikita Fuchs – alper Aug 4 '18 at 18:07
  • There is no such thing as a signer on a PoA network, and no such thing as a forced transaction broadcasting delay. On PoA, it's just that only the authorized nodes are allowed to mine a block, and from there on everything is according to my above answer: Every transaction is broadcasted immediately, miners just need to have everything ready beforehand in order to not having to start over mining again. – Nikita Fuchs Aug 4 '18 at 19:45
  • There is this function clique.getSigners() please see (ethereum.stackexchange.com/a/15779/4575). As I shown on my question when I sent a transaction it won't show up on the current block that would be mined immediately on the block that is sent even there is no other transaction exist on the block. So if I sent my transaction on 1st second of the block, first I need to wait 14 seconds for next block to come. And wait additional 15 seconds more for that transaction to be deployed, so in total I need to wait 29 seconds. – alper Aug 4 '18 at 20:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.