Transaction Table with Fee Density Analysis
The table below lists all 20 mempool transactions with their calculated fee-per-unit ratios. Sorted by fee density (highest first) to guide optimal selection.
| TX ID | Fee (ETH) | Size (units) | Fee Density (ETH/unit) | Density Tier | Last Digit |
|---|---|---|---|---|---|
| tx_001 | 0.08 | 1 | 0.080 | High | 1 |
| tx_003 | 0.15 | 2 | 0.075 | High | 3 |
| tx_007 | 0.21 | 3 | 0.070 | High | 7 |
| tx_012 | 0.12 | 2 | 0.060 | High | 2 |
| tx_005 | 0.10 | 2 | 0.050 | Medium | 5 |
| tx_016 | 0.24 | 5 | 0.048 | Medium | 6 |
| tx_009 | 0.18 | 4 | 0.045 | Medium | 9 |
| tx_002 | 0.08 | 2 | 0.040 | Medium | 2 |
| tx_011 | 0.08 | 2 | 0.040 | Medium | 1 |
| tx_019 | 0.16 | 4 | 0.040 | Medium | 9 |
| tx_014 | 0.28 | 7 | 0.040 | Medium | 4 |
| tx_006 | 0.09 | 3 | 0.030 | Low | 6 |
| tx_013 | 0.09 | 3 | 0.030 | Low | 3 |
| tx_008 | 0.08 | 3 | 0.027 | Low | 8 |
| tx_018 | 0.10 | 4 | 0.025 | Low | 8 |
| tx_004 | 0.06 | 3 | 0.020 | Low | 4 |
| tx_010 | 0.10 | 6 | 0.017 | Low | 0 |
| tx_015 | 0.10 | 6 | 0.017 | Low | 5 |
| tx_017 | 0.07 | 5 | 0.014 | Low | 7 |
| tx_020 | 0.04 | 3 | 0.013 | Low | 0 |
Rows highlighted in green are the five optimal transactions for the winning block. Full analysis below.
Optimal Block Solution
Optimal Transaction Selection (Greedy by Fee Density)
The optimal strategy takes the highest-density transactions until the block is full. Starting from the top of the fee-density-sorted list:
- tx_001 — Fee: 0.08, Size: 1 — Running total: 1/10 units
- tx_003 — Fee: 0.15, Size: 2 — Running total: 3/10 units
- tx_007 — Fee: 0.21, Size: 3 — Running total: 6/10 units
- tx_012 — Fee: 0.12, Size: 2 — Running total: 8/10 units
- tx_005 — Fee: 0.10, Size: 2 — Running total: 10/10 units
Optimal Block Results
Block Hash Calculation
Using the simplified hash formula (sum of last digits of selected TX IDs):
- tx_001 → last digit:
1 - tx_003 → last digit:
3 - tx_005 → last digit:
5 - tx_007 → last digit:
7 - tx_012 → last digit:
2
Block Hash = 1 + 3 + 5 + 7 + 2 = 18
Strategy Analysis & Discussion Points
Teams may arrive at 0.66 ETH via different paths. All paths totalling 0.66 ETH with a valid block are equally correct. The key insight is the fee-density heuristic.
Strategy 1: Pure Fee Sorting (Suboptimal)
Some teams will sort by raw fee alone, picking tx_014 (0.28 ETH, 7 units) first. This fills 7/10 units and leaves only room for tx_001 (0.08, 1 unit) and tx_003 (0.15, 2 units) = 0.51 ETH total. Significantly worse than optimal because tx_014 has poor density.
Strategy 2: Fee Density Greedy (Optimal)
Sort by fee/size ratio. Take highest-density transactions first until block is full. Results in 0.66 ETH as shown above. This is the correct economic approach — exactly what real miners/validators do.
Strategy 3: Exhaustive Search (Also Optimal, Slower)
Some teams may try all combinations. While impractical for large mempools, for 20 transactions it can work. They should arrive at the same 0.66 ETH result. Accept this approach — reward thoroughness. Note that real blockchains cannot do this due to time constraints.
Near-Optimal Alternative Block (0.64 ETH)
Replacing tx_005 with tx_002 + tx_011 (both size 2, fee 0.08 each = 0.16 total for 4 units) while dropping tx_012 gives: tx_001 + tx_003 + tx_007 + tx_002 + tx_011 = 0.08+0.15+0.21+0.08+0.08 = 0.60 ETH for 10 units. Still valid but suboptimal. Accept with note about density calculation.
Key Economic Concepts to Discuss
Learning Outcomes Verification
After the activity, students should be able to articulate:
- Fee density (ETH/unit) is the correct optimization metric, not raw fee. A 0.24 ETH transaction taking 5 units (density 0.048) is worse than a 0.10 ETH transaction taking 2 units (density 0.050).
- This is the Knapsack Problem — a classic NP-hard optimization. For small instances (20 txs), greedy works. For real mempools (thousands of txs), miners use heuristics.
- Opportunity cost is real — including tx_014 (large, moderate density) prevents including several high-density small transactions.
- Real miners face these exact trade-offs — Bitcoin and Ethereum nodes order transactions by fee-per-byte (satoshis/byte or gwei/gas).
- The hash function connects blocks — even the simplified sum-of-digits exercise illustrates how transaction selection affects the block identifier.
Common Student Errors
- Sorting by fee alone, ignoring size: Leads to including large low-density transactions (especially tx_014 at 7 units) that crowd out better options. Typical result is 0.51-0.55 ETH instead of 0.66 ETH.
- Arithmetic errors in fee totals: Have teams double-check by re-adding selected fees. Common errors involve tx_012 (0.12, not 0.10).
- Exceeding 10-unit block size: Teams eager to maximize fees sometimes forget to track running size. Blocks over 10 units are invalid — zero points for winning criterion.
- Hash calculation with wrong last digits: tx_012's last digit is 2 (not 1 or 12). Clarify that "last digit" means the final single digit of the number only.
- Confusing fee density with fee-per-transaction: Fee density requires dividing by size. Students new to optimization sometimes compute fee/fee instead.
- Not verifying another team's block: The cross-team verification step mirrors real blockchain validation. Emphasize that every node independently verifies every block.
Grading Guidance
| Outcome | Total Fees | Assessment |
|---|---|---|
| Optimal block | 0.66 ETH | Full credit — wins competition |
| Near-optimal (density-aware) | 0.60-0.65 ETH | Strong — shows correct strategy |
| Good attempt (fee-sorted) | 0.50-0.59 ETH | Partial — fee sorting without density |
| Invalid block (oversized) | Any | No points for winning criterion — block fails verification |
Grading Note: Reward correct reasoning even if arithmetic is slightly off. A team that correctly identifies the fee-density heuristic but miscalculates by 0.01 ETH demonstrates full understanding of the economic concept.
© Joerg Osterrieder 2025-2026. All rights reserved.