The primary goal of this proposal is the removal of the Batch Balancer mechanism from sector onboarding to facilitate an increase in effective Filecoin network bandwidth, while preserving network burn.

The secondary goal is to reduce the reliance of Filecoin’s network burn on the price of gas used by Storage Providers.

A significant percentage of block capacity is not utilized due to the batch balancer mechanism, which penalises proof aggregation.

This leads to artificially increased cost of gas through the BaseFee mechanism but guarantees a certain level of burn associated with onboarding. The reliance of this burn rate on gas price influences the design and execution of the protocol, where significant gas optimizations and reductions are seen as inherently risky due to the possibility of upsetting the balance of the new token supply and network burn. The batch balancer also increases the sensitivity of onboarding costs to chain congestion above that already inherent in the gas price.

This proposal aims to reduce the dependency on BaseFee by decoupling the on-chain costs of onboarding from the gas price, specifying an explicit pricing policy instead. Onboarding is not a scarce resource like chain throughput, and the EIP-1559 mechanism is not an appropriate pricing mechanism. This decoupling allows for the removal of the batch balancer and supports continued optimization of the network’s execution layer, with better-aligned incentives for token holders, Storage Providers and data users.

The Filecoin network’s primary objective is to provide reliable, verifiable data storage. This feature differentiates Filecoin from other crypto networks, and it is the source of its utility. This proposal reigns in fees that Filecoin charges, such that they are directly proportional to the utility Filecoin provides to Storage Providers and clients.

We propose the introduction of two fees: Capacity Fee and Data Fee. We aim for these fees to maintain the total on-chain cost of onboarding storage at current levels, while the removal of the batch balancer should relieve the pressure of the BaseFee and allow for continued protocol improvements and gas optimizations, which will provide additional benefits in enabling Storage Providers to onboard more data with lesser overall cost.

The batch balancer was introduced to equalize the playing field for small and large storage providers in the presence of proof aggregation, which can provide very significant reductions in costs. It also plays a stabilising role in the Base Fee system but has an outsized influence towards increasing the Base Fee.

The batch balancer has the following characteristics, some of which were part of its design goals, and others are externalities of how it functions.

Out of these characteristics, we choose to focus on preserving linear cost and network burn.

The Capacity Fee is charged per byte of capacity onboarded and involves a proportional burn, but without reference to the gas base fee.

We propose setting the value of the capacity fee based on the block reward and the rate at which the network is growing. The block reward becomes an anchor, which provides a reference level while the network doesn’t grow or shrink. When the network increases in size, the fee increases with the per-annum growth of the network. The opposite is also true; the fee decreases while the network shrinks.

We can define the Capacity Fee more precisely as the anchor value equal to X days of the block reward, with a multiplier depending on the net network growth in a range of 0.2 to 5x. The multiplier should also take a value of 1x when the amount of storage in the network is stable.

Sigmoid function in combination with base five exponentiation (to achieve multipliers in the range of 5^-1 and 5) are clear choices for achieving these goals. (5 is placeholder parameter).

There are multiple possible schemes for deciding the value of the Capacity Fee. As there is no direct scarcity in relation to onboarding (the management of the scarcity of chain space is delegated to the Base Fee system), thus auction mechanisms are not directly applicable to Capacity Fee.

Static Fee

The simplest possible design of such a system is a static fee, independent of onboarding metrics of the network set to some reference value. Filecoin token-denominated reference values are problematic in the long term as conditions in the network change. These references, further called anchors, should be tied to Filecoin’s economic condition.

We are aware of two good anchors for use in such a scheme: expected block reward and circulating supply. Both of these are related to cryptoeconomic conditions in the Filecoin network, but they differ in their action and predictability. The expected block reward is directly related to Filecoin’s inflation rate, while the circulating supply is integral over the inflation rate minus the lockup rate. The Expected Block Reward almost certainly is a much more predictable metric, and unless circulating supply anchor can provide significant benefits in the long term, it looks like the preferred metric to be used.

One possible formulation for Capacity Fee is block rewards of a sector for the time period T or x percentage of block rewards from a total expected lifetime of the sector.

Dynamic Fee

The major difference between a static fee and a dynamic fee is that a dynamic fee introduces control system mechanics into the fee scheme. The fee depends on the change in network size. When the network grows rapidly, the fees are higher, and while the storage in the network grows slowly or is reducing, the fees reduce with it.

The simple mechanism to achieve that objective is to allow fees to swing by some multiplier [M_min, M_max] away from the anchor, depending on the network conditions. When the network size does not change, the function chosen for the multiplier should output one.

The best-suited metric for such a fee scheme is the delta of network size over a longer period with smoothing. The initial suggestion is Exponential Moving Average with a time constant of five days.

The proposed scheme for Dynamic Fee should have a stabilising effect on onboarding while avoiding common pitfalls of control mechanisms due to its simplicity and ease of analysis.

The Data Fee is applied when data is put into a sector. This can be during initial sector onboarding or later via SnapDeals. In the future, when SnapDeals can be repeated, it should be applied to instances of data changing in the sector.

The aim of the Data Fee is to maintain a minimal number of empty sectors in the network in cases of very high storage utilization. We define storage utilization as the fraction of storage containing data.

When utilization reaches very high levels, a congestion scenario arises, where sectors and storage are a limited resource. In this case, the network can mediate the best usage of the remaining free storage by requiring a baseline payment for storing data.

Our design goal for Data Fee is for it to be insignificant during periods of low-to-medium storage utilization but to get higher as the utilization approaches 100%.

The selection of value for Data Fee, follows the same principles as the Onboarding Fee. The mechanism should be as simple as possible while performing its function.

An example of a function that roughly fits the design characteristics of the Data Fee multiplier function is f(utilization) = 1 / (1 - utilization^2) - 1, where the Data Fee multiplier is less than 1 up until utilization is greater than 70%.

In the current state of utilization level at around 5%, the Data Fee will be an insignificant cost to a Storage Provider onboarding data.

There are multiple other designs and aspects of a system like this that could be considered for introduction. Among them are:

Gas Credits - a percentage of gas used for proof verification is credited towards the fees.

Discount Schemes where during periods of high network utilization, the Data Fee substitutes the Capacity Fee, encouraging onboarding of more sectors.

Fee Pools where fees are paid into a pool that the network can use to stimulate growth in periods of

Previous discussions:

CEL notes: