Introduction
What if high performance blockchain like Solana’s fee model could automatically adjust not just for compute usage, but also for memory, network bandwidth, and I/O? In high-throughput environments, multiple resource bottlenecks can emerge—yet traditional one-dimensional fee mechanisms rarely capture this reality.
In Part 1 of our series, we explored how a dynamic base-fee on Solana (inspired by Ethereum’s EIP-1559) could help:
- Prevent spam by raising fees under high load,
- Keep fees low when utilization is modest, and
- Charge transactions proportionally to their “compute unit” usage.
But compute units aren’t the only bottleneck. Modern blockchain nodes can also saturate memory, network bandwidth, or disk I/O. Let me introduce you to Dominant Resource Fairness (DRF). Borrowed from HPC and data-center scheduling, DRF is a multi-dimensional fairness mechanism that recognizes how each job (or transaction) can stress multiple resources. By aligning Solana’s dynamic fees with DRF principles—envy-freeness, strategy-proofness, and Pareto efficiency—we can ensure that:
- Heavy memory users pay a premium if memory is scarce,
- Network-intensive transactions pay more if network bandwidth is the true bottleneck,
- No single dimension becomes a hidden choke point where cheap spam can flood the system.
This article explores why and how to extend Solana’s dynamic fee model to handle all major resource types. We’ll show how DRF’s “dominant resource” approach—max-min fairness (MMF) generalized to multiple resources—can naturally merge with the EIP-1559-like fee updates discussed in Part 1. The result is a multi-resource mechanism that scales with real-world constraints and automatically prices each transaction based on its actual burden on the network.
So if you’re curious about the next leap in blockchain fee mechanism—beyond simple CUs—read on. We’ll lay out the theoretical foundations from the DRF paper (SIGCOMM 2011), the practical challenges in a blockchain environment, and the benefits of bringing multi-dimensional fairness to unstoppable throughput.
Motivation: DRF for Multi-Resource Blockchain Fees
Solana (and similar high-performance blockchains) must handle multiple bottlenecks—CPU, memory, network, I/O—rather than merely “compute units” (CUs). A multi-resource dynamic fee model needs to:
- Charge each transaction proportionally to the resources it consumes,
- Adjust fees under congestion across all resource dimensions,
- Prevent manipulation: Users should not benefit by lying about resource needs,
- Stay robust in adversarial or spiky demands.
These challenges mirror multi-resource scheduling in cluster-computing environments. Dominant Resource Fairness (DRF), introduced by Ghodsi et al. in their SIGCOMM 2011 paper, offers a well-studied solution to multi-resource allocation:
- DRF generalizes max-min fairness (MMF) to multiple resource types.
- Each user’s “dominant share” is the fraction of their usage along whichever resource dimension is the highest fraction of that resource’s capacity.
- DRF aims to equalize these dominant shares across users, thereby satisfying an elegant list of fairness properties (strategy-proofness, envy-freeness, Pareto efficiency, bottleneck fairness, etc.).
While DRF was originally developed for cluster-scheduling tasks, it naturally extends to blockchains if we treat each user (or flow of transactions) as a “job” that demands some resource vector. We can then adapt DRF’s central insights into a fee mechanism that automatically prices multi-dimensional usage, aligning well with the EIP-1559-like dynamic base-fee updates already discussed for Solana.
Recap: Important DRF Properties and Theorems
To appreciate how DRF can inform a blockchain fee market, it helps to restate its core theorems. All references are to Ghodsi et al., SIGCOMM 2011, plus the Appendix in the same paper.
-
Dominant Share for user $i$:
\(s_i \;=\; \max_{r \in \mathcal{R}} \Bigl(\tfrac{d_i^{(r)}}{B^{(r)}}\Bigr),\)where $d_i^{(r)}$ is user $i$’s usage of resource $r$ and $B^{(r)}$ is the total capacity of resource $r$.
-
Progressive Filling Algorithm: Intuitively, DRF keeps “filling” allocations proportionally to each user’s demand vector until at least one resource saturates for that user. This ensures no user can increase her “dominant share” without decreasing someone else’s share.
-
Important Theorems (in the idealized continuous scenario with strictly positive demands):
- Theorem 9: DRF is Pareto efficient (no user can increase her share without reducing someone else’s).
- Theorem 10: DRF satisfies the sharing incentive and bottleneck fairness.
- Theorem 11: Every DRF allocation is envy-free (no user would prefer another user’s allocation).
- Theorem 12: DRF is strategy-proof under homogeneous resource pools, so lying about your demands does not yield a higher dominant share.
- Theorem 14: DRF satisfies population monotonicity when demands are strictly positive (though resource monotonicity is sacrificed).
These theorems collectively show that DRF is an appealing mechanism in multi-resource environments, ensuring fairness and mitigating manipulations like demand inflation.
Adapting DRF to a Blockchain Fee Market
Users, Transactions, and Resource Vectors
Where DRF typically treats each “user” as a job or queue of tasks, we can analogize each address (or priority fee-payer) on Solana to a “user” whose transactions together request a vector of resources: \(\mathbf{d}_i = \bigl( d_i^{(\text{CPU})},\, d_i^{(\text{Memory})},\, d_i^{(\text{Network})},\dots \bigr).\)
In practice, each transaction $\tau$ from user $i$ might have its own resource vector $\mathbf{u}(\tau)$. Summing up or averaging over all transactions from $i$ in a block yields a block-level request $\mathbf{d}_i$. If the chain tries to “fairly” accommodate all user demands for the next block, we can apply DRF ideas at block boundaries.
Fee Computation: Dominant-Share–Based Pricing
In DRF, each user ends up with an allocation that equalizes the “dominant resource fraction.” In a blockchain fee context, we can invert this logic:
- If user $i$’s dominant resource fraction is high (i.e., they claim a large fraction of some bottleneck resource), the protocol can charge a higher price.
- Conversely, if user $i$ uses minimal amounts of each resource, their total cost is lower.
This suggests a dynamic base-fee multiplier that penalizes large dominant shares. For instance, the cost of user $i$’s transactions might be:
\[\text{Cost}(i) \;=\; M \times \max_{r}\Bigl\{ w^{(r)}\,d_i^{(r)}\Bigr\} + \text{tip}(i),\]where $w^{(r)}$ are resource weights, and $M$ is the global scaling factor that rises or falls with overall system load. This is essentially an adaptation of DRF’s “dominant resource” principle into a pricing model.
Dynamic Updates (Block to Block)
As in EIP-1559, we want to automatically adjust $M$ every block so that total usage hovers near a target threshold. The single-resource EIP-1559 uses $\exp[\alpha(\phi_n - \phi^*)]$, but here $\phi_n$ must reflect the multi-resource load. DRF suggests we look at each user’s “dominant fraction” to see if the block is saturating any resource dimension:
- If the block is near capacity in at least one resource, raise $M$.
- If resources are underutilized, lower $M$.
One possibility is to define a function \(\phi_n = \max_{r\in\mathcal{R}} \Bigl(\tfrac{u_n^{(r)}}{B^{(r)}}\Bigr),\) as in the “dominant resource usage fraction.” Then we do: \(M_{n+1} = M_n \times \exp\!\bigl(\alpha\,[\phi_n - \phi^*]\bigr).\) This ensures the fee goes up whenever any resource is heavily used, consistent with DRF’s notion that saturating even one dimension constitutes a system bottleneck.
Strategy-Proofness Concerns
A hallmark of DRF is that users cannot gain by demanding resources they do not need. In a blockchain, “lying” about resource usage could mean artificially inflating (or deflating) the CPU/memory usage fields in a transaction to manipulate fees. DRF’s Theorem 12 states that if resources are drawn from a single homogeneous pool, it is strategy-proof for every user to declare real demands.
- Blockchain Relevance: We must instrument validators to measure actual usage (CPU cycles, memory bytes, network overhead) rather than trust self-reported demands. With robust measurement, the user has no direct way to lie, thereby inheriting strategy-proofness.
- Discrete Tasks & Fragmentation: Real transactions are often all-or-nothing (a transaction either fits in a block or not). DRF strategy-proofness still largely holds if the usage is measured ex post by the runtime, but discrete capacity can cause “fragmentation” issues (Section 6.2 in the DRF paper).
Envy-Freeness and Bottleneck Fairness
- Envy-Freeness: If user $i$’s dominant share is equalized with user $j$, then $i$ cannot prefer $j$’s resource usage because that would push $i$’s dominant fraction up (and lead to higher fees). Translating envy-freeness to a fee system suggests that no user would prefer to pay the cost of another user’s usage bundle.
- Bottleneck Fairness: DRF ensures that if one resource is the bottleneck for a user, everyone else also sees at least the same fraction of their personal bottleneck. In a blockchain, this would ensure that no single user’s resource usage “unfairly” dominates a dimension relative to others, unless they also pay proportionately higher fees.
Deeper Formalization: Merging DRF with Dynamic Fees
Let us sketch a more formal version of the block-level DRF-based fee mechanism:
- Users & Demand Vectors:
- In block $n$, we have $N_n$ active users (addresses) ${1,\dots,N_n}$.
- User $i$ proposes a set of transactions whose combined resource demand is $\mathbf{d}_{i,n}$.
- We measure $\mathbf{d}_{i,n}$ via actual runtime metrics.
- Capacities:
- Each resource $r\in\mathcal{R}$ has a block capacity $B^{(r)}$. For block $n$, we do not exceed $B^{(r)}$ in resource usage.
- Dominant Share:
- For user $i$, define \(s_{i,n} \;=\; \max_{r\in\mathcal{R}} \bigl(\tfrac{d_{i,n}^{(r)}}{B^{(r)}}\bigr).\)
- The system tries to “allocate” each user up to a certain share so that all $s_{i,n}$ are as balanced as possible.
- Pricing:
- Let $M_n$ be the base-fee multiplier.
- Each user $i$ pays:
\(\text{Cost}(i,n) \;=\; M_n \times s_{i,n} \;\; +\; \text{tips},\) or equivalently $M_n \cdot \max_{r} {w^{(r)}\,d_{i,n}^{(r)}}$ if we incorporate weighting. (One can also interpret $s_{i,n}$ as a dimensionless fraction and scale it by each resource’s “cost” if needed.)
- Fee Update:
- After the block completes, measure total usage $u_n = \sum_i d_{i,n}$.
- Define $\phi_n = \max_{r} (u_n^{(r)}/B^{(r)})$.
- Update \(M_{n+1} = M_n \times \exp\![\alpha\,(\phi_n-\phi^*)].\)
- This ensures the base fee rises or falls in response to the “dominant resource usage fraction” of the block as a whole, maintaining system load near $\phi^*$.
Pros and Cons of This Hybrid Approach
- Pros:
- Aligns with DRF: Big resource hogs pay more, and there is a built-in fairness.
- Inherits strategy-proofness (assuming usage is measured accurately).
- Scales with block-level usage automatically.
- Envy-Freeness and bottleneck fairness can carry over at the “user” level.
- Cons:
- Implementation complexity: we must measure real resource usage $\mathbf{d}_{i,n}$.
- DRF in discrete settings can lead to “fragmentation” or partial usage of a dimension.
- Tension with local fee markets: Solana also has local hotspots (e.g., specific accounts or programs). Merging local bidding with DRF-based global pricing is non-trivial.
Handling Discrete Tasks, Fragmentation, and Placement Constraints
The Future Work (Section 9.1) of the DRF paper points out several directions that also look relevant in blockchain contexts:
- Minimizing Fragmentation:
- Blockchains have discrete “slots” for transactions. If partial resource usage of a dimension is leftover, but no single transaction can fit in it, that capacity is effectively wasted. This is akin to bin-packing or scheduling tasks on discrete machines.
- The DRF solution for continuous resources has strong fairness properties but does not necessarily minimize fragmentation. Similarly, letting “small” transactions slip in might or might not always raise overall fairness.
- Placement Constraints:
- In cluster scheduling, certain tasks require specific machines. In blockchains, we might have constraints that a transaction must read/write particular on-chain states or run on a certain set of validators that have the required account data cached.
- DRF with constraints can lose some of its simpler proofs of strategy-proofness. The user might concentrate demands on certain “preferred” partitions of the resource.
- OS-Level DRF:
- The DRF paper suggests applying DRF within a multi-core OS as a scheduling policy. By analogy, a blockchain runtime environment (e.g., Solana runtime on each validator) could adopt DRF-like scheduling for transaction execution. This is more granular than simply assigning “CUs,” but it might lead to better multi-core utilization and real concurrency fairness.
- Microeconomic Perspective:
- DRF is not the only multi-resource fairness approach. For example, Competitive Equilibrium from Equal Incomes (CEEI) is envy-free and Pareto efficient but not strategy-proof.
- A deeper question: “Is DRF the unique strategy-proof mechanism under the other fairness properties?” The paper posits investigating whether DRF is the only possibility that satisfies all these constraints for multi-resource allocations. For blockchains, this raises future directions: perhaps alternative multi-resource fee mechanisms exist but break strategy-proofness or envy-freeness.
Validator Manipulations & Multi-Resource Measurement: Two Important Questions
A multi-resource fee system can be highly robust against validator manipulation and fair to all users—but it demands careful design around resource tracking and honest measurement.
Can Validators Adjust Their Usage Patterns to Minimize Fees?
Short Answer: While validators might try reorganizing transactions or splitting them in clever ways, a well-designed multi-resource fee framework (inspired by DRF) limits the advantages of such manipulation—especially if resource usage is measured accurately and aggregated properly.
Adjusting Personal Transactions
Validators who submit their own transactions may attempt to split large, resource-heavy transactions into multiple smaller ones to reduce the “dominant resource” cost. However, DRF’s strategy-proofness (assuming accurate resource measurement) ensures that artificially gaming the system usually provides little or no net benefit. Splitting transactions often merely redistributes resource usage, but doesn’t fundamentally lower total fees if the protocol sums usage across all transactions within a block.
Favoring Certain Transactions in Block Production
A validator might omit or reorder user transactions to keep next-block fees lower. However, the next block’s fee also depends on global usage and other validators’ choices. Moreover, dropping transactions means forfeiting potential tip revenue, which typically disincentivizes such manipulations.
How Difficult Is It to Measure Multi-Resource Utilization Accurately?
Short Answer: Measuring CPU, memory, network, and I/O usage per transaction is non-trivial, especially in a Byzantine environment. It requires robust instrumentation, potential cross-validator checks, or trusted hardware to ensure honest reporting.
Instrumentation Complexity
- CPU usage is relatively straightforward (e.g., compute units).
- Memory usage attribution can be tricky in a parallel execution environment.
- I/O tracking requires detailed logging of reads/writes at runtime.
- Network usage can be especially challenging to track if multiple nodes handle partial data.
Possible Approaches
- Runtime-Based Instrumentation: Validators monitor resource consumption in near-real time and record usage per transaction.
- Trusted Hardware (TEE): Secure enclaves or other TEE solutions can provide tamper-proof usage metrics.
- Cross-Validator Verification: Multiple validators re-check usage data for consistency, detecting any anomalies. This may additionally require some incentive mechanism to incentivize validators to report accurately.
Risk of Manipulation
If a validator can unilaterally misreport its own transactions’ usage, it could underpay fees. Mitigations include strict runtime checks (to minimize manual reporting) or proof-of-measurement schemes.
Balancing Overhead & Fairness
Accurate tracking of each resource adds implementation complexity and runtime overhead, but the benefit is true multi-dimensional fairness—charging transactions for the resources they actually consume, not just for “compute.”
Conclusion & Research Directions
By adopting Dominant Resource Fairness ideas, a multi-resource fee model on Solana can potentially achieve strong fairness and spam deterrence across CPU, memory, I/O, and network usage. DRF’s proven properties—strategy-proofness, envy-freeness, bottleneck fairness, Pareto efficiency—give it a theoretical foundation that purely one-dimensional or ad hoc pricing methods often lack.
Summary of the DRF-Enhanced Model
- Measure each transaction’s usage in multiple resource dimensions.
- Aggregate usage per user (or per priority fee-payer).
- Compute each user’s dominant fraction.
- Charge that user according to a function of their dominant fraction and a global base-fee multiplier $M_n$.
- Update $M_n$ from block to block based on the maximum resource utilization in the previous block.
This ensures that if any resource dimension is near capacity, the entire system’s fees rise automatically, encouraging users to reduce consumption or spread out their usage.
Open Research Problems
- Discrete “Tasks”: Just like big HPC clusters have discrete tasks, blockchains have discrete transactions. Minimizing fragmentation while preserving DRF fairness is akin to a multi-dimensional bin-packing problem with fairness constraints.
- Machine or Validator Constraints: Some transactions can only be processed by certain validators or must read certain states. This complicates uniform resource pooling.
- Local vs. Global Fees: Solana has local fee bidding for “hot” accounts. Combining local auctions with a global DRF-based dynamic fee floor is an open question.
- Implementation Overheads: Precisely measuring memory or network usage for each transaction can be expensive. We need robust instrumentation to preserve strategy-proofness (so no one can lie about usage).
- Microeconomic Uniqueness: Investigate whether DRF is indeed the only strategy-proof policy among multi-resource, fair, Pareto-efficient approaches for blockchains.
In summary, DRF offers a rigorous blueprint for fair, multi-dimensional resource allocation. Adapting it carefully to Solana’s dynamic fee structure would give strong theoretical guarantees that no user can “game” the system by misrepresenting resource needs, and that all major resources (CPU, memory, I/O, network) are priced in a balanced, bottleneck-aware manner. Although significant engineering details remain—especially around discrete transactions and validator constraints—the potential payoff is a robust, fair, and spam-resistant multi-resource fee market that can scale along with Solana’s parallel execution model.