The quality of a block is decided before it is authored — in the pool that decides which transactions are ready, in what order, and which can safely run at the same time. EmpoorioChain replaced the flat transaction queue with a DAG mempool, and this post explains the decision and its limits.
The production decision
The engineering docs record it in one line: Aura/GRANDPA plus an improved DAG mempool. Full DAG-based consensus (the Bullshark family) stays an experimental track. The reasoning is worth quoting in substance: Bullshark is not just a different queue. It changes how data availability, ordering, block authoring and finality are separated. Turning it on without replacing the authorship pipeline would create the illusion of a DAG while blocks remained linear under Aura. So the safe path is: keep the consensus, improve the pool, measure under load, and only then decide whether to move authorship.
What the DAG mempool does
Code lives in runtime/src/mempool/dag.rs, advanced_mempool.rs and gossip.rs, with node-side metrics in node/src/emp_metrics.rs. Capabilities:
- Dependencies by nonce — a sender's transactions form a chain; nonce 7 cannot run before nonce 6.
- Dependencies by storage — read/write hints let the pool detect that two transactions from different senders touch the same state.
- Deterministic ordering by fee priority, then nonce, then transaction id. Every node orders identically.
- Batch builder that assembles groups of independent transactions up to gas and length limits — exactly what the parallel executor wants.
- Duplicate rejection and cycle detection.
- Gossip of DAG vertices and whole batches to peers.
The effect on block building: the author receives pre-partitioned batches instead of a flat list and can hand them to the parallel scheduler with less planning work. The effect on fairness: ordering is by declared priority and arrival, deterministically, not by whoever wins a network race.
Metrics
emp_txpool_pending_txs
emp_txpool_dag_width
emp_txpool_dag_depth
emp_txpool_duplicate_txs
emp_txpool_propagation_delay_ms_p95
Width is how many independent transactions are ready at once (parallelism available); depth is how long the dependency chains are (serialisation forced by senders). Duplicates measure wasted gossip. Propagation delay is the network's health. Legacy gauge names (emp_mempool_*) remain for compatibility with existing dashboards.
Tests
cargo test -p empoorio-runtime mempool::dag --lib
covers out-of-order nonces, fee prioritisation, storage conflicts and duplicates.
Criteria for going further
Before anyone proposes replacing Aura's authorship with a real DAG consensus, all of the following must exist:
- a proposer of our own integrated with the transaction pool;
- identical state roots against Aura/GRANDPA under the same load;
- Zombienet runs with 4 and 10 validators under artificial latency;
- stable Prometheus/Grafana dashboards;
- adversarial tests — spam, duplicates, conflicts, invalid dependencies, forks;
- a rollback plan back to Aura/GRANDPA.
None of these is optional, and the list is in the repository so that a future contributor cannot skip one by forgetting it. Block optimisation on EmpoorioChain is, for now, a better queue in front of a conservative consensus — measured, and honest about being exactly that.
Based on MEMPOOL_DAG_ORDERING.md.