Reduce onboarding gas & align value accrual by removing batch balancer and replacing it with a per-sector fee

[irenegia]

Context and Motivation

In the ongoing effort to reduce per-sector onboarding gas costs (see #1092), we have identified the following active work streams:

• Supporting the DDO Pipeline: For example, adding DDO deal tracking capabilities to Spark.

• Storage Gas Optimizations and Miner Configuration Improvements: Tracking this work here;

• Enabling Full Adoption of Batching and Aggregation to Scale Onboarding Growth: This involves ensuring that batching for precommit and batching/aggregation for provecommit are always rational (ie, cost-effective for SPs).

This new discussion focuses specifically on the third point—making batching and aggregation pipelines cost-effective while aligning network value accrual with onboarding growth. Currently, the cost-effectiveness of these pipelines is governed by the BatchBalancer mechanism, which is tied to the base fee. In the sections below, we provide an overview of the current system, highlight its limitations, and propose a practical solution to address these challenges and enable fast progress. This proposal builds on previous work done by CryptoNet (see here and #587).

Filecoin's current fee structure consists of two main components:

• Gas Fees: As in other blockchains, gas fees mediate access to limited blockchain execution capacity. These fees are burned, generating network revenue proportional to the execution resources used.

• Batch Balancer Mechanism: Beyond blockchain execution, the Filecoin network provides a storage-auditing service to SPs through the proofs of storage verified on-chain. Historically, before proof aggregation, each proof verified a single unit of storage (sector), meaning gas fees captured the value of the storage auditing service. However, the introduction of proof aggregation (where one proof audits multiple sectors) disrupted this alignment. The batch balancer was introduced to address this misalignment but has become outdated, and, as recent work on gas onboarding optimization (Onboarding rate and gas optimizations #1092) highlights, it now acts as a bottleneck to fully adopting aggregation and batching.

Problem Statement: Gas fees – a system primarily intended to charge for execution resources – alone do not properly capture network value for Filecoin, negatively impacting the overall Filecoin economy. Filecoin value accrual via fees should grow proportionally to network adoption and demand, and be resilient to technical optimizations that reduce gas fees and increase chain bandwidth. While the batch balancer mechanism tried to solve this, at the same time it creates these inefficiencies:

• It discourages full adoption of batching and aggregation by making these operations less rational (cost-effective). Batching and aggregation improves the overall efficiency of Filecoin, and increases the onboarding capacity of the network.

• It couples gas fees with storage auditing in a way that limits predictability and increases exposure to base fee volatility. Gas fee pricing is designed to prevent the network from overusing execution resources; it should not be so directly tied to onboarding levels.

• It poses challenges for aligning technological improvements (such as optimizations that reduce gas congestion) with economic incentives (value accrual alignment with network growth).

Proposal and Effects

To address these issues, we propose removing the batch balancer mechanism and replacing its value accrual effect with a per-sector fee, separate from gas fees. This change has multiple benefits:

1. Rational Batching and Aggregation
   • With batching (for precommit) and aggregation (for provecommit) fully adopted, we expect a 30% reduction in per-sector onboarding gas.
   • Lower onboarding gas increases the network’s onboarding rate capacity, allowing Filecoin to surpass the current ~3PiB/day rate without elevating base fee.
2. Improved Predictability and User Experience
   • By separating gas fees (blockspace costs) from service fees (onboarding costs), we create a resilient system less prone to base fee spikes, offering predictable and fair costs to SPs.
   • The network can guarantee a smoother user experience, with clear boundaries between congestion control (via base fees) and the payment of costs of other additional services unrelated to congestion.
3. Alignment with Long-Term Network Economics
   • Burning a per sector fee, the network is able to properly capture value for the storage auditing service (ie, proportionally to the storage demand).
   • Future optimizations in proofs or onboarding throughput will no longer risk destabilizing the network’s economic alignment. This ensures the Filecoin protocol can continue to reduce costs for SPs while capturing value for the network.

Fee Design Principles

The fee should accord with the following design goals:

1. Simplify the system to improve predictability
   • Introducing a per-sector fee should help reduce the likelihood of network shocks caused by unpredictable base fee volatility.
   • Service Providers should be able to reason about future fees, rewards, and ROI.
   • A simpler system is easier to maintain, requiring fewer manual updates.
2. Increase & Align Network Value Accrual
   • As demand for Filecoin storage increases, cumulative fees burnt should grow proportionally, reflecting the added value to the ecosystem.
   • Service fees should prevent the long-term decline of burn fees, ensuring economic sustainability as gas fees per sector decrease with technological advancements.
   • Burn fees reduce the supply of FIL permanently, equally distributing the value accrued by the network to FIL holders and earners.
3. Avoiding More Onboarding Rate Limits
   • The fee should not introduce new bottlenecks that constrain the network’s ability to onboard data.
4. Fast Alignment + Delivery
   • Unblocking network onboarding rate and gas fee predictability require quick improvements to unlock network growth.
   • Therefore the network needs a simple, reasonable, and effective solution that can be aligned on and implemented quickly to fit into the next network upgrade.
   • Take a launch-observe-iterate approach to landing simple improvements now, and be able to improve with more data-driven iterations in the future.

Proposal Directions

We are exploring two high-level fee models:

1. Flat per-sector fee. For example,: each sector burns 1% of the corresponding expected block rewards or pledge collateral. This simple model offers predictability and consistency.
2. Dynamic per-sector fee: Eg: the fee updates daily based on the delta in Quality Adjusted Power (QAP) from the previous day. This approach adjusts fees dynamically to align with storage demand trends such that a network growing faster charges higher fees. This more closely aligns network value accrual, but at the expense of simplicity and predictability.

We are evaluating variations of these models that tie fees to broader economic indicators, such as circulating and total token supply. Proposals are being evaluated based on how well they achieve the Fee Design Principles above.

Conclusion

This proposal introduces a more predictable and rational fee structure that replaces the batch balancer with a per-sector fee, providing Storage Providers with a cost structure that is more stable and easier to plan around. By decoupling gas fees from service fees, this should better capture network value, encourage technological innovation and optimization, and ensure the long-term economic sustainability of the Filecoin network.

Please give your initial thoughts and questions; this is a work in progress, and your feedback will help ensure this approach benefits all parts of the Filecoin ecosystem.

[mjroddy]

Thanks @irenegia agree on this

Just on 2 - dynamic pricing.

I'm not sure on the merits of this approach. I don't think we should be disincentivising onboarding via a higher fee unless there are constraints (like with gas fees). If Filecoin found rapid traction what would be the benefit of increasing the fee at the expense of possibly slowing that down?

Adjusting down in periods of declining growth I could understand but this also happens naturally with more of the simple rewards being distributed amongst the lower QAP.