Skip to main content

Transaction reordering

On Ethereum, a block producer chooses the exact order of transactions in a block. That power is what makes front-running and sandwich attacks possible — the producer can insert its own transactions around yours for profit.

ZENIQ Smart Chain removes that lever. The order in which transactions take effect is not the order chosen by the block proposer. Instead, transactions are reordered by a deterministic on-chain algorithm with two goals:

  1. Maximise parallelism between transactions (so the parallel executor has independent work to do).
  2. Mitigate front-running by shuffling the order pseudo-randomly.

How the shuffle works​

After a block is committed, and before its transactions are executed, the transaction list is pseudo-randomly shuffled:

  1. Build a from-address list and a map from each from-address to its transactions.
  2. Derive the shuffle seed from the block's DataHash (the Merkle root of the block's transactions).
  3. Shuffle the from-address list using the MT19937-64 pseudo-random generator seeded above.
  4. Rebuild the transaction list from the shuffled address list and the map.

Per-account order is preserved. Multiple transactions from the same account keep their nonce-increasing partial order, so nonces still execute in sequence. In the shuffled list, a single account's transactions sit adjacently, but they are not executed back-to-back: within an enforced bundle only the first is executed immediately; the rest are pushed to the end of the standby queue and executed last.

Why this resists manipulation​

Because the seed comes from the block's DataHash, a proposer cannot pick a transaction order directly. To force a particular relative order among specific transactions, a malicious validator would have to try different transaction sets — and therefore different seeds — until one happens to produce the order it wants. The cost of that search grows exponentially with the number of orderings the attacker is trying to enforce, which makes targeted front-running impractical.

Determinism

The seed is derived from on-chain block data and the generator (MT19937-64) is fully deterministic, so every node computes the identical shuffle. Reordering is consensus-critical and does not depend on how many goroutines the parallel executor happens to use.

A future upgrade may derive the seed from a Verifiable Delay Function (VDF), further shrinking the window in which a validator could try alternative seeds.