Skip to content

Conversation

@ckartik
Copy link

@ckartik ckartik commented Jun 4, 2024

The reason for this change is because the block sealing process was setting the header.Time timestamp into the future, delaying consensus approximately ~200ms beyond when the transactions were applied to the EVM. This could result in situations where transactions are applied correctly during simulation, but fail once consensus check is complete, because the final header.Time is 200ms into the future of the initial simulation.

	header.Time = parent.Time + c.config.PeriodMs
	if header.Time < uint64(time.Now().UnixMilli()) {
		header.Time = uint64(time.Now().UnixMilli())
	}

This change reduces the latency of the geth transaction processing from time a trasnaction enters the mempool to it's finalization at the consensus layer to about <50ms. This is a significant improvement from the existing latency which was in the order of 200ms - 1000ms.

  • We reduce the minimum block period to zero, this allows for blocks to be produced at any time.
  • The only restriction that will be left, is that timestamp progresses forward in time, however, this is of little relevance as there will be only one clock (in the single signer node), so this restriction would be satisfied irrespectively.
  • Another aspect is that blocks will now only be produced when transactions are included in the block (e.g no empty blocks)
	// For 0-period chains, refuse to seal empty blocks (no reward but would spin sealing)
	if c.config.PeriodMs == 0 && len(block.Transactions()) == 0 {
		return errors.New("sealing paused while waiting for transactions")
	}
  • This change has been tested on a latitude server and produces significant latency improvements and will likely also improve disk utilization

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants