From 2eb1f3879b7bd4a9914c54c21ca94b85ab360c7f Mon Sep 17 00:00:00 2001 From: irene <23217773+irenegia@users.noreply.github.com> Date: Tue, 4 Feb 2025 18:59:33 +0100 Subject: [PATCH 01/27] Create fip-removeBatchBalancer.md We are proposing a FIP for replacing the batch balance with a new per sector fee and be able to support more batching/aggregation. --- FIPS/fip-removeBatchBalancer.md | 164 ++++++++++++++++++++++++++++++++ 1 file changed, 164 insertions(+) create mode 100644 FIPS/fip-removeBatchBalancer.md diff --git a/FIPS/fip-removeBatchBalancer.md b/FIPS/fip-removeBatchBalancer.md new file mode 100644 index 00000000..1d3dcf07 --- /dev/null +++ b/FIPS/fip-removeBatchBalancer.md @@ -0,0 +1,164 @@ +--- +fip: "00XX" +title: Removing Batch Balancer, Replacing It With a Per-sector Fee and Removing Gas-limited Constraints +author: irene (@irenegia), AX (@AxCortesCubero), rvagg (@rvagg), molly (@momack2), kiran (@kkarrancsu) +Discussions-to: https://github.com/filecoin-project/FIPs/discussions/1092 and https://github.com/filecoin-project/FIPs/discussions/1105 +status: Draft +type: Technical +category: Core +Created: 2025-02-04 +--- + +# FIP-00XX: Removing Batch Balancer, Replacing It With a Per-sector Fee and Removing Gas-limited Constraints + + +## Simple Summary +This FIP proposes to: + - Remove the batch fee from all precommit and provecommit methods to incentivize sector batching during the precommit step and proof aggregation during the provecommit step; + - Introduce a per sector fee to replace the batch balancer cost structure with a more stable mechanism that supports the long-term economic sustainability of the Filecoin network; + - Remove protocol constraints that are no longer necessary since the introduction of proper gas accounting. + + +## Abstract +This FIP consists of three changes: + - First, a straightforward way to reduce gas consumption is through sector batching and proof aggregation. Storage providers (SPs) should be incentivized to batch sectors at precommit and aggregate proofs at prove commit as much as possible. Currently, the efficiency of these processes is governed by the batch balancer mechanism, which is tied to the base fee and comes with several limitations. This FIP proposes the removal of the batch balancer (see details below) to enable full adoption of batching and aggregation, thereby enhancing scalability and onboarding growth. + - Secondly, the batch balancer was introduced to address a misalignment in the Filecoin economy. Beyond blockchain execution, the Filecoin network provides SPs with a storage-auditing service through on-chain verification of proofs. While gas fees primarily account for execution costs, there is no dedicated system that properly captures the network’s storage-auditing value. The batch balancer partially addressed this gap, although attempted to achieve value capture through the gas mechanism which is primarily a means of constraining chain validation costs. With the removal of the batch balancer, a replacement mechanism is needed. This FIP proposes a better, more effective system to achieve that goal (see details below). + - Finally, this FIP also includes the removal of gas-limited protocol constraints which are no longer needed. However, these modifications are not the primary focus of the proposal. Eliminating these constraints aims to simplify the protocol, and remove any unintentional network growth constraints. + + +## Change Motivation + +### Precommit batch fee removed +Due to the batch fee, currently precommit batching is only rational (ie, cost-effective) when the base fee exceeds 0.09 nanoFIL. Removing this fee will eliminate this obstacle, enabling more batching and therefore gas saving. +To have a rough estimate of the saving, we can compare two PreCommitSector messages posted by the same miner actor with little difference in the number of sectors when the message landed. +- [Msg 1](https://www.filutils.com/en/message/bafy2bzacebzacw3b7ymcwukk2uimahiebpke65utbfn3srgslzj5w3hh234x6): PreCommiSectorBatch2 for 1 sector : 16.7 M gas used +- [Msg 2](https://www.filutils.com/en/message/bafy2bzacebdqgivdbxzj25exae55j7vjasos45lvj4bzi6fj5oaya4rqwxrf6): PreCommitSectorBatch2 for 4 sectors): 18.6 M/ 4 = 4.6 M per sector (3.6x smaller) + + +### Provecommit batch fee removed +There are two options for `ProveCommitSector3`: (1) "simple" batching as in precommit (ie, one message for ≥ 2 sectors) where there is a PoRep proof for each sector in the batched message, and (2) aggregating proofs of multiple sectors and post in one message. +Batching for provecommit is already rational, as the batch fee applies only to aggregated proofs (opposed to precommit, where the batch balancer applies to batching). +On the other hand, aggregation is rational only when the base fee exceeds 0.065 nanoFIL due to the batch fee applied to aggregation. Removing this fee too will eliminate this obstacle, enabling more proof aggregation and therefore gas saving. + +To have a rough estimate of the saving, we can compare these `ProveCommitSector3` messages posted by the same miner actor with little difference in the number of sectors when the message landed[^*]. +- [Msg 1](https://www.filutils.com/en/message/bafy2bzacebshpv7afwnxph6l4jnbpwpqnss3cboyfvlualfrjbox76hojjnlo): ProveCommitSectors3 for 1 sector: 267.5 M +- [Msg 2](https://www.filutils.com/en/message/bafy2bzacebd7ftq5lk4ikuif4j3xfwiabmla5bek3kuhn3k6x3obufxyzrs6y): ProveCommitSectors3 for 4 sectors, batched (no aggregation): 580 M/4 = 145 M per sector (1.85x smaller) +- [Msg 3](https://www.filutils.com/en/message/bafy2bzacedezi6lm4warrfq2n6dxvpokowzt5isacbq2kojkz462yfpfq7lxm): ProveCommitSectors3 for 4 sectors, aggregated: 517.4 M/4 = 129.3 M per sector (2x smaller) + +[^*]: A bug is currently causing single proofs to be charged an incorrect amount of gas units. So we added the missing units (42M per proof) to msg1 and msg2 in order to provide the future correct estimates (the bug is planned to be fixed in nv25). See [here](https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0076.md) + + +### Per-sector fee added +The batch balancer mechanism had several goals and effects. Among them, two key aspects were: (1) Creating a linear cost for onboarding storage in the presence of batching/aggregation and (2) Burning tokens to balance new token supply with network burn, ensuring value distribution among FIL holders and earners. +We propose a replacement mechanism that preserves these effects while adhering to the following design principles: + - Simplify the system to improve predictability. + - Preserve and align network value accrual. + - Avoid additional onboarding rate limits. + - Enable future optimizations in the network’s execution layer. + +**Proposal Details**: We introduce a per-sector fee, whose value is proportional to a fixed fraction of the circulating supply value at that moment and to the sector duration. To prevent this fee from becoming a significant upfront cost that could hinder onboarding, we propose daily payments instead of an upfront fee. Moreover, as a safety measure for the highly-optimistically network growth scenarios, we propose capping the daily payment at a fixed percentage of the 24h expected per-sector block reward. +More in details: at provecommit time we compute the value + + `dailyFee= k * CS(t)` + +Where `k= 7.4 E-15` is a system constant and `t` is the sector activation epoch. Then, the value + + `dailyPayment = min (dailyFee, m * 24hBR)` +is paid daily for each new sector onboarded after this FIP is deployed (`m= 0.5` is another system constant). + +Note that the daily payment is due everyday until sector expiration. In particular: +Even if a sector becomes faulty for the day, the payment is due. In other words, the dailyPayment is paid at windowPoSt time for all sectors in one the following state: active, faulty, recovered; +The total fee per sector over its full sector lifetime is: sectorFee = dailyPayment sectorDurationInDays. If a sector is terminated, the remaining of sectorFee gets computed and paid at termination (can be paid together with termination fee); +If a sector is extended, the dailyPayment is not changed and the sector will keep paying the same value for the extended lifetime. + + +### Gas-limited constraints + +Various protocol constraints that were previously necessary when there was no gas applied on actor computation are no longer necessary since the introduction of proper gas accounting with FVM (see [FIP-0032](./fip-0032.md)). This FIP proposes to remove the following constraints as they are no longer necessary in practice due to the gas mechanism being the primary constraint for computation: + +* `PRE_COMMIT_SECTOR_BATCH_MAX_SIZE`: The maximum number of sector pre-commitments in a single batch. +* `PROVE_REPLICA_UPDATES_MAX_SIZE`: The maximum number of sector replica updates in a single batch. +* `DECLARATIONS_MAX`: Maximum number of unique "declarations" in batch operations (i.e. terminations, faults, recoveries). + +In most cases, users will be limited by the gas limit rather than these constraints ([`message execution failed: exit SysErrOutOfGas`](https://github.com/filecoin-project/lotus/issues/10612)). Removing these constraints will simplify the protocol and remove any unintentional network growth constraints. + +## Specification +- Remove the burning `aggregate_fee` from `PreCommitSectorBatch2`. +- Remove the burning `aggregate_fee` from `ProveCommitAggregate`, `ProveCommitSectorsNI`, `ProveCommitSectors3` + +- TODO : add actor spec for the per sector fee + +- Remove the following gas-limited constraints: + - `PRE_COMMIT_SECTOR_BATCH_MAX_SIZE` + - `PROVE_REPLICA_UPDATES_MAX_SIZE` + - `DECLARATIONS_MAX` + +## Design Rationale +We aimed for a design that is simple to understand and model, and relatively simple to implement. With this in mind, we explored the following fee structures: + +- **Upfront Payment vs. Ongoing Payment**: The first offers better predictability, while the second reduces the risk of creating an entry barrier. With this FIP, we chose a hybrid approach that captures the benefits of both by computing the fee upfront for predictability, but allowing it to be paid daily over sector lifetime instead of as a lump sum upfront. + +- **Flat Fee vs. Dynamic Fee**: A fixed per-sector fee provides predictability and consistency, while a fluctuating fee based on network congestion, onboarding rate, or other variables better captures value when the network is actively providing a service. We chose a model where the fee is a fixed fraction of a quantity that adjusts to economic conditions. We evaluated the following economic indicators for determining the per-sector fee: Initial Pledge (IP), per-sector Block Reward (BR) and Circulating Supply (CS). + - The Initial Pledge was discarded to avoid complex system dependencies, as changes to IP in future FIPs could unintentionally impact the per-sector fee. + - The BR-based fee was discarded because the fee-to-reward ratio did not adjust properly to network growth, leading to high fees even when onboarding demand was low. See here for more details (TODO add link) + - CS was ultimately chosen because it normalizes fees relative to the Filecoin economy, ensuring both adaptability and predictability. + +We reached this conclusion through simulation-based analysis, modeling the impact of fees under different network conditions. Specifically, we evaluated multiple input trajectories—0.5×, 0.75×, 1×, and 2× the current onboarding, renewal, and FIL+ rates. Since both renewals and FIL+ are near 100%, we capped them at their current maximum. (See Fig. 1) + +
+ Screenshot +
+ + + + +For each trajectory, we analyzed the expected fee and related metrics over time. Fig. 2 presents these results for the CS-based fee, incorporating a daily cap at 50% of the per-sector block reward (BR). Notably, Fig. 2 confirms that the CS-based fee proposed in this FIP offers the following key advantages: +- **Stable Economic Reference**: A fixed percentage of CS functions like a fixed USD fee if market cap remains stable, keeping costs predictable; +- **Adapts to Market Conditions**: If Filecoin’s valuation rises, fees increase in FIL terms, scaling with the economy. If the market stagnates, fees stay economically consistent. + +![Screenshot 2025-02-04 at 18 53 21](https://github.com/user-attachments/assets/7be95ca1-d855-4c32-91c7-a8d48026e197) + + + + +## Backwards Compatibility +This FIP modifies actor behavior and will require a new Filecoin network version. + +## Test Cases +TODO + + +## Security Considerations +This FIP does not affect underlying proofs or protocol security. + +## Incentive Considerations + +Filecoin’s network revenue model is currently tied to the gas usage, and the most amount of gas is used by storage onboarding methods. This creates an incentive misalignment, where economic considerations lead to an incentive to not optimize the gas usage of onboarding methods, as this could hurt overall network revenue. + +The Batch Balancer mechanism exemplifies this concept: batching and aggregating abilities were introduced to increase gas efficiency of onboarding methods, but the batch balancer mechanism was put in place to essentially turn off these abilities at times of low demand, to protect Filecoin’s economic interests. + +This FIP fixes this incentive misalignment by disconnecting the network revenue from gas usage. The removal of the batch balancer, allows for aggregation to occur even at current levels of demand. We expect this to lead to a reduction of about ~30% in per-sector onboarding gas. This would in turn result in a drop in base fee, and therefore a drop in gas-based network revenue. + +The explicit per-sector fee introduced by this FIP allows us to remove the batch balancer, and allow any other future gas usage optimizations, without adding macroeconomic risk. + + + +## Product Considerations +From a product perspective, this FIP is expected to: +- Decouple gas fees (blockspace costs) from service fees (storage-auditing costs): This separation creates a more resilient system, reducing sensitivity to base fee spikes and ensuring predictable and fair costs for SPs. +- Simplify cost analysis and calculations for SPs: The network will provide a smoother user experience by clearly distinguishing between congestion control (managed via base fees) and payments for services unrelated to congestion. +- Capture value for the storage-auditing service: By introducing a per-sector fee burn, the network can proportionally capture value based on storage demand. +- Ensure economic stability amid future optimizations: Improvements in proof mechanisms or onboarding throughput will no longer risk destabilizing the network’s economic alignment. This ensures the Filecoin protocol can lower costs for SPs while still capturing value for the network. +- Remove gas-limited constraints: Eliminating these unnecessary constraints simplifies the protocol and allows gas mechanisms to serve as the primary network constraint, making the system more adaptive and flexible to changing conditions. + +## Implementation +builtin-actors PRs: +* Remove batch fee for precommit and lower BatchBalancer (TBD) +* Implement windowPoSt per sector fee (TBD) +* [Remove gas-limited constraints](https://github.com/filecoin-project/builtin-actors/pull/1586) + +## Copyright +Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). + + + From 83d62a4533e137814f4fb80f64232ce7278f4113 Mon Sep 17 00:00:00 2001 From: irene <23217773+irenegia@users.noreply.github.com> Date: Wed, 5 Feb 2025 14:51:31 +0100 Subject: [PATCH 02/27] Update README.md --- README.md | 1 + 1 file changed, 1 insertion(+) diff --git a/README.md b/README.md index 2201a0da..2ece4bc5 100644 --- a/README.md +++ b/README.md @@ -134,3 +134,4 @@ This improvement protocol helps achieve that objective for all members of the Fi | [0096](https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0096.md) | Convert fundraising remainder address(es) to keyless account actor(s) | FIP | @Fatman13 | Draft | | [0097](https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0097.md) | Add Support for EIP-1153 (Transient Storage) in the FEVM | FIP | Michael Seiler (@snissn), Steven Allen (@stebalien) | Accepted | | [0098](https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0098.md) | Simplify termination fee calculation to a fixed percentage of initial pledge | FIP | Jonathan Schwartz (@Schwartz10), Alex North (@anorth), Jim Pick (@jimpick) | Last Call | +| [xxxx](https://github.com/filecoin-project/FIPs/blob/irenegia-removeBatchBalancer/FIPS/fip-removeBatchBalancer.md) | Removing Batch Balancer, Replacing It With a Per-sector Fee and Removing Gas-limited Constraints | FIP | irene (@irenegia), AX (@AxCortesCubero), rvagg (@rvagg), molly (@momack2), kiran (@kkarrancsu)| Draft | From 8df858c5ab204187d9ae2e7fc06925a61a0a73ea Mon Sep 17 00:00:00 2001 From: irene <23217773+irenegia@users.noreply.github.com> Date: Wed, 5 Feb 2025 15:27:09 +0100 Subject: [PATCH 03/27] Update fip-removeBatchBalancer.md --- FIPS/fip-removeBatchBalancer.md | 42 ++++++++++++++++----------------- 1 file changed, 20 insertions(+), 22 deletions(-) diff --git a/FIPS/fip-removeBatchBalancer.md b/FIPS/fip-removeBatchBalancer.md index 1d3dcf07..c5d5d819 100644 --- a/FIPS/fip-removeBatchBalancer.md +++ b/FIPS/fip-removeBatchBalancer.md @@ -57,20 +57,19 @@ We propose a replacement mechanism that preserves these effects while adhering t - Enable future optimizations in the network’s execution layer. **Proposal Details**: We introduce a per-sector fee, whose value is proportional to a fixed fraction of the circulating supply value at that moment and to the sector duration. To prevent this fee from becoming a significant upfront cost that could hinder onboarding, we propose daily payments instead of an upfront fee. Moreover, as a safety measure for the highly-optimistically network growth scenarios, we propose capping the daily payment at a fixed percentage of the 24h expected per-sector block reward. -More in details: at provecommit time we compute the value +More in details: at provecommit time we compute the values - `dailyFee= k * CS(t)` - -Where `k= 7.4 E-15` is a system constant and `t` is the sector activation epoch. Then, the value + dailyFee= k * CS(t) +where `k = 7.4 E-15` is a system constant and `t` is the sector activation epoch. Then, the value - `dailyPayment = min (dailyFee, m * 24hBR)` + dailyPayment = min (dailyFee, m * 24hBR) is paid daily for each new sector onboarded after this FIP is deployed (`m= 0.5` is another system constant). Note that the daily payment is due everyday until sector expiration. In particular: -Even if a sector becomes faulty for the day, the payment is due. In other words, the dailyPayment is paid at windowPoSt time for all sectors in one the following state: active, faulty, recovered; -The total fee per sector over its full sector lifetime is: sectorFee = dailyPayment sectorDurationInDays. If a sector is terminated, the remaining of sectorFee gets computed and paid at termination (can be paid together with termination fee); -If a sector is extended, the dailyPayment is not changed and the sector will keep paying the same value for the extended lifetime. - +- Even if a sector becomes faulty for the day, the payment is due. In other words, the dailyPayment is paid at windowPoSt time for all sectors in one the following state: active, faulty, recovered; +- The total fee per sector over its full sector lifetime is: `sectorFee = dailyPayment sectorDurationInDays`. If a sector is terminated, the remaining of `sectorFee` gets computed and paid at termination (paid together with termination fee); +- If a sector is extended, the dailyPayment is not changed and the sector will keep paying the same value for the extended lifetime. +- TODO: sector updates ? ### Gas-limited constraints @@ -99,26 +98,25 @@ We aimed for a design that is simple to understand and model, and relatively sim - **Upfront Payment vs. Ongoing Payment**: The first offers better predictability, while the second reduces the risk of creating an entry barrier. With this FIP, we chose a hybrid approach that captures the benefits of both by computing the fee upfront for predictability, but allowing it to be paid daily over sector lifetime instead of as a lump sum upfront. - **Flat Fee vs. Dynamic Fee**: A fixed per-sector fee provides predictability and consistency, while a fluctuating fee based on network congestion, onboarding rate, or other variables better captures value when the network is actively providing a service. We chose a model where the fee is a fixed fraction of a quantity that adjusts to economic conditions. We evaluated the following economic indicators for determining the per-sector fee: Initial Pledge (IP), per-sector Block Reward (BR) and Circulating Supply (CS). - - The Initial Pledge was discarded to avoid complex system dependencies, as changes to IP in future FIPs could unintentionally impact the per-sector fee. + - The IP-based fee was discarded to avoid complex system dependencies, as changes to IP in future FIPs could unintentionally impact the per-sector fee. - The BR-based fee was discarded because the fee-to-reward ratio did not adjust properly to network growth, leading to high fees even when onboarding demand was low. See here for more details (TODO add link) - CS was ultimately chosen because it normalizes fees relative to the Filecoin economy, ensuring both adaptability and predictability. -We reached this conclusion through simulation-based analysis, modeling the impact of fees under different network conditions. Specifically, we evaluated multiple input trajectories—0.5×, 0.75×, 1×, and 2× the current onboarding, renewal, and FIL+ rates. Since both renewals and FIL+ are near 100%, we capped them at their current maximum. (See Fig. 1) - -
- Screenshot +We reached this conclusion through simulation-based analysis, modeling the impact of fees under different network conditions. Specifically, we evaluated multiple input trajectories: 0.5×, 0.75×, 1×, and 2× the current onboarding, renewal, and FIL+ rates. Since both renewals and FIL+ are near 100%, we capped them at their current maximum (see Fig. 1). +
+ +

Fig 1: Network state evolution for each input trajectory. +

- - - -For each trajectory, we analyzed the expected fee and related metrics over time. Fig. 2 presents these results for the CS-based fee, incorporating a daily cap at 50% of the per-sector block reward (BR). Notably, Fig. 2 confirms that the CS-based fee proposed in this FIP offers the following key advantages: +For each trajectory, we analyzed the expected fee and related metrics over time. Fig. 2 presents these results for the CS-based fee, incorporating a daily cap at 50% of the per-sector block reward as a safety measure in high-growth scenarios. Notably, Fig. 2 confirms that the CS-based fee proposed in this FIP offers the following key advantages: - **Stable Economic Reference**: A fixed percentage of CS functions like a fixed USD fee if market cap remains stable, keeping costs predictable; - **Adapts to Market Conditions**: If Filecoin’s valuation rises, fees increase in FIL terms, scaling with the economy. If the market stagnates, fees stay economically consistent. - -![Screenshot 2025-02-04 at 18 53 21](https://github.com/user-attachments/assets/7be95ca1-d855-4c32-91c7-a8d48026e197) - - +
+ +

Figure 2: CS-based fee evolution as a function of various network metrics. Here we considered a daily payment that is a fixed % of CS-based and capped at 50% of 24hBR as a safety measure. +

+
## Backwards Compatibility From 0391c9049d1e578da02c5169f987811868a7f4a7 Mon Sep 17 00:00:00 2001 From: irene <23217773+irenegia@users.noreply.github.com> Date: Wed, 5 Feb 2025 18:02:48 +0100 Subject: [PATCH 04/27] Update fip-removeBatchBalancer.md --- FIPS/fip-removeBatchBalancer.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/FIPS/fip-removeBatchBalancer.md b/FIPS/fip-removeBatchBalancer.md index c5d5d819..1d90ada2 100644 --- a/FIPS/fip-removeBatchBalancer.md +++ b/FIPS/fip-removeBatchBalancer.md @@ -133,12 +133,13 @@ This FIP does not affect underlying proofs or protocol security. Filecoin’s network revenue model is currently tied to the gas usage, and the most amount of gas is used by storage onboarding methods. This creates an incentive misalignment, where economic considerations lead to an incentive to not optimize the gas usage of onboarding methods, as this could hurt overall network revenue. -The Batch Balancer mechanism exemplifies this concept: batching and aggregating abilities were introduced to increase gas efficiency of onboarding methods, but the batch balancer mechanism was put in place to essentially turn off these abilities at times of low demand, to protect Filecoin’s economic interests. +The Batch Balancer mechanism exemplifies this concept: batching and aggregating abilities were introduced to increase gas efficiency of onboarding methods, but the batch balancer mechanism restricted use of these abilities to when the network demand was high, to protect Filecoin’s economic interests. -This FIP fixes this incentive misalignment by disconnecting the network revenue from gas usage. The removal of the batch balancer, allows for aggregation to occur even at current levels of demand. We expect this to lead to a reduction of about ~30% in per-sector onboarding gas. This would in turn result in a drop in base fee, and therefore a drop in gas-based network revenue. +This FIP fixes this incentive misalignment by disconnecting the network revenue from gas usage. The removal of the batch balancer allows for aggregation to occur at any level of demand regardless of network utilization rate (such as current levels of demand). We expect this to lead to a reduction of about ~30% in per-sector onboarding gas. This would in turn result in a drop in base fee, and therefore a drop in gas-based network revenue. -The explicit per-sector fee introduced by this FIP allows us to remove the batch balancer, and allow any other future gas usage optimizations, without adding macroeconomic risk. +The explicit per-sector fee introduced by this FIP allows us to remove the batch balancer, and support other future gas usage optimizations, without adding macroeconomic risk. +The removal of batch balancer and associated reduction in gas fees are up-front improvements to SP costs designed to unblock and support faster data onboarding. This up-front cost-reduction is balanced by the per-sector fee that is charged gradually over the sector lifetime, starting at a small fraction of daily block rewards and adjusting dynamically based on network economic growth rate. ## Product Considerations From 5825d687009a369d97766fc20b64346df7bc7a8b Mon Sep 17 00:00:00 2001 From: irene <23217773+irenegia@users.noreply.github.com> Date: Wed, 5 Feb 2025 18:26:35 +0100 Subject: [PATCH 05/27] Update fip-removeBatchBalancer.md --- FIPS/fip-removeBatchBalancer.md | 22 ++++++++++------------ 1 file changed, 10 insertions(+), 12 deletions(-) diff --git a/FIPS/fip-removeBatchBalancer.md b/FIPS/fip-removeBatchBalancer.md index 1d90ada2..1922d31e 100644 --- a/FIPS/fip-removeBatchBalancer.md +++ b/FIPS/fip-removeBatchBalancer.md @@ -56,20 +56,18 @@ We propose a replacement mechanism that preserves these effects while adhering t - Avoid additional onboarding rate limits. - Enable future optimizations in the network’s execution layer. -**Proposal Details**: We introduce a per-sector fee, whose value is proportional to a fixed fraction of the circulating supply value at that moment and to the sector duration. To prevent this fee from becoming a significant upfront cost that could hinder onboarding, we propose daily payments instead of an upfront fee. Moreover, as a safety measure for the highly-optimistically network growth scenarios, we propose capping the daily payment at a fixed percentage of the 24h expected per-sector block reward. -More in details: at provecommit time we compute the values +**Proposal Details**: We introduce a per-sector fee, whose value is proportional to a fixed fraction of the circulating supply and to the sector duration. To prevent this fee from becoming a significant upfront cost that could hinder onboarding, we propose daily payments instead of an upfront fee. Moreover, as a safety measure for the high-growth scenarios, we propose capping the daily payment at a fixed percentage of the daily expected per-sector block reward. - dailyFee= k * CS(t) -where `k = 7.4 E-15` is a system constant and `t` is the sector activation epoch. Then, the value +More in details: at provecommit time we compute the value - dailyPayment = min (dailyFee, m * 24hBR) -is paid daily for each new sector onboarded after this FIP is deployed (`m= 0.5` is another system constant). + dailyFee = k * CS(t) +where `k = 7.4 E-15` is a system constant and `t` is the sector activation epoch. Then, we cap it using the `expected_day_reward` value that is currently already computed as part of the onchain sector info [link](https://github.com/filecoin-project/builtin-actors/blob/5aad41bfa29d8eab78f91eb5c82a03466c6062d2/actors/miner/src/types.rs#L447). That is, we compute: -Note that the daily payment is due everyday until sector expiration. In particular: + dailyPayment = min (dailyFee, m * expected_day_reward) +where `m= 0.5` is another system constant. Then the daily payment is due everyday until sector expirationfor each new sector onboarded after this FIP is deployed. In particular: - Even if a sector becomes faulty for the day, the payment is due. In other words, the dailyPayment is paid at windowPoSt time for all sectors in one the following state: active, faulty, recovered; -- The total fee per sector over its full sector lifetime is: `sectorFee = dailyPayment sectorDurationInDays`. If a sector is terminated, the remaining of `sectorFee` gets computed and paid at termination (paid together with termination fee); -- If a sector is extended, the dailyPayment is not changed and the sector will keep paying the same value for the extended lifetime. -- TODO: sector updates ? +- The total fee per sector over its full sector lifetime is: `sectorFee = dailyPayment * sectorDurationInDays`. If a sector is terminated, the remaining of `sectorFee` gets computed and paid at termination (paid together with termination fee); +- If a sector is extended or updated, the dailyFee is not changed but the cap is recompute considering the upated value of `expected_day_reward` (and therefore the dailyPayment is updated). The sector will keep paying dailyPayment for the extended lifetime. ### Gas-limited constraints @@ -109,12 +107,12 @@ We reached this conclusion through simulation-based analysis, modeling the impac

-For each trajectory, we analyzed the expected fee and related metrics over time. Fig. 2 presents these results for the CS-based fee, incorporating a daily cap at 50% of the per-sector block reward as a safety measure in high-growth scenarios. Notably, Fig. 2 confirms that the CS-based fee proposed in this FIP offers the following key advantages: +For each trajectory, we analyzed the expected fee and related metrics over time. Fig. 2 presents these results for the CS-based fee, incorporating a cap at 50% of `expected_day_reward` as a safety measure in high-growth scenarios. Notably, Fig. 2 confirms that the CS-based fee proposed in this FIP offers the following key advantages: - **Stable Economic Reference**: A fixed percentage of CS functions like a fixed USD fee if market cap remains stable, keeping costs predictable; - **Adapts to Market Conditions**: If Filecoin’s valuation rises, fees increase in FIL terms, scaling with the economy. If the market stagnates, fees stay economically consistent.
-

Figure 2: CS-based fee evolution as a function of various network metrics. Here we considered a daily payment that is a fixed % of CS-based and capped at 50% of 24hBR as a safety measure. +

Figure 2: CS-based fee evolution as a function of various network metrics. Here we considered a daily payment that is a fixed % of CS-based and capped at 50% of `expected_day_reward` as a safety measure in high-growth scenarios.

From 0651a8ca05eef91c1732180368b6a566d96de1e3 Mon Sep 17 00:00:00 2001 From: irene <23217773+irenegia@users.noreply.github.com> Date: Wed, 5 Feb 2025 23:25:04 +0100 Subject: [PATCH 06/27] Create FIPxxxxAppendix.md --- .../FIPxxxxAppendix.md | 83 +++++++++++++++++++ 1 file changed, 83 insertions(+) create mode 100644 resources/fip-replaceBatchBalancer/FIPxxxxAppendix.md diff --git a/resources/fip-replaceBatchBalancer/FIPxxxxAppendix.md b/resources/fip-replaceBatchBalancer/FIPxxxxAppendix.md new file mode 100644 index 00000000..4b892468 --- /dev/null +++ b/resources/fip-replaceBatchBalancer/FIPxxxxAppendix.md @@ -0,0 +1,83 @@ +## Appendix + +This document describes simulations related to FIPxxxx: "Removing Batch Balancer, Replacing It With a Per-sector Fee and Removing Gas-limited Constraints". + +### Simulation Methodology + +#### MechaFIL Introduction +Simulations are conducted using the mechafil package, which is a Python implementation of a mechanistic model of the Filecoin economy. The inputs to the simulation are: +- Raw byte onboarding (PiB/day) +- Renewal Rate (%) - the percentage of expiring power which is renewed +- Fil+ Rate (%) - the percentage of onboarded power which is deal power + +Given a trajectory of inputs, the model will forecast the future state of the network, including network power, circulating supply, locked, pledge, and other related metrics. + +Fig 1 shows the different onboarding trajectories that are simulated. Various input trajectories are considered - 0.5x, 0.75x, 1x, and 2x the current onboarding, renewal, and FIL+ rates. +Renewals and FIL+ are capped at their current maximum, since both values are close to 100%. +
+ +

Fig 1: Network state evolution for each input trajectory. +

+
+ +### Proof Fees Modeling + +#### Circulating Supply (CS) Based Fees +We can describe this fee as follows, for a sector onboarded at time t: + +`sectorFee(t) = k1 * CS(t) * sectorDurationDay` + +In the simulation, the sector duration is fixed to 540 days. + +#### Block Reward (BR) Based Fees +We can describe this fee as follows, for a sector onboarded at time t: + +`sectorFee(t) = k2 * (sum_{d=1, ...,540} sectorBlockReward(t,d) * FeeMultiplier(d)) ` + +In the above formulations: +- FeeMultiplier represents the following multiplier function. +
+ +
+- k1 and k2 represent two different scaling factors +- CS(t) is the circulating supply at time t +- sectorBlockReward(t,d) is the per sector reward for a sector onboarded at time t during day d + +### Simulations + +To understand the effect of BR-based vs CS-based fees, we consider the following 4 metrics: +- Onboarding Fee / Sector; +- Onboarding fee per sector / Pledge per sector; +- Onboarding fee per sector / 1 day of BlockReward per sector; +- Cumulative onboarding fees that would be collected. + +For each trajectory, we can show the expected fee and derivative metrics as a function of time. +Fig 2a and 2b shows these metrics for the CS-based fee (with the cap at 50% expected_daily_reward only for Fig 2b). Fig. 3 here shows these metrics for the BR-based fee. + +
+ +

Figure 2a: CS-based fee evolution as a function of various network metrics. The scaling factor k1 = 5.56 E-15 in the first row and k1= 7.4 E-15 in the second row. +

+
+ +
+ +

Figure 2b: CS-based fee evolution as a function of various network metrics. The scaling factor k1 = 5.56 E-15 in the first row and k1= 7.4 E-15 in the second row. The daily payment is also capped at 50% of expected_daily_reward as a safety measure. +

+
+ +
+ +

Figure 3: BR-based fee evolution as a function of various network metrics. The scaling factor k2 =1% in the first row and = 2% in the second row. +

+
+ + + + +### Conclusions: +The Block Reward (BR, Fig 3) was ruled out because the fee-to-reward ratio did not exhibit the desired behavior—specifically, when network growth slowed, the ratio did not show any slowdown in the increase, which was not optimal. In particular, the total amount of fees burnt over time is less sensitive to the levels of onboarding demand, and there is a risk of fees being high, even when onboarding demand is low. + +Circulating supply (CS, Fig. 2a nad 2b) was chosen. CS is a good basis for the per-sector fee because it normalizes fees relative to the Filecoin economy, ensuring both adaptability and predictability. More precisely: +- Stable Economic Reference: A fixed percentage of CS functions like a fixed USD fee if market cap remains stable, keeping costs predictable; +- Adapts to Market Conditions: If Filecoin’s valuation rises, fees increase in FIL terms, scaling with the economy. If the market stagnates, fees stay economically consistent. From 76d38c482b1b72f872993e829e2812e95abcd43e Mon Sep 17 00:00:00 2001 From: irene <23217773+irenegia@users.noreply.github.com> Date: Wed, 5 Feb 2025 23:26:33 +0100 Subject: [PATCH 07/27] Update fip-removeBatchBalancer.md --- FIPS/fip-removeBatchBalancer.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/FIPS/fip-removeBatchBalancer.md b/FIPS/fip-removeBatchBalancer.md index 1922d31e..1d5335ad 100644 --- a/FIPS/fip-removeBatchBalancer.md +++ b/FIPS/fip-removeBatchBalancer.md @@ -97,7 +97,7 @@ We aimed for a design that is simple to understand and model, and relatively sim - **Flat Fee vs. Dynamic Fee**: A fixed per-sector fee provides predictability and consistency, while a fluctuating fee based on network congestion, onboarding rate, or other variables better captures value when the network is actively providing a service. We chose a model where the fee is a fixed fraction of a quantity that adjusts to economic conditions. We evaluated the following economic indicators for determining the per-sector fee: Initial Pledge (IP), per-sector Block Reward (BR) and Circulating Supply (CS). - The IP-based fee was discarded to avoid complex system dependencies, as changes to IP in future FIPs could unintentionally impact the per-sector fee. - - The BR-based fee was discarded because the fee-to-reward ratio did not adjust properly to network growth, leading to high fees even when onboarding demand was low. See here for more details (TODO add link) + - The BR-based fee was discarded because the fee-to-reward ratio did not adjust properly to network growth, leading to high fees even when onboarding demand was low. See [here](https://github.com/filecoin-project/FIPs/blob/irenegia-removeBatchBalancer/resources/fip-replaceBatchBalancer/FIPxxxxAppendix.md) for more details. - CS was ultimately chosen because it normalizes fees relative to the Filecoin economy, ensuring both adaptability and predictability. We reached this conclusion through simulation-based analysis, modeling the impact of fees under different network conditions. Specifically, we evaluated multiple input trajectories: 0.5×, 0.75×, 1×, and 2× the current onboarding, renewal, and FIL+ rates. Since both renewals and FIL+ are near 100%, we capped them at their current maximum (see Fig. 1). From 539b1831f267246225d5f4b3f79bab22caf13d0d Mon Sep 17 00:00:00 2001 From: Rod Vagg Date: Thu, 6 Feb 2025 22:36:56 +1100 Subject: [PATCH 08/27] Initial draft of specification and implementation details --- FIPS/fip-removeBatchBalancer.md | 117 ++++++++++++++++++++++++++++++-- 1 file changed, 110 insertions(+), 7 deletions(-) diff --git a/FIPS/fip-removeBatchBalancer.md b/FIPS/fip-removeBatchBalancer.md index 1d5335ad..5fd0625f 100644 --- a/FIPS/fip-removeBatchBalancer.md +++ b/FIPS/fip-removeBatchBalancer.md @@ -80,15 +80,118 @@ Various protocol constraints that were previously necessary when there was no ga In most cases, users will be limited by the gas limit rather than these constraints ([`message execution failed: exit SysErrOutOfGas`](https://github.com/filecoin-project/lotus/issues/10612)). Removing these constraints will simplify the protocol and remove any unintentional network growth constraints. ## Specification -- Remove the burning `aggregate_fee` from `PreCommitSectorBatch2`. -- Remove the burning `aggregate_fee` from `ProveCommitAggregate`, `ProveCommitSectorsNI`, `ProveCommitSectors3` -- TODO : add actor spec for the per sector fee +This FIP makes three main changes to the protocol: +1. Removes the batch balancer fee mechanism from sector pre-commit and prove-commit operations +2. Removes certain gas-limited protocol constraints that are no longer necessary +3. Introduces a new per-sector daily fee mechanism based on circulating supply and block rewards -- Remove the following gas-limited constraints: - - `PRE_COMMIT_SECTOR_BATCH_MAX_SIZE` - - `PROVE_REPLICA_UPDATES_MAX_SIZE` - - `DECLARATIONS_MAX` + +### Storage power actor + +The storage power actor will be used to record a daily average of the circulating supply. This is achieved by incrementing a running total of circulating supply per epoch through the existing cron call. Once every 2880 epochs this will be divided and recorded in an AMT as the average circulating supply for that day period. Records will be indexed starting from `0` and incrementing `1` per day (creating an optimal AMT structure). + +The power actor will also store a new field, set on activation of this FIP to the activation epoch, to record the collection start epoch. This value will be used to quantise down any requested epoch to the daily average value. + +```rust +pub struct State { + // existing fields ... + + /// The epoch when average daily supply started being recorded. This is the activation epoch of + /// FIP-XXXX and is used for quantising epochs to their daily average record in the daily_supply + /// array. + pub daily_supply_record_start: i64, + + /// A running total for the current 24 hour period, incremented on each call from cron, and used + /// to record the average value for the previous 24 hour period once a day. + pub daily_supply_total: TokenAmount, + + /// Average circulating supply for each 24 hour period since the start of recording as defined by + /// daily_supply_record_start, indexed by day, starting from 0 as the first 24 hour period + /// recorded after daily_supply_record_start and incrementing by 1 each day. + pub daily_supply: Cid, // Array (AMT[TokenAmount]) +} +``` + +In addition, a new method will be exposed to access the current root CID of the AMT so that another actor can load one or more arbitrary historical records. As the storage miner actor may need to look up many separate records when dealing with batches of sectors, it will be more efficient to pass the data structure rather than answer specific queries. + +```rust +fn daily_supply_root(rt: &impl Runtime) -> Result +``` + +A helper wrapper for the AMT that can be shared amongst actors to easily convert arbitrary epochs to daily average values is suggested. + +### Storage miner actor + +#### Removal of gas-limited constraints + +The following constants and their use will be removed: + - `PRE_COMMIT_SECTOR_BATCH_MAX_SIZE` - used by `PreCommitSectorBatch2` + - `PROVE_REPLICA_UPDATES_MAX_SIZE` - used by both `ProveReplicaUpdates` and `ProveReplicaUpdates3` + - `DECLARATIONS_MAX` - used by `TerminateSectors`, `DeclareFaults` and `DeclareFaultsRecovered` + +#### Removal of aggregate fee + +- Remove the burning of `aggregate_fee` from `PreCommitSectorBatch2`. +- Remove the burning of `aggregate_fee` from `ProveCommitAggregate`, `ProveCommitSectorsNI`, `ProveCommitSectors3` +- Removal of `aggregate_fee` calculation methods and associated constants, including `ESTIMATED_SINGLE_PROVE_COMMIT_GAS_USAGE` and `ESTIMATED_SINGLE_PRE_COMMIT_GAS_USAGE` + +#### Fee implementation + +Fees are payable daily at WindowPoSt for the sectors being proven. As this operation aims to be gas-efficient, the introduction of a fee mechanism should not add unnecessary additional load `SubmitWindowedPoSt`. Since WindowPoSt addresses sectors grouped by partition, a total daily fee amount for an entire partition will be stored in the root of the partition's state. This value is summed across the partitions included in a successful `SubmitWindowedPoSt` message and deducted from the miner actor. No special handling is added for skipped sectors in a WindowPoSt. + +TODO (should we do it here?): It is within WindowPoSt that the cap on the daily fee is enforced. The cap is calculated as a fixed percentage of the expected daily block reward. This is calculated by using the total power from storage power actor, and current epoch block reward from the reward actor combined with the QaP recorded for the partition. + +```rust +pub struct Partition { + // existing fields ... + + /// The total fee payable per day for this partition, this represents a sum of the daily fee + /// amounts for all sectors in this partition. + pub daily_fee: TokenAmount, +} +``` + +Fees are calculated for each sector at various points in their lifecycle and the `daily_fee` value in their assigned partition is updated accordingly. The fee is calculated as a fixed fraction of the circulating supply at the time of sector activation. The circulating supply value is taken from the record in the power actor for the day of sector activation; the last average circulating supply value recorded before the sector activation epoch is used. This same value can be looked up at any future point in time to calculate the fee for potential adjustments. + +For each of `ProveCommitSectors3`, `ProveCommitAggregate` and `ProveCommitSectorsNI` the fee is for each sector committed is calculated at the time of the message and added to the existing `daily_fee` total recorded in the partition the sector is assigned to. + +Faults have no impact on a partition's `daily_fee` value. + +Early terminations, both automatic and manual, will result in a reduction of the partition's `daily_fee` value for the sectors being terminated. `daily_fee` is reduced by the daily fee recalculated for the sector by using the activation epoch and average circulating supply value for that epoch as described above. In this way, addition and removal of sectors from a partition will adjust the daily fee by the correct amount, resulting in no over or undercharging. + +#### Alternative fee implementation + +_This section is provided temporarily for discussion purposes and will either be removed or used to rework the above section once the final fee implementation is decided. Acceptance of this design will result in the removal of proposed changes to the storage power actor above._ + +_Description of `daily_fee` accumulation in the partition and its use on WindowPoSt remains the same._ + +The `SectorOnChainInfo` struct will be extended to include a new field `daily_fee` which will be used to store the daily fee for the sector. This value will be updated at the time of sector activation and will be used to calculate the daily fee for the sector for the duration of its lifetime. Due to the number of sectors already on chain and the expense of migrating to a new format to add this field, the existing block layout will continue to be supported, which is represented as a 15 element array, with one element per field of the struct. The new field will be added as the 16th element of the array. Loading and decoding any `SectorOnChainInfo` block will be able to handle both the old and new formats. Any writes by the builtin actors will strictly use the new format. + +A future migration will be proposed to unify the format, however this is deferred until additional sector clean-up activities can take place to reduce the number of unused sectors on chain, thereby reducing the cost of migration. + +```rust +pub struct SectorOnChainInfo { + // existing fields ... + + /// The total fee payable per day for this sector. The value of this field is set at the time of + /// sector activation and is used to calculate the daily fee for the sector for the duration of + /// its lifetime. + /// This field is not included in the serialised form of the struct prior to the activation of + /// FIP-XXXX, and is added as the 16th element of the array after that point only for new sectors + /// or sectors that are updated after that point. For old sectors, the value of this field will + /// always be zero. + pub daily_fee: TokenAmount, +} +``` + +Fees are calculated for each sector at various points in their lifecycle and the `daily_fee` value is stored in the sector's `SectorOnChainInfo` and the `daily_fee` value in their assigned partition is updated accordingly. The fee is calculated as a fixed fraction of the circulating supply at the time of sector activation. The circulating supply value is available at the time of sector onboarding as it is used for pledge calculation. + +For each of `ProveCommitSectors3`, `ProveCommitAggregate` and `ProveCommitSectorsNI` the fee is for each sector committed is calculated at the time of the message. + +Faults have no impact on a partition's `daily_fee` value. + +Early terminations, both automatic and manual, will result in a reduction of the partition's `daily_fee` value for the sectors being terminated. `daily_fee` is reduced by the daily fee recalculated for the sector by using the activation epoch and average circulating supply value for that epoch as described above. In this way, addition and removal of sectors from a partition will adjust the daily fee by the correct amount, resulting in no over or undercharging. ## Design Rationale We aimed for a design that is simple to understand and model, and relatively simple to implement. With this in mind, we explored the following fee structures: From 401d8663dbb192f40281e1b3fe1f69ef905f3903 Mon Sep 17 00:00:00 2001 From: Rod Vagg Date: Fri, 7 Feb 2025 15:08:53 +1100 Subject: [PATCH 09/27] Add migration details and termination memoisation/reconciliation details --- FIPS/fip-removeBatchBalancer.md | 33 ++++++++++++++++++++++++++++++--- 1 file changed, 30 insertions(+), 3 deletions(-) diff --git a/FIPS/fip-removeBatchBalancer.md b/FIPS/fip-removeBatchBalancer.md index 5fd0625f..2c50fd72 100644 --- a/FIPS/fip-removeBatchBalancer.md +++ b/FIPS/fip-removeBatchBalancer.md @@ -91,6 +91,8 @@ This FIP makes three main changes to the protocol: The storage power actor will be used to record a daily average of the circulating supply. This is achieved by incrementing a running total of circulating supply per epoch through the existing cron call. Once every 2880 epochs this will be divided and recorded in an AMT as the average circulating supply for that day period. Records will be indexed starting from `0` and incrementing `1` per day (creating an optimal AMT structure). +_TODO: the bitwidth of the AMT will need to be decided, a value of 5 is proposed, for a branching factor of 32._ + The power actor will also store a new field, set on activation of this FIP to the activation epoch, to record the collection start epoch. This value will be used to quantise down any requested epoch to the daily average value. ```rust @@ -121,6 +123,14 @@ fn daily_supply_root(rt: &impl Runtime) -> Result A helper wrapper for the AMT that can be shared amongst actors to easily convert arbitrary epochs to daily average values is suggested. +#### Migration + +At activation of this FIP, a new layout for the storage power actor state will be introduced, adding 3 new fields. The existing state will be migrated to the new layout by copying the existing fields. + +* `daily_supply_record_start` will be set to the activation epoch of this FIP +* `daily_supply_total` will be set to zero +* `daily_supply` will be set to the empty AMT for the specified bitwidth + ### Storage miner actor #### Removal of gas-limited constraints @@ -146,19 +156,30 @@ TODO (should we do it here?): It is within WindowPoSt that the cap on the daily pub struct Partition { // existing fields ... + /// Subset of sectors that have been terminated but their fee has not yet been removed from the + /// total daily fee for this partition. Reconciliation of the fee for these sectors will be + /// performed at the time the fee is payable. + pub fee_deductions: BitField, + /// The total fee payable per day for this partition, this represents a sum of the daily fee /// amounts for all sectors in this partition. pub daily_fee: TokenAmount, } ``` -Fees are calculated for each sector at various points in their lifecycle and the `daily_fee` value in their assigned partition is updated accordingly. The fee is calculated as a fixed fraction of the circulating supply at the time of sector activation. The circulating supply value is taken from the record in the power actor for the day of sector activation; the last average circulating supply value recorded before the sector activation epoch is used. This same value can be looked up at any future point in time to calculate the fee for potential adjustments. +Fees are calculated for each sector at multiple points in their lifecycle and the `daily_fee` value in their assigned partition is updated accordingly. The fee is calculated as a fixed fraction of the circulating supply at the time of sector activation. The circulating supply value is taken from the record in the power actor for the day of sector activation; the last average circulating supply value recorded before the sector activation epoch is used. This same value can be looked up at any future point in time to calculate the fee for potential adjustments. For each of `ProveCommitSectors3`, `ProveCommitAggregate` and `ProveCommitSectorsNI` the fee is for each sector committed is calculated at the time of the message and added to the existing `daily_fee` total recorded in the partition the sector is assigned to. Faults have no impact on a partition's `daily_fee` value. -Early terminations, both automatic and manual, will result in a reduction of the partition's `daily_fee` value for the sectors being terminated. `daily_fee` is reduced by the daily fee recalculated for the sector by using the activation epoch and average circulating supply value for that epoch as described above. In this way, addition and removal of sectors from a partition will adjust the daily fee by the correct amount, resulting in no over or undercharging. +Early terminations, both automatic and manual, will result in a reduction of the partition's `daily_fee` value for the sectors being terminated. Early terminations are currently handled at the end of each proving deadline via cron, and for efficiency, sector state is not fetched, but sector numbers and power adjustments are memoised per partition and reconciled later. Fee adjustment for early termination will also be memoised and reconciled at the time the fee is payable. When a sector number is added to the partition's `terminated` bitfield, the sector number will also be added to the `fee_deductions` bitfield. The `fee_deductions` bitfield will be used to track the sectors that have been terminated but their fee has not yet been removed from the total `daily_fee` for this partition. `fee_deductions` does not need to be used for any functionality other than fee reconciliation (although it will be useful for external inspection where total partition fee amounts are required). + +Reconciliation of the fee for these sectors will be performed at WindowPoSt via a `Deadline`'s `record_proven_sectors`. Each `Partition` will be asked for its fee amount via a new method and it is within this method that any sector's numbers recorded in `fee_deductions` will have their fee recalculated and deducted from the total `daily_fee` for the partition. The `fee_deductions` bitfield will be cleared after reconciliation. `daily_fee` is reduced by recalculating the sector's daily fee by using the activation epoch and average circulating supply value for that epoch as described above. In this way, addition and removal of sectors from a partition will adjust the daily fee by the correct amount, resulting in no over or undercharging. + +#### Migration + +At activation of this FIP, a new layout for the `Partition` block type will be introduced, adding a new field, `daily_fee: TokenAmount`. A migration will be performed on all partitions, within all deadlines, across all miner actors. At the time of writing there are 293,000 partitions on the chain, distributed across the 695,000 miner actors. Each of these will need to be migrated to the new format. The migration will be performed by loading the existing partition state, copying the existing fields to the new format, and setting the `daily_fee` field to zero. The new format will be used for all new partitions created after the activation of this FIP. #### Alternative fee implementation @@ -166,7 +187,9 @@ _This section is provided temporarily for discussion purposes and will either be _Description of `daily_fee` accumulation in the partition and its use on WindowPoSt remains the same._ -The `SectorOnChainInfo` struct will be extended to include a new field `daily_fee` which will be used to store the daily fee for the sector. This value will be updated at the time of sector activation and will be used to calculate the daily fee for the sector for the duration of its lifetime. Due to the number of sectors already on chain and the expense of migrating to a new format to add this field, the existing block layout will continue to be supported, which is represented as a 15 element array, with one element per field of the struct. The new field will be added as the 16th element of the array. Loading and decoding any `SectorOnChainInfo` block will be able to handle both the old and new formats. Any writes by the builtin actors will strictly use the new format. +The `SectorOnChainInfo` struct will be extended to include a new field `daily_fee` which will be used to store the daily fee for the sector. This value will be updated at the time of sector activation and will be used to calculate the daily fee for the sector for the duration of its lifetime. + +Due to the number of sectors already on chain (currently 645,600,000) and the expense of migrating to a new format to add this field, the existing block layout will continue to be supported, which is represented as a 15 element array, with one element per field of the struct. The new field will be added as the 16th element of the array. Loading and decoding any `SectorOnChainInfo` block will be able to handle both the old and new formats. Any writes by the builtin actors will strictly use the new format. A future migration will be proposed to unify the format, however this is deferred until additional sector clean-up activities can take place to reduce the number of unused sectors on chain, thereby reducing the cost of migration. @@ -193,6 +216,10 @@ Faults have no impact on a partition's `daily_fee` value. Early terminations, both automatic and manual, will result in a reduction of the partition's `daily_fee` value for the sectors being terminated. `daily_fee` is reduced by the daily fee recalculated for the sector by using the activation epoch and average circulating supply value for that epoch as described above. In this way, addition and removal of sectors from a partition will adjust the daily fee by the correct amount, resulting in no over or undercharging. +##### Migration + +There is no migration required for this implementation as the existing format will continue to be supported. The new field will be added to the sector state as sectors are updated or new sectors are created after the activation of this FIP. + ## Design Rationale We aimed for a design that is simple to understand and model, and relatively simple to implement. With this in mind, we explored the following fee structures: From ee4576d4e54fbe5af3dbebec7bc8ddd1bedbd344 Mon Sep 17 00:00:00 2001 From: Rod Vagg Date: Fri, 7 Feb 2025 16:19:35 +1100 Subject: [PATCH 10/27] Add section detailing CS changes needed to fix Calibnet --- FIPS/fip-removeBatchBalancer.md | 57 +++++++++++++++++++++++++++++++++ 1 file changed, 57 insertions(+) diff --git a/FIPS/fip-removeBatchBalancer.md b/FIPS/fip-removeBatchBalancer.md index 2c50fd72..e2ab6750 100644 --- a/FIPS/fip-removeBatchBalancer.md +++ b/FIPS/fip-removeBatchBalancer.md @@ -220,6 +220,63 @@ Early terminations, both automatic and manual, will result in a reduction of the There is no migration required for this implementation as the existing format will continue to be supported. The new field will be added to the sector state as sectors are updated or new sectors are created after the activation of this FIP. +### Special handling for Calibration network + +In order to properly test the implementation of this FIP, a long-standing problem with circulating supply calculation on Calibnet will need to be addressed. Circulating supply is calculated using an estimation method each epoch and supplied to the FVM, it uses these inputs (from the time of writing): + +| Metric | Mainnet (FIL) | Calibnet (FIL) | +|----------------------|--------------:|---------------:| +| `FilVested` | 484,847,134 | 323,483,605 | +| `FilMined` | 365,928,138 | 68,672,646 | +| `FilBurnt` | 40,327,377 | 32,117,860 | +| `FilLocked` | 140,975,297 | 3,893,484 | +| `InitialFilReserved` | 300,000,000 | 300,000,000 | +| `FilReserveBalance` | 282,933,381 | 869,278,271 | + +The amount of reserved funds disbursed from f090 (`FilReserveDisbursed`) is then calculated as: + +```math +FilReserveDisbursed = InitialFilReserved - FilReserveBalance +``` + +For Mainnet: +```math +FilReserveDisbursed = 300,000,000 - 282,933,381 = 17,066,619 +``` + +For Calibnet: +```math +FilReserveDisbursed = 300,000,000 - 869,278,271 = -569,278,271 +``` + +Circulating supply (`CS`) is then calculated as: + +```math +CS = \max(0, FilVested + FilMined + FilReserveDisbursed - FilBurnt - FilLocked) +``` + +For Mainnet: +```math +CS = \max(0, 484,847,134 + 365,928,138 + 17,066,619 - 40,327,377 - 140,975,297) = 686,539,216 +``` + +For Calibnet: +```math +CS = \max(0, 323,483,605 + 68,672,646 + (-569,278,271) - 32,117,860 - 3,893,484) = 0 +``` + +Calibnet currently executes with a circulating supply of `0` each epoch, regardless of token movements. + +Because this FIP uses a fixed portion of current circulating supply to calculate the fee, Calibnet fees will always be `0`, which makes proper testing of the new functionality in live network conditions impossible. + +To address this problem, this FIP will also adjust network parameters for Calibnet to ensure that the circulating supply is a reasonable and dynamic positive number. The core problem is the initial allocation of reserve funds which appears to have been set to 900M FIL. This was likely set to ensure a total supply of 2B FIL. Unfortunately, implementations use the same `InitialFilReserved` value as mainnet, 300M FIL. Filecoin node implementations compatible with Calibnet will be required to set their `InitialFilReserved` for Calibnet to `900,000,000` FIL from the activation epoch of this FIP. This will result in a more appropriate circulating supply calculation: + +| Metric | Mainnet (FIL) | Calibnet (FIL) | +|-----------------------|--------------:|---------------:| +| `InitialFilReserved` | 300,000,000 | 900,000,000 | +| `FilReserveDisbursed` | 17,066,619 | 30,721,729 | +| `FilCirculating` | 686,539,216 | 386,866,636 | + ## Design Rationale We aimed for a design that is simple to understand and model, and relatively simple to implement. With this in mind, we explored the following fee structures: From 22678529eff7ffbb998f2cb35aeb814a29c69cb3 Mon Sep 17 00:00:00 2001 From: Rod Vagg Date: Fri, 7 Feb 2025 20:41:15 +1100 Subject: [PATCH 11/27] Further implementation notes and added test cases --- FIPS/fip-removeBatchBalancer.md | 40 +++++++++++++++++++++++++++++---- 1 file changed, 36 insertions(+), 4 deletions(-) diff --git a/FIPS/fip-removeBatchBalancer.md b/FIPS/fip-removeBatchBalancer.md index e2ab6750..756d83fc 100644 --- a/FIPS/fip-removeBatchBalancer.md +++ b/FIPS/fip-removeBatchBalancer.md @@ -11,7 +11,6 @@ Created: 2025-02-04 # FIP-00XX: Removing Batch Balancer, Replacing It With a Per-sector Fee and Removing Gas-limited Constraints - ## Simple Summary This FIP proposes to: - Remove the batch fee from all precommit and provecommit methods to incentivize sector batching during the precommit step and proof aggregation during the provecommit step; @@ -169,14 +168,18 @@ pub struct Partition { Fees are calculated for each sector at multiple points in their lifecycle and the `daily_fee` value in their assigned partition is updated accordingly. The fee is calculated as a fixed fraction of the circulating supply at the time of sector activation. The circulating supply value is taken from the record in the power actor for the day of sector activation; the last average circulating supply value recorded before the sector activation epoch is used. This same value can be looked up at any future point in time to calculate the fee for potential adjustments. -For each of `ProveCommitSectors3`, `ProveCommitAggregate` and `ProveCommitSectorsNI` the fee is for each sector committed is calculated at the time of the message and added to the existing `daily_fee` total recorded in the partition the sector is assigned to. +**Sector commitments**, performed with each of `ProveCommitSectors3`, `ProveCommitAggregate` and `ProveCommitSectorsNI` the fee is for each sector committed is calculated at the time of the message and added to the existing `daily_fee` total recorded in the partition the sector is assigned to. Faults have no impact on a partition's `daily_fee` value. -Early terminations, both automatic and manual, will result in a reduction of the partition's `daily_fee` value for the sectors being terminated. Early terminations are currently handled at the end of each proving deadline via cron, and for efficiency, sector state is not fetched, but sector numbers and power adjustments are memoised per partition and reconciled later. Fee adjustment for early termination will also be memoised and reconciled at the time the fee is payable. When a sector number is added to the partition's `terminated` bitfield, the sector number will also be added to the `fee_deductions` bitfield. The `fee_deductions` bitfield will be used to track the sectors that have been terminated but their fee has not yet been removed from the total `daily_fee` for this partition. `fee_deductions` does not need to be used for any functionality other than fee reconciliation (although it will be useful for external inspection where total partition fee amounts are required). +**Early terminations**, both automatic and manual, will result in a reduction of the partition's `daily_fee` value for the sectors being terminated. Early terminations are currently handled at the end of each proving deadline via cron, and for efficiency, sector state is not fetched, but sector numbers and power adjustments are memoised per partition and reconciled later. Fee adjustment for early termination will also be memoised and reconciled at the time the fee is payable. When a sector number is added to the partition's `terminated` bitfield, the sector number will also be added to the `fee_deductions` bitfield. The `fee_deductions` bitfield will be used to track the sectors that have been terminated but their fee has not yet been removed from the total `daily_fee` for this partition. `fee_deductions` does not need to be used for any functionality other than fee reconciliation (although it will be useful for external inspection where total partition fee amounts are required). Reconciliation of the fee for these sectors will be performed at WindowPoSt via a `Deadline`'s `record_proven_sectors`. Each `Partition` will be asked for its fee amount via a new method and it is within this method that any sector's numbers recorded in `fee_deductions` will have their fee recalculated and deducted from the total `daily_fee` for the partition. The `fee_deductions` bitfield will be cleared after reconciliation. `daily_fee` is reduced by recalculating the sector's daily fee by using the activation epoch and average circulating supply value for that epoch as described above. In this way, addition and removal of sectors from a partition will adjust the daily fee by the correct amount, resulting in no over or undercharging. +**Partition compaction** will necessarily involve recalculation of a partition-level `daily_fee` using each sector in the partition. Per-sector daily fees will be recalculated using the activation epoch and average circulating supply value for that epoch as described above. The partition's `daily_fee` will be updated to reflect the sum of the daily fees for all sectors in the partition. Any outstanding `fee_deductions` will be recalculated and deducted from the total `daily_fee` for the partition. + +***TODO***: **Balance withdrawal**: _is this allowed while there are `fee_deductions` in place? If not, do we need `fee_deductions` at the top-level to indicate which deadlines have deductions that need to be reconciled? Do we just let withdrawals proceed and if they don't have balance left to cover the fees they fail post?_ + #### Migration At activation of this FIP, a new layout for the `Partition` block type will be introduced, adding a new field, `daily_fee: TokenAmount`. A migration will be performed on all partitions, within all deadlines, across all miner actors. At the time of writing there are 293,000 partitions on the chain, distributed across the 695,000 miner actors. Each of these will need to be migrated to the new format. The migration will be performed by loading the existing partition state, copying the existing fields to the new format, and setting the `daily_fee` field to zero. The new format will be used for all new partitions created after the activation of this FIP. @@ -308,8 +311,37 @@ For each trajectory, we analyzed the expected fee and related metrics over time. This FIP modifies actor behavior and will require a new Filecoin network version. ## Test Cases -TODO +### builtin-actors + +Many of the test scenarios outlined below already exist within the test suite for builtin-actors. Ensuring that all of the various cases, particularly edge-cases, are covered will be important to ensure that the new fee mechanism is correctly implemented and behaves as expected. In addition, any existing test scenarios that test sector lifecycles should be updated to include invariants that check the new fee mechanism: that it is correctly calculated, tallied in the partition, remains correct over time, is correctly deducted at WindowPoSt time, is correctly capped and is correctly adjusted for terminations. + +* Test that the batch balancer fee is removed from `PreCommitSectorBatch2` and `ProveCommitAggregate`, `ProveCommitSectorsNI`, `ProveCommitSectors3` +* Test that the gas-limited constraints are removed from the protocol +* Test that the power actor correctly records the daily average circulating supply - both in per-epoch increments and per-day averages recorded in the AMT + * Test that the power actor can provide the correct AMT root CID for the circulating supply average data +* Test that the per-sector fee is correctly calculated and added to the respective partition's `daily_fee` value when using `ProveCommitAggregate`, `ProveCommitSectorsNI`, `ProveCommitSectors3` + * Tests should cover different batching variations +* Test that `ProveReplicaUpdates` and `ProveReplicaUpdates3` do not have an impact on the fee mechanism +* Test that the per-sector fee is correctly charged at WindowPoSt time for all sectors in the active, faulty, and recovered states + * Tests should cover different batching variations +* Test that manual early terminations correctly adjust the partition's `daily_fee` value at the next WindowPoSt +* Test that automatic early terminations correctly adjust the partition's `daily_fee` value at the next WindowPoSt +* Test that sector expiration correctly adjusts the partition's `daily_fee` value at the next WindowPoSt +* Test that the fee is correctly capped at the expected daily block reward at WindowPoSt time +* Test that partition compaction correctly recalculates the `daily_fee` value for each partition + +### Calibration network + +Once Calibnet is upgraded, functional tests should be performed that cover: + +* Ensure that the circulating supply is a reasonable and dynamic positive number +* Ensure that the power actor is correctly recording the daily average circulating supply +* Onboarding new sectors with `PreCommitSectorBatch2` and `ProveCommitAggregate`, `ProveCommitSectors3` (and `ProveCommitSectorsNI` if possible) and: + * observing that the batch balancer fee is not applied + * observing partition state to ensure that the new fee mechanism is correctly implemented and behaves as expected +* Observing that the per-sector fee is correctly charged at WindowPoSt time for all sectors in the active, faulty, and recovered states +* Observing that manual early terminations correctly adjust the partition's `daily_fee` value at the next WindowPoSt ## Security Considerations This FIP does not affect underlying proofs or protocol security. From 81a309bd7a8277d40284b001a99ade7c703b9918 Mon Sep 17 00:00:00 2001 From: irene <23217773+irenegia@users.noreply.github.com> Date: Mon, 10 Feb 2025 11:48:51 +0100 Subject: [PATCH 12/27] Update fip-removeBatchBalancer.md --- FIPS/fip-removeBatchBalancer.md | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/FIPS/fip-removeBatchBalancer.md b/FIPS/fip-removeBatchBalancer.md index 756d83fc..9f8d0835 100644 --- a/FIPS/fip-removeBatchBalancer.md +++ b/FIPS/fip-removeBatchBalancer.md @@ -42,7 +42,10 @@ On the other hand, aggregation is rational only when the base fee exceeds 0.065 To have a rough estimate of the saving, we can compare these `ProveCommitSector3` messages posted by the same miner actor with little difference in the number of sectors when the message landed[^*]. - [Msg 1](https://www.filutils.com/en/message/bafy2bzacebshpv7afwnxph6l4jnbpwpqnss3cboyfvlualfrjbox76hojjnlo): ProveCommitSectors3 for 1 sector: 267.5 M - [Msg 2](https://www.filutils.com/en/message/bafy2bzacebd7ftq5lk4ikuif4j3xfwiabmla5bek3kuhn3k6x3obufxyzrs6y): ProveCommitSectors3 for 4 sectors, batched (no aggregation): 580 M/4 = 145 M per sector (1.85x smaller) -- [Msg 3](https://www.filutils.com/en/message/bafy2bzacedezi6lm4warrfq2n6dxvpokowzt5isacbq2kojkz462yfpfq7lxm): ProveCommitSectors3 for 4 sectors, aggregated: 517.4 M/4 = 129.3 M per sector (2x smaller) +- [Msg 3](https://www.filutils.com/en/message/bafy2bzacedezi6lm4warrfq2n6dxvpokowzt5isacbq2kojkz462yfpfq7lxm): ProveCommitSectors3 for 4 sectors, aggregated: 517.4 M/4 = 129.3 M per sector (2x smaller). + +The same logic applies to `ProveCommitSectorsNI`, where we have the same two options as in `ProveCommitSector3`. +TODO: add gas saving numbers for NI-PoRep. [^*]: A bug is currently causing single proofs to be charged an incorrect amount of gas units. So we added the missing units (42M per proof) to msg1 and msg2 in order to provide the future correct estimates (the bug is planned to be fixed in nv25). See [here](https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0076.md) From 490ad2e9694153289dfe89fb287ebeb41c682cd1 Mon Sep 17 00:00:00 2001 From: irene <23217773+irenegia@users.noreply.github.com> Date: Tue, 11 Feb 2025 11:21:20 +0100 Subject: [PATCH 13/27] Apply suggestions from code review Co-authored-by: MollyM --- FIPS/fip-removeBatchBalancer.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/FIPS/fip-removeBatchBalancer.md b/FIPS/fip-removeBatchBalancer.md index 9f8d0835..a872b93f 100644 --- a/FIPS/fip-removeBatchBalancer.md +++ b/FIPS/fip-removeBatchBalancer.md @@ -66,7 +66,7 @@ More in details: at provecommit time we compute the value where `k = 7.4 E-15` is a system constant and `t` is the sector activation epoch. Then, we cap it using the `expected_day_reward` value that is currently already computed as part of the onchain sector info [link](https://github.com/filecoin-project/builtin-actors/blob/5aad41bfa29d8eab78f91eb5c82a03466c6062d2/actors/miner/src/types.rs#L447). That is, we compute: dailyPayment = min (dailyFee, m * expected_day_reward) -where `m= 0.5` is another system constant. Then the daily payment is due everyday until sector expirationfor each new sector onboarded after this FIP is deployed. In particular: +where `m= 0.5` is another system constant. Then the daily payment is due everyday until sector expiration for each new sector onboarded after this FIP is deployed. In particular: - Even if a sector becomes faulty for the day, the payment is due. In other words, the dailyPayment is paid at windowPoSt time for all sectors in one the following state: active, faulty, recovered; - The total fee per sector over its full sector lifetime is: `sectorFee = dailyPayment * sectorDurationInDays`. If a sector is terminated, the remaining of `sectorFee` gets computed and paid at termination (paid together with termination fee); - If a sector is extended or updated, the dailyFee is not changed but the cap is recompute considering the upated value of `expected_day_reward` (and therefore the dailyPayment is updated). The sector will keep paying dailyPayment for the extended lifetime. From 122afefe28d95e437635a8a13ab10c8eb0d0f2ab Mon Sep 17 00:00:00 2001 From: MollyM Date: Tue, 11 Feb 2025 09:54:01 -0800 Subject: [PATCH 14/27] Apply suggestions from code review Applying changes for naming to FIP-0100 --- FIPS/fip-removeBatchBalancer.md | 6 +++--- README.md | 2 +- resources/fip-replaceBatchBalancer/FIPxxxxAppendix.md | 2 +- 3 files changed, 5 insertions(+), 5 deletions(-) diff --git a/FIPS/fip-removeBatchBalancer.md b/FIPS/fip-removeBatchBalancer.md index a872b93f..4ca85aba 100644 --- a/FIPS/fip-removeBatchBalancer.md +++ b/FIPS/fip-removeBatchBalancer.md @@ -1,5 +1,5 @@ --- -fip: "00XX" +fip: "0100" title: Removing Batch Balancer, Replacing It With a Per-sector Fee and Removing Gas-limited Constraints author: irene (@irenegia), AX (@AxCortesCubero), rvagg (@rvagg), molly (@momack2), kiran (@kkarrancsu) Discussions-to: https://github.com/filecoin-project/FIPs/discussions/1092 and https://github.com/filecoin-project/FIPs/discussions/1105 @@ -9,7 +9,7 @@ category: Core Created: 2025-02-04 --- -# FIP-00XX: Removing Batch Balancer, Replacing It With a Per-sector Fee and Removing Gas-limited Constraints +# FIP-0100: Removing Batch Balancer, Replacing It With a Per-sector Fee and Removing Gas-limited Constraints ## Simple Summary This FIP proposes to: @@ -102,7 +102,7 @@ pub struct State { // existing fields ... /// The epoch when average daily supply started being recorded. This is the activation epoch of - /// FIP-XXXX and is used for quantising epochs to their daily average record in the daily_supply + /// FIP-0100 and is used for quantising epochs to their daily average record in the daily_supply /// array. pub daily_supply_record_start: i64, diff --git a/README.md b/README.md index 2ece4bc5..4e3ea394 100644 --- a/README.md +++ b/README.md @@ -134,4 +134,4 @@ This improvement protocol helps achieve that objective for all members of the Fi | [0096](https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0096.md) | Convert fundraising remainder address(es) to keyless account actor(s) | FIP | @Fatman13 | Draft | | [0097](https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0097.md) | Add Support for EIP-1153 (Transient Storage) in the FEVM | FIP | Michael Seiler (@snissn), Steven Allen (@stebalien) | Accepted | | [0098](https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0098.md) | Simplify termination fee calculation to a fixed percentage of initial pledge | FIP | Jonathan Schwartz (@Schwartz10), Alex North (@anorth), Jim Pick (@jimpick) | Last Call | -| [xxxx](https://github.com/filecoin-project/FIPs/blob/irenegia-removeBatchBalancer/FIPS/fip-removeBatchBalancer.md) | Removing Batch Balancer, Replacing It With a Per-sector Fee and Removing Gas-limited Constraints | FIP | irene (@irenegia), AX (@AxCortesCubero), rvagg (@rvagg), molly (@momack2), kiran (@kkarrancsu)| Draft | +| [0100](https://github.com/filecoin-project/FIPs/blob/irenegia-removeBatchBalancer/FIPS/fip-removeBatchBalancer.md) | Removing Batch Balancer, Replacing It With a Per-sector Fee and Removing Gas-limited Constraints | FIP | irene (@irenegia), AX (@AxCortesCubero), rvagg (@rvagg), molly (@momack2), kiran (@kkarrancsu)| Draft | diff --git a/resources/fip-replaceBatchBalancer/FIPxxxxAppendix.md b/resources/fip-replaceBatchBalancer/FIPxxxxAppendix.md index 4b892468..10789269 100644 --- a/resources/fip-replaceBatchBalancer/FIPxxxxAppendix.md +++ b/resources/fip-replaceBatchBalancer/FIPxxxxAppendix.md @@ -1,6 +1,6 @@ ## Appendix -This document describes simulations related to FIPxxxx: "Removing Batch Balancer, Replacing It With a Per-sector Fee and Removing Gas-limited Constraints". +This document describes simulations related to FIP-0100: "Removing Batch Balancer, Replacing It With a Per-sector Fee and Removing Gas-limited Constraints". ### Simulation Methodology From 836ead8309bee5ffa216cc07bf4ae6b61425a700 Mon Sep 17 00:00:00 2001 From: irene <23217773+irenegia@users.noreply.github.com> Date: Wed, 12 Feb 2025 11:36:39 +0100 Subject: [PATCH 15/27] Update fip-removeBatchBalancer.md per sector fee description improved, fee paid at termination removed --- FIPS/fip-removeBatchBalancer.md | 14 +++++--------- 1 file changed, 5 insertions(+), 9 deletions(-) diff --git a/FIPS/fip-removeBatchBalancer.md b/FIPS/fip-removeBatchBalancer.md index 4ca85aba..4f70ed82 100644 --- a/FIPS/fip-removeBatchBalancer.md +++ b/FIPS/fip-removeBatchBalancer.md @@ -60,16 +60,12 @@ We propose a replacement mechanism that preserves these effects while adhering t **Proposal Details**: We introduce a per-sector fee, whose value is proportional to a fixed fraction of the circulating supply and to the sector duration. To prevent this fee from becoming a significant upfront cost that could hinder onboarding, we propose daily payments instead of an upfront fee. Moreover, as a safety measure for the high-growth scenarios, we propose capping the daily payment at a fixed percentage of the daily expected per-sector block reward. -More in details: at provecommit time we compute the value +More in details: - dailyFee = k * CS(t) -where `k = 7.4 E-15` is a system constant and `t` is the sector activation epoch. Then, we cap it using the `expected_day_reward` value that is currently already computed as part of the onchain sector info [link](https://github.com/filecoin-project/builtin-actors/blob/5aad41bfa29d8eab78f91eb5c82a03466c6062d2/actors/miner/src/types.rs#L447). That is, we compute: - - dailyPayment = min (dailyFee, m * expected_day_reward) -where `m= 0.5` is another system constant. Then the daily payment is due everyday until sector expiration for each new sector onboarded after this FIP is deployed. In particular: -- Even if a sector becomes faulty for the day, the payment is due. In other words, the dailyPayment is paid at windowPoSt time for all sectors in one the following state: active, faulty, recovered; -- The total fee per sector over its full sector lifetime is: `sectorFee = dailyPayment * sectorDurationInDays`. If a sector is terminated, the remaining of `sectorFee` gets computed and paid at termination (paid together with termination fee); -- If a sector is extended or updated, the dailyFee is not changed but the cap is recompute considering the upated value of `expected_day_reward` (and therefore the dailyPayment is updated). The sector will keep paying dailyPayment for the extended lifetime. +- At provecommit time, we compute the value `dailyFee = k * CS(t)`, where `k = 7.4 E-15` is a system constant and `t` is the sector activation epoch. The `dailyFee` value is stored but no payment is due at provecommit time. +- Then, during each windowPoSt, we compute: `dailyPayment = min (dailyFee, m * expected_day_reward)`, where `m= 0.5` is another system constant and `expected_day_reward` is the updated value for the daily expected per-sector block reward. The `dailyPayment` value is burnt. This happens for each sector assigned to the windowPoSt deadline and onboarded after this FIP is deployed. Note that the payment is due for sectors in any non-exparing state (active, faulty and in recovery). +- If a sector is extended or updated, the `dailyFee` value is not changed but the cap will be computed considering the updated value of `expected_day_reward` (and therefore the `dailyPayment` is updated). The sector will keep paying dailyPayment for the extended duration. +- When the sector expires or gets terminated, then the daily at windowPoSt payments stop ### Gas-limited constraints From a15afd9ee311d1d1fed9ee2256d189fe27107644 Mon Sep 17 00:00:00 2001 From: Rod Vagg Date: Thu, 13 Feb 2025 17:47:07 +1100 Subject: [PATCH 16/27] Rename to 0100 --- FIPS/{fip-removeBatchBalancer.md => fip-0100.md} | 0 README.md | 2 +- 2 files changed, 1 insertion(+), 1 deletion(-) rename FIPS/{fip-removeBatchBalancer.md => fip-0100.md} (100%) diff --git a/FIPS/fip-removeBatchBalancer.md b/FIPS/fip-0100.md similarity index 100% rename from FIPS/fip-removeBatchBalancer.md rename to FIPS/fip-0100.md diff --git a/README.md b/README.md index 4e3ea394..cf797aac 100644 --- a/README.md +++ b/README.md @@ -134,4 +134,4 @@ This improvement protocol helps achieve that objective for all members of the Fi | [0096](https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0096.md) | Convert fundraising remainder address(es) to keyless account actor(s) | FIP | @Fatman13 | Draft | | [0097](https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0097.md) | Add Support for EIP-1153 (Transient Storage) in the FEVM | FIP | Michael Seiler (@snissn), Steven Allen (@stebalien) | Accepted | | [0098](https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0098.md) | Simplify termination fee calculation to a fixed percentage of initial pledge | FIP | Jonathan Schwartz (@Schwartz10), Alex North (@anorth), Jim Pick (@jimpick) | Last Call | -| [0100](https://github.com/filecoin-project/FIPs/blob/irenegia-removeBatchBalancer/FIPS/fip-removeBatchBalancer.md) | Removing Batch Balancer, Replacing It With a Per-sector Fee and Removing Gas-limited Constraints | FIP | irene (@irenegia), AX (@AxCortesCubero), rvagg (@rvagg), molly (@momack2), kiran (@kkarrancsu)| Draft | +| [0100](https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0100.md) | Removing Batch Balancer, Replacing It With a Per-sector Fee and Removing Gas-limited Constraints | FIP | irene (@irenegia), AX (@AxCortesCubero), rvagg (@rvagg), molly (@momack2), kiran (@kkarrancsu)| Draft | From 614839b5d49e558592e1e24bac210ac50b1732f6 Mon Sep 17 00:00:00 2001 From: Rod Vagg Date: Thu, 13 Feb 2025 19:32:11 +1100 Subject: [PATCH 17/27] Update implementation details --- FIPS/fip-0100.md | 109 +++++++++++++++++------------------------------ 1 file changed, 38 insertions(+), 71 deletions(-) diff --git a/FIPS/fip-0100.md b/FIPS/fip-0100.md index 4f70ed82..e4b4368e 100644 --- a/FIPS/fip-0100.md +++ b/FIPS/fip-0100.md @@ -84,116 +84,83 @@ This FIP makes three main changes to the protocol: 2. Removes certain gas-limited protocol constraints that are no longer necessary 3. Introduces a new per-sector daily fee mechanism based on circulating supply and block rewards - ### Storage power actor -The storage power actor will be used to record a daily average of the circulating supply. This is achieved by incrementing a running total of circulating supply per epoch through the existing cron call. Once every 2880 epochs this will be divided and recorded in an AMT as the average circulating supply for that day period. Records will be indexed starting from `0` and incrementing `1` per day (creating an optimal AMT structure). - -_TODO: the bitwidth of the AMT will need to be decided, a value of 5 is proposed, for a branching factor of 32._ - -The power actor will also store a new field, set on activation of this FIP to the activation epoch, to record the collection start epoch. This value will be used to quantise down any requested epoch to the daily average value. +The storage power actor will be used to record a daily average of the circulating supply and to provide this to the sector commitment methods in order to record a `daily_fee` for each sector. This is achieved by incrementing a running total of circulating supply per epoch through the existing cron call. Once every 2880 epochs this will be divided and recorded as the reference circulating supply for the purpose of fee calculation for the next 24 hours when the next value will be recorded. The 24 hour period will be defined as any multiple of 2880 epochs. ```rust pub struct State { // existing fields ... - /// The epoch when average daily supply started being recorded. This is the activation epoch of - /// FIP-0100 and is used for quantising epochs to their daily average record in the daily_supply - /// array. - pub daily_supply_record_start: i64, - /// A running total for the current 24 hour period, incremented on each call from cron, and used /// to record the average value for the previous 24 hour period once a day. - pub daily_supply_total: TokenAmount, + pub daily_supply_accum: TokenAmount, - /// Average circulating supply for each 24 hour period since the start of recording as defined by - /// daily_supply_record_start, indexed by day, starting from 0 as the first 24 hour period - /// recorded after daily_supply_record_start and incrementing by 1 each day. - pub daily_supply: Cid, // Array (AMT[TokenAmount]) + /// Average circulating supply for the last 24 hour period. This value is used for the basis of + /// fee calculation for the next 24 hour period. + pub daily_supply: TokenAmount, } ``` -In addition, a new method will be exposed to access the current root CID of the AMT so that another actor can load one or more arbitrary historical records. As the storage miner actor may need to look up many separate records when dealing with batches of sectors, it will be more efficient to pass the data structure rather than answer specific queries. +In addition, a new method will be exposed to access the current daily average circulating supply, which is required by the storage miner actor: ```rust -fn daily_supply_root(rt: &impl Runtime) -> Result +fn daily_supply(rt: &impl Runtime) -> Result ``` -A helper wrapper for the AMT that can be shared amongst actors to easily convert arbitrary epochs to daily average values is suggested. - #### Migration -At activation of this FIP, a new layout for the storage power actor state will be introduced, adding 3 new fields. The existing state will be migrated to the new layout by copying the existing fields. +At activation of this FIP, a new schema for the storage power actor state will be introduced, adding 2 new fields. The existing state will be migrated to the new schema by copying the existing fields. + +* `daily_supply_accum` will be set to zero +* `daily_supply` will be set to zero -* `daily_supply_record_start` will be set to the activation epoch of this FIP -* `daily_supply_total` will be set to zero -* `daily_supply` will be set to the empty AMT for the specified bitwidth +Note that because the `daily_supply` value begins at zero, the first 24 hour period will result in a circulating supply of zero, leading to a `daily_fee` of zero for all sectors onboarded during this period. ### Storage miner actor #### Removal of gas-limited constraints -The following constants and their use will be removed: +The following constants and their use will be removed from the storage miner actor: - `PRE_COMMIT_SECTOR_BATCH_MAX_SIZE` - used by `PreCommitSectorBatch2` - `PROVE_REPLICA_UPDATES_MAX_SIZE` - used by both `ProveReplicaUpdates` and `ProveReplicaUpdates3` - `DECLARATIONS_MAX` - used by `TerminateSectors`, `DeclareFaults` and `DeclareFaultsRecovered` #### Removal of aggregate fee -- Remove the burning of `aggregate_fee` from `PreCommitSectorBatch2`. -- Remove the burning of `aggregate_fee` from `ProveCommitAggregate`, `ProveCommitSectorsNI`, `ProveCommitSectors3` -- Removal of `aggregate_fee` calculation methods and associated constants, including `ESTIMATED_SINGLE_PROVE_COMMIT_GAS_USAGE` and `ESTIMATED_SINGLE_PRE_COMMIT_GAS_USAGE` +Aggregate fee functionality and constants will be removed from the storage miner actor. This includes the following changes: + - Remove the burning of `aggregate_fee` from `PreCommitSectorBatch2`. + - Remove the burning of `aggregate_fee` from `ProveCommitAggregate`, `ProveCommitSectorsNI`, `ProveCommitSectors3` + - Removal of `aggregate_fee` calculation methods and associated constants, including `ESTIMATED_SINGLE_PROVE_COMMIT_GAS_USAGE` and `ESTIMATED_SINGLE_PRE_COMMIT_GAS_USAGE` #### Fee implementation -Fees are payable daily at WindowPoSt for the sectors being proven. As this operation aims to be gas-efficient, the introduction of a fee mechanism should not add unnecessary additional load `SubmitWindowedPoSt`. Since WindowPoSt addresses sectors grouped by partition, a total daily fee amount for an entire partition will be stored in the root of the partition's state. This value is summed across the partitions included in a successful `SubmitWindowedPoSt` message and deducted from the miner actor. No special handling is added for skipped sectors in a WindowPoSt. +A daily fee value is calculated per-sector at time of onboarding. This value is stored as `daily_fee` in the `SectorOnChainInfo` and an aggregated `daily_fee` value is also stored in each `Deadline`. The fee is deducted from the miner actor's balance, processed by cron at the end of each deadline, where the fee is deducted in a similar manner to fault fees. Upon sector termination, the `daily_fee` recorded in the sector's `Deadline` is adjusted to remove the sector's fee. -TODO (should we do it here?): It is within WindowPoSt that the cap on the daily fee is enforced. The cap is calculated as a fixed percentage of the expected daily block reward. This is calculated by using the total power from storage power actor, and current epoch block reward from the reward actor combined with the QaP recorded for the partition. +The fee is calculated as a fixed fraction of the circulating supply, as per the formula above, at the time of sector activation. This value is provided by the power actor which will be responsible for providing a smoothed average of the circulating supply for the previous 24 hour period. Upon payment, the estimated block reward for a `Deadline`s power is calculated and used to apply a maximum cap, as per the formula above. Efficient application of the cap will require also adding a new power field to the `Deadline` as a sum of all the power its partitions. + +Fee deduction will be handled in the existing `handle_proving_deadline()` function which is called from cron. It will need to make use of the `ThisEpochReward` method from the reward actor and `CurrentTotalPower` method of the power actor in order to calculate and apply the expected 24h block reward cap to the fee for the amount of power in the deadline. + +The `Deadline` struct will be extended with `live_power` and `daily_fee` fields: ```rust -pub struct Partition { +pub struct Deadline { // existing fields ... - /// Subset of sectors that have been terminated but their fee has not yet been removed from the - /// total daily fee for this partition. Reconciliation of the fee for these sectors will be - /// performed at the time the fee is payable. - pub fee_deductions: BitField, + /// Power of not-yet-terminated sectors (incl faulty & unproven) assigned to this deadline. + pub live_power: PowerPair, - /// The total fee payable per day for this partition, this represents a sum of the daily fee - /// amounts for all sectors in this partition. + /// The total fee payable per day for this deadline, this represents a sum of the daily fee + /// amounts for all sectors assigned to this deadline. pub daily_fee: TokenAmount, } ``` -Fees are calculated for each sector at multiple points in their lifecycle and the `daily_fee` value in their assigned partition is updated accordingly. The fee is calculated as a fixed fraction of the circulating supply at the time of sector activation. The circulating supply value is taken from the record in the power actor for the day of sector activation; the last average circulating supply value recorded before the sector activation epoch is used. This same value can be looked up at any future point in time to calculate the fee for potential adjustments. - -**Sector commitments**, performed with each of `ProveCommitSectors3`, `ProveCommitAggregate` and `ProveCommitSectorsNI` the fee is for each sector committed is calculated at the time of the message and added to the existing `daily_fee` total recorded in the partition the sector is assigned to. - -Faults have no impact on a partition's `daily_fee` value. - -**Early terminations**, both automatic and manual, will result in a reduction of the partition's `daily_fee` value for the sectors being terminated. Early terminations are currently handled at the end of each proving deadline via cron, and for efficiency, sector state is not fetched, but sector numbers and power adjustments are memoised per partition and reconciled later. Fee adjustment for early termination will also be memoised and reconciled at the time the fee is payable. When a sector number is added to the partition's `terminated` bitfield, the sector number will also be added to the `fee_deductions` bitfield. The `fee_deductions` bitfield will be used to track the sectors that have been terminated but their fee has not yet been removed from the total `daily_fee` for this partition. `fee_deductions` does not need to be used for any functionality other than fee reconciliation (although it will be useful for external inspection where total partition fee amounts are required). +The `SectorOnChainInfo` struct will be extended to include a new `daily_fee` field which will be used to store the daily fee for the sector. This value will be set at the time of sector activation and will be used to calculate the daily fee for the sector for the duration of its lifetime. This value will be zero for sectors onboarded prior to activation of this FIP. -Reconciliation of the fee for these sectors will be performed at WindowPoSt via a `Deadline`'s `record_proven_sectors`. Each `Partition` will be asked for its fee amount via a new method and it is within this method that any sector's numbers recorded in `fee_deductions` will have their fee recalculated and deducted from the total `daily_fee` for the partition. The `fee_deductions` bitfield will be cleared after reconciliation. `daily_fee` is reduced by recalculating the sector's daily fee by using the activation epoch and average circulating supply value for that epoch as described above. In this way, addition and removal of sectors from a partition will adjust the daily fee by the correct amount, resulting in no over or undercharging. +At the time of this proposal, there are approximately 650M sectors on chain. The expense of migrating and additional bytes used to store zero values for old sectors is not insignificant. Therefore it is proposed to perform a _lazy migration_ where existing `SectorOnChainInfo` objects are left alone and this new field is only added to new sectors, and sectors which are updated (for any reason). This means that reading `SectorOnChainInfo` blocks from state will support two forms: a 15 field version (old) and a 16 field version (new `daily_fee` field). The old version will instantiate with a zero value for `daily_fee` and this field will be written whenever a `SectorOnChainInfo` object is written to state, regardless of whether it contains a zero or non-zero value. i.e. reads will support 15 or 16 fields, writes will always write 16 fields. -**Partition compaction** will necessarily involve recalculation of a partition-level `daily_fee` using each sector in the partition. Per-sector daily fees will be recalculated using the activation epoch and average circulating supply value for that epoch as described above. The partition's `daily_fee` will be updated to reflect the sum of the daily fees for all sectors in the partition. Any outstanding `fee_deductions` will be recalculated and deducted from the total `daily_fee` for the partition. - -***TODO***: **Balance withdrawal**: _is this allowed while there are `fee_deductions` in place? If not, do we need `fee_deductions` at the top-level to indicate which deadlines have deductions that need to be reconciled? Do we just let withdrawals proceed and if they don't have balance left to cover the fees they fail post?_ - -#### Migration - -At activation of this FIP, a new layout for the `Partition` block type will be introduced, adding a new field, `daily_fee: TokenAmount`. A migration will be performed on all partitions, within all deadlines, across all miner actors. At the time of writing there are 293,000 partitions on the chain, distributed across the 695,000 miner actors. Each of these will need to be migrated to the new format. The migration will be performed by loading the existing partition state, copying the existing fields to the new format, and setting the `daily_fee` field to zero. The new format will be used for all new partitions created after the activation of this FIP. - -#### Alternative fee implementation - -_This section is provided temporarily for discussion purposes and will either be removed or used to rework the above section once the final fee implementation is decided. Acceptance of this design will result in the removal of proposed changes to the storage power actor above._ - -_Description of `daily_fee` accumulation in the partition and its use on WindowPoSt remains the same._ - -The `SectorOnChainInfo` struct will be extended to include a new field `daily_fee` which will be used to store the daily fee for the sector. This value will be updated at the time of sector activation and will be used to calculate the daily fee for the sector for the duration of its lifetime. - -Due to the number of sectors already on chain (currently 645,600,000) and the expense of migrating to a new format to add this field, the existing block layout will continue to be supported, which is represented as a 15 element array, with one element per field of the struct. The new field will be added as the 16th element of the array. Loading and decoding any `SectorOnChainInfo` block will be able to handle both the old and new formats. Any writes by the builtin actors will strictly use the new format. - -A future migration will be proposed to unify the format, however this is deferred until additional sector clean-up activities can take place to reduce the number of unused sectors on chain, thereby reducing the cost of migration. +A future migration may be proposed to unify the format, or introduce an explicit schema versioning mechanism, however this will likely be deferred until additional sector clean-up activities can take place to reduce the number of unused sectors on chain, thereby reducing the cost of migration. ```rust pub struct SectorOnChainInfo { @@ -203,24 +170,24 @@ pub struct SectorOnChainInfo { /// sector activation and is used to calculate the daily fee for the sector for the duration of /// its lifetime. /// This field is not included in the serialised form of the struct prior to the activation of - /// FIP-XXXX, and is added as the 16th element of the array after that point only for new sectors + /// FIP-0100, and is added as the 16th element of the array after that point only for new sectors /// or sectors that are updated after that point. For old sectors, the value of this field will /// always be zero. pub daily_fee: TokenAmount, } ``` -Fees are calculated for each sector at various points in their lifecycle and the `daily_fee` value is stored in the sector's `SectorOnChainInfo` and the `daily_fee` value in their assigned partition is updated accordingly. The fee is calculated as a fixed fraction of the circulating supply at the time of sector activation. The circulating supply value is available at the time of sector onboarding as it is used for pledge calculation. +**Sector commitments**: At each of `ProveCommitSectors3`, `ProveCommitAggregate` and `ProveCommitSectorsNI`, the `daily_fee` is for each sector is calculated and recorded in `SectorOnChainInfo`. It is also added to the existing `daily_fee` total recorded in the `Deadline` the sector is assigned to. -For each of `ProveCommitSectors3`, `ProveCommitAggregate` and `ProveCommitSectorsNI` the fee is for each sector committed is calculated at the time of the message. +**Faults**: have no impact on a sector or deadline's `daily_fee` value. -Faults have no impact on a partition's `daily_fee` value. +**Early terminations**: both automatic and manual, will result in a reduction of a `Deadline`'s `daily_fee` value for the sectors being terminated. -Early terminations, both automatic and manual, will result in a reduction of the partition's `daily_fee` value for the sectors being terminated. `daily_fee` is reduced by the daily fee recalculated for the sector by using the activation epoch and average circulating supply value for that epoch as described above. In this way, addition and removal of sectors from a partition will adjust the daily fee by the correct amount, resulting in no over or undercharging. +#### Migration -##### Migration +At activation of this FIP, a new schema for the `Deadline` block type will be introduced, adding two new fields: `live_power: PowerPair` and `daily_fee: TokenAmount`. A migration will be performed on all deadlines, across all miner actors. As the majority of deadlines referenced on chain are _the_ empty `Deadline` block, a CID for this singleton block may be used to speed up migration where the CID for the previous form's `Deadline` block is encountered. All `daily_fee` values will be set to zero at migration and the `live_power` will be calculated as a sum of the `live_power` in each of the `Partition`s assigned to the `Deadline`. -There is no migration required for this implementation as the existing format will continue to be supported. The new field will be added to the sector state as sectors are updated or new sectors are created after the activation of this FIP. +No migration is necessary for `SectorOnChainInfo` as the lazy migration strategy is employed. ### Special handling for Calibration network From 50ee35a3db49cf513360d17449f775b8f063b60f Mon Sep 17 00:00:00 2001 From: Rod Vagg Date: Thu, 13 Feb 2025 20:57:18 +1100 Subject: [PATCH 18/27] Remove power actor changes, clean-up and clarify details --- FIPS/fip-0100.md | 162 ++++++++++++++++++++--------------------------- 1 file changed, 70 insertions(+), 92 deletions(-) diff --git a/FIPS/fip-0100.md b/FIPS/fip-0100.md index e4b4368e..be71fc81 100644 --- a/FIPS/fip-0100.md +++ b/FIPS/fip-0100.md @@ -1,8 +1,8 @@ --- fip: "0100" title: Removing Batch Balancer, Replacing It With a Per-sector Fee and Removing Gas-limited Constraints -author: irene (@irenegia), AX (@AxCortesCubero), rvagg (@rvagg), molly (@momack2), kiran (@kkarrancsu) -Discussions-to: https://github.com/filecoin-project/FIPs/discussions/1092 and https://github.com/filecoin-project/FIPs/discussions/1105 +author: irene (@irenegia), AX (@AxCortesCubero), rvagg (@rvagg), molly (@momack2), kiran (@kkarrancsu) +Discussions-to: https://github.com/filecoin-project/FIPs/discussions/1092 and https://github.com/filecoin-project/FIPs/discussions/1105 status: Draft type: Technical category: Core @@ -12,47 +12,59 @@ Created: 2025-02-04 # FIP-0100: Removing Batch Balancer, Replacing It With a Per-sector Fee and Removing Gas-limited Constraints ## Simple Summary + This FIP proposes to: - - Remove the batch fee from all precommit and provecommit methods to incentivize sector batching during the precommit step and proof aggregation during the provecommit step; + + - Remove the batch fee from all PreCommit and ProveCommit methods to incentivize sector batching during the PreCommit step and proof aggregation during the ProveCommit step; - Introduce a per sector fee to replace the batch balancer cost structure with a more stable mechanism that supports the long-term economic sustainability of the Filecoin network; - Remove protocol constraints that are no longer necessary since the introduction of proper gas accounting. ## Abstract + This FIP consists of three changes: - - First, a straightforward way to reduce gas consumption is through sector batching and proof aggregation. Storage providers (SPs) should be incentivized to batch sectors at precommit and aggregate proofs at prove commit as much as possible. Currently, the efficiency of these processes is governed by the batch balancer mechanism, which is tied to the base fee and comes with several limitations. This FIP proposes the removal of the batch balancer (see details below) to enable full adoption of batching and aggregation, thereby enhancing scalability and onboarding growth. + + - First, a straightforward way to reduce gas consumption is through sector batching and proof aggregation. Storage providers (SPs) should be incentivized to batch sectors at PreCommit and aggregate proofs at prove commit as much as possible. Currently, the efficiency of these processes is governed by the batch balancer mechanism, which is tied to the base fee and comes with several limitations. This FIP proposes the removal of the batch balancer (see details below) to enable full adoption of batching and aggregation, thereby enhancing scalability and onboarding growth. - Secondly, the batch balancer was introduced to address a misalignment in the Filecoin economy. Beyond blockchain execution, the Filecoin network provides SPs with a storage-auditing service through on-chain verification of proofs. While gas fees primarily account for execution costs, there is no dedicated system that properly captures the network’s storage-auditing value. The batch balancer partially addressed this gap, although attempted to achieve value capture through the gas mechanism which is primarily a means of constraining chain validation costs. With the removal of the batch balancer, a replacement mechanism is needed. This FIP proposes a better, more effective system to achieve that goal (see details below). - Finally, this FIP also includes the removal of gas-limited protocol constraints which are no longer needed. However, these modifications are not the primary focus of the proposal. Eliminating these constraints aims to simplify the protocol, and remove any unintentional network growth constraints. ## Change Motivation -### Precommit batch fee removed -Due to the batch fee, currently precommit batching is only rational (ie, cost-effective) when the base fee exceeds 0.09 nanoFIL. Removing this fee will eliminate this obstacle, enabling more batching and therefore gas saving. +### PreCommit batch fee removed + +Due to the batch fee, currently PreCommit batching is only rational (ie, cost-effective) when the base fee exceeds 0.09 nanoFIL. Removing this fee will eliminate this obstacle, enabling more batching and therefore gas saving. + To have a rough estimate of the saving, we can compare two PreCommitSector messages posted by the same miner actor with little difference in the number of sectors when the message landed. + - [Msg 1](https://www.filutils.com/en/message/bafy2bzacebzacw3b7ymcwukk2uimahiebpke65utbfn3srgslzj5w3hh234x6): PreCommiSectorBatch2 for 1 sector : 16.7 M gas used -- [Msg 2](https://www.filutils.com/en/message/bafy2bzacebdqgivdbxzj25exae55j7vjasos45lvj4bzi6fj5oaya4rqwxrf6): PreCommitSectorBatch2 for 4 sectors): 18.6 M/ 4 = 4.6 M per sector (3.6x smaller) +- [Msg 2](https://www.filutils.com/en/message/bafy2bzacebdqgivdbxzj25exae55j7vjasos45lvj4bzi6fj5oaya4rqwxrf6): PreCommitSectorBatch2 for 4 sectors): 18.6 M/ 4 = 4.6 M per sector (3.6x smaller) + + +### ProveCommit batch fee removed +There are two options for `ProveCommitSector3`: (1) "simple" batching as in PreCommit (ie, one message for ≥ 2 sectors) where there is a PoRep proof for each sector in the batched message, and (2) aggregating proofs of multiple sectors and post in one message. -### Provecommit batch fee removed -There are two options for `ProveCommitSector3`: (1) "simple" batching as in precommit (ie, one message for ≥ 2 sectors) where there is a PoRep proof for each sector in the batched message, and (2) aggregating proofs of multiple sectors and post in one message. -Batching for provecommit is already rational, as the batch fee applies only to aggregated proofs (opposed to precommit, where the batch balancer applies to batching). -On the other hand, aggregation is rational only when the base fee exceeds 0.065 nanoFIL due to the batch fee applied to aggregation. Removing this fee too will eliminate this obstacle, enabling more proof aggregation and therefore gas saving. +Batching for ProveCommit is already rational, as the batch fee applies only to aggregated proofs (opposed to PreCommit, where the batch balancer applies to batching). +On the other hand, aggregation is rational only when the base fee exceeds 0.065 nanoFIL due to the batch fee applied to aggregation. Removing this fee too will eliminate this obstacle, enabling more proof aggregation and therefore gas saving. To have a rough estimate of the saving, we can compare these `ProveCommitSector3` messages posted by the same miner actor with little difference in the number of sectors when the message landed[^*]. -- [Msg 1](https://www.filutils.com/en/message/bafy2bzacebshpv7afwnxph6l4jnbpwpqnss3cboyfvlualfrjbox76hojjnlo): ProveCommitSectors3 for 1 sector: 267.5 M + +- [Msg 1](https://www.filutils.com/en/message/bafy2bzacebshpv7afwnxph6l4jnbpwpqnss3cboyfvlualfrjbox76hojjnlo): ProveCommitSectors3 for 1 sector: 267.5 M - [Msg 2](https://www.filutils.com/en/message/bafy2bzacebd7ftq5lk4ikuif4j3xfwiabmla5bek3kuhn3k6x3obufxyzrs6y): ProveCommitSectors3 for 4 sectors, batched (no aggregation): 580 M/4 = 145 M per sector (1.85x smaller) - [Msg 3](https://www.filutils.com/en/message/bafy2bzacedezi6lm4warrfq2n6dxvpokowzt5isacbq2kojkz462yfpfq7lxm): ProveCommitSectors3 for 4 sectors, aggregated: 517.4 M/4 = 129.3 M per sector (2x smaller). -The same logic applies to `ProveCommitSectorsNI`, where we have the same two options as in `ProveCommitSector3`. +The same logic applies to `ProveCommitSectorsNI`, where we have the same two options as in `ProveCommitSector3`. TODO: add gas saving numbers for NI-PoRep. -[^*]: A bug is currently causing single proofs to be charged an incorrect amount of gas units. So we added the missing units (42M per proof) to msg1 and msg2 in order to provide the future correct estimates (the bug is planned to be fixed in nv25). See [here](https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0076.md) - +[^*]: A bug is currently causing single proofs (`VerifySeal`) to be charged an incorrect amount of gas units. So we added the missing units (42M per proof) to msg1 and msg2 in order to provide the future correct estimates (the bug is planned to be fixed in nv25). See [here](https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0076.md) ### Per-sector fee added + The batch balancer mechanism had several goals and effects. Among them, two key aspects were: (1) Creating a linear cost for onboarding storage in the presence of batching/aggregation and (2) Burning tokens to balance new token supply with network burn, ensuring value distribution among FIL holders and earners. + We propose a replacement mechanism that preserves these effects while adhering to the following design principles: + - Simplify the system to improve predictability. - Preserve and align network value accrual. - Avoid additional onboarding rate limits. @@ -60,18 +72,18 @@ We propose a replacement mechanism that preserves these effects while adhering t **Proposal Details**: We introduce a per-sector fee, whose value is proportional to a fixed fraction of the circulating supply and to the sector duration. To prevent this fee from becoming a significant upfront cost that could hinder onboarding, we propose daily payments instead of an upfront fee. Moreover, as a safety measure for the high-growth scenarios, we propose capping the daily payment at a fixed percentage of the daily expected per-sector block reward. -More in details: +More in details: -- At provecommit time, we compute the value `dailyFee = k * CS(t)`, where `k = 7.4 E-15` is a system constant and `t` is the sector activation epoch. The `dailyFee` value is stored but no payment is due at provecommit time. -- Then, during each windowPoSt, we compute: `dailyPayment = min (dailyFee, m * expected_day_reward)`, where `m= 0.5` is another system constant and `expected_day_reward` is the updated value for the daily expected per-sector block reward. The `dailyPayment` value is burnt. This happens for each sector assigned to the windowPoSt deadline and onboarded after this FIP is deployed. Note that the payment is due for sectors in any non-exparing state (active, faulty and in recovery). -- If a sector is extended or updated, the `dailyFee` value is not changed but the cap will be computed considering the updated value of `expected_day_reward` (and therefore the `dailyPayment` is updated). The sector will keep paying dailyPayment for the extended duration. -- When the sector expires or gets terminated, then the daily at windowPoSt payments stop +- At ProveCommit time, we compute the value `dailyFee = k * CS(t)`, where `k = 7.4 E-15` is a system constant and `t` is the sector activation epoch. The `dailyFee` value is stored but no payment is due at ProveCommit time. +- Then, at the end of each deadline, we compute: `dailyPayment = min (dailyFee, m * expected_day_reward)`, where `dailyFee` is a total for all sectors in the deadline, `m= 0.5` is another system constant and `expected_day_reward` is the updated value for the daily expected per-sector block reward for all sectors in the deadline. The `dailyPayment` value is burnt. This happens for each sector assigned to the deadline and onboarded after this FIP is deployed. Note that the payment is due for sectors in any non-exparing state (active, faulty and in recovery). +- If a sector is extended or updated, the `dailyFee` value is not changed but the cap will be computed considering the updated value of `expected_day_reward` (and therefore the `dailyPayment` is updated). The sector will keep paying `dailyPayment` for the extended duration. +- When the sector expires or gets terminated, the sector is no longer counted in the `dailyFee` value for the deadline. ### Gas-limited constraints Various protocol constraints that were previously necessary when there was no gas applied on actor computation are no longer necessary since the introduction of proper gas accounting with FVM (see [FIP-0032](./fip-0032.md)). This FIP proposes to remove the following constraints as they are no longer necessary in practice due to the gas mechanism being the primary constraint for computation: -* `PRE_COMMIT_SECTOR_BATCH_MAX_SIZE`: The maximum number of sector pre-commitments in a single batch. +* `PRE_COMMIT_SECTOR_BATCH_MAX_SIZE`: The maximum number of sector PreCommitments in a single batch. * `PROVE_REPLICA_UPDATES_MAX_SIZE`: The maximum number of sector replica updates in a single batch. * `DECLARATIONS_MAX`: Maximum number of unique "declarations" in batch operations (i.e. terminations, faults, recoveries). @@ -80,64 +92,30 @@ In most cases, users will be limited by the gas limit rather than these constrai ## Specification This FIP makes three main changes to the protocol: -1. Removes the batch balancer fee mechanism from sector pre-commit and prove-commit operations + +1. Removes the batch balancer fee mechanism from sector PreCommit and ProveCommit operations 2. Removes certain gas-limited protocol constraints that are no longer necessary 3. Introduces a new per-sector daily fee mechanism based on circulating supply and block rewards -### Storage power actor - -The storage power actor will be used to record a daily average of the circulating supply and to provide this to the sector commitment methods in order to record a `daily_fee` for each sector. This is achieved by incrementing a running total of circulating supply per epoch through the existing cron call. Once every 2880 epochs this will be divided and recorded as the reference circulating supply for the purpose of fee calculation for the next 24 hours when the next value will be recorded. The 24 hour period will be defined as any multiple of 2880 epochs. - -```rust -pub struct State { - // existing fields ... - - /// A running total for the current 24 hour period, incremented on each call from cron, and used - /// to record the average value for the previous 24 hour period once a day. - pub daily_supply_accum: TokenAmount, - - /// Average circulating supply for the last 24 hour period. This value is used for the basis of - /// fee calculation for the next 24 hour period. - pub daily_supply: TokenAmount, -} -``` - -In addition, a new method will be exposed to access the current daily average circulating supply, which is required by the storage miner actor: - -```rust -fn daily_supply(rt: &impl Runtime) -> Result -``` - -#### Migration - -At activation of this FIP, a new schema for the storage power actor state will be introduced, adding 2 new fields. The existing state will be migrated to the new schema by copying the existing fields. - -* `daily_supply_accum` will be set to zero -* `daily_supply` will be set to zero - -Note that because the `daily_supply` value begins at zero, the first 24 hour period will result in a circulating supply of zero, leading to a `daily_fee` of zero for all sectors onboarded during this period. - -### Storage miner actor - -#### Removal of gas-limited constraints +### Removal of gas-limited constraints The following constants and their use will be removed from the storage miner actor: - `PRE_COMMIT_SECTOR_BATCH_MAX_SIZE` - used by `PreCommitSectorBatch2` - `PROVE_REPLICA_UPDATES_MAX_SIZE` - used by both `ProveReplicaUpdates` and `ProveReplicaUpdates3` - `DECLARATIONS_MAX` - used by `TerminateSectors`, `DeclareFaults` and `DeclareFaultsRecovered` -#### Removal of aggregate fee +### Removal of aggregate fee Aggregate fee functionality and constants will be removed from the storage miner actor. This includes the following changes: - Remove the burning of `aggregate_fee` from `PreCommitSectorBatch2`. - Remove the burning of `aggregate_fee` from `ProveCommitAggregate`, `ProveCommitSectorsNI`, `ProveCommitSectors3` - Removal of `aggregate_fee` calculation methods and associated constants, including `ESTIMATED_SINGLE_PROVE_COMMIT_GAS_USAGE` and `ESTIMATED_SINGLE_PRE_COMMIT_GAS_USAGE` -#### Fee implementation +### Fee implementation A daily fee value is calculated per-sector at time of onboarding. This value is stored as `daily_fee` in the `SectorOnChainInfo` and an aggregated `daily_fee` value is also stored in each `Deadline`. The fee is deducted from the miner actor's balance, processed by cron at the end of each deadline, where the fee is deducted in a similar manner to fault fees. Upon sector termination, the `daily_fee` recorded in the sector's `Deadline` is adjusted to remove the sector's fee. -The fee is calculated as a fixed fraction of the circulating supply, as per the formula above, at the time of sector activation. This value is provided by the power actor which will be responsible for providing a smoothed average of the circulating supply for the previous 24 hour period. Upon payment, the estimated block reward for a `Deadline`s power is calculated and used to apply a maximum cap, as per the formula above. Efficient application of the cap will require also adding a new power field to the `Deadline` as a sum of all the power its partitions. +The fee is calculated as a fixed fraction of the circulating supply, as per the formula above, at the time of sector activation. This value is obtained from the existing `total_fil_circ_supply` system call which is also used for the Initial Pledge (IP) calculation. Upon payment, the estimated block reward for a `Deadline`s power is calculated and used to apply a maximum cap, as per the formula above. Efficient application of the cap will require also adding a new power field to the `Deadline` as a sum of all the power its partitions. Fee deduction will be handled in the existing `handle_proving_deadline()` function which is called from cron. It will need to make use of the `ThisEpochReward` method from the reward actor and `CurrentTotalPower` method of the power actor in order to calculate and apply the expected 24h block reward cap to the fee for the amount of power in the deadline. @@ -183,7 +161,7 @@ pub struct SectorOnChainInfo { **Early terminations**: both automatic and manual, will result in a reduction of a `Deadline`'s `daily_fee` value for the sectors being terminated. -#### Migration +### Migration At activation of this FIP, a new schema for the `Deadline` block type will be introduced, adding two new fields: `live_power: PowerPair` and `daily_fee: TokenAmount`. A migration will be performed on all deadlines, across all miner actors. As the majority of deadlines referenced on chain are _the_ empty `Deadline` block, a CID for this singleton block may be used to speed up migration where the CID for the previous form's `Deadline` block is encountered. All `daily_fee` values will be set to zero at migration and the `live_power` will be calculated as a sum of the `live_power` in each of the `Partition`s assigned to the `Deadline`. @@ -238,7 +216,9 @@ Calibnet currently executes with a circulating supply of `0` each epoch, regardl Because this FIP uses a fixed portion of current circulating supply to calculate the fee, Calibnet fees will always be `0`, which makes proper testing of the new functionality in live network conditions impossible. -To address this problem, this FIP will also adjust network parameters for Calibnet to ensure that the circulating supply is a reasonable and dynamic positive number. The core problem is the initial allocation of reserve funds which appears to have been set to 900M FIL. This was likely set to ensure a total supply of 2B FIL. Unfortunately, implementations use the same `InitialFilReserved` value as mainnet, 300M FIL. Filecoin node implementations compatible with Calibnet will be required to set their `InitialFilReserved` for Calibnet to `900,000,000` FIL from the activation epoch of this FIP. This will result in a more appropriate circulating supply calculation: +To address this problem, this FIP will also adjust network parameters for Calibnet to ensure that the circulating supply is a reasonable and dynamic positive number. The core problem is the initial allocation of reserve funds which appears to have been set to 900M FIL. This was likely set to ensure a total supply of 2B FIL. Unfortunately, implementations use the same `InitialFilReserved` value as mainnet, 300M FIL. + +Filecoin node implementations compatible with Calibnet will be required to set their `InitialFilReserved` for Calibnet (only) to `900,000,000` FIL **from the activation epoch of this FIP** (i.e. a value of `300,000,000` FIL must be used for epochs up until then, including when re-executing older tipsets). This will result in a more appropriate circulating supply calculation starting from the activation epoch of this FIP: | Metric | Mainnet (FIL) | Calibnet (FIL) | |-----------------------|--------------:|---------------:| @@ -247,19 +227,20 @@ To address this problem, this FIP will also adjust network parameters for Calibn | `FilCirculating` | 686,539,216 | 386,866,636 | ## Design Rationale + We aimed for a design that is simple to understand and model, and relatively simple to implement. With this in mind, we explored the following fee structures: - **Upfront Payment vs. Ongoing Payment**: The first offers better predictability, while the second reduces the risk of creating an entry barrier. With this FIP, we chose a hybrid approach that captures the benefits of both by computing the fee upfront for predictability, but allowing it to be paid daily over sector lifetime instead of as a lump sum upfront. -- **Flat Fee vs. Dynamic Fee**: A fixed per-sector fee provides predictability and consistency, while a fluctuating fee based on network congestion, onboarding rate, or other variables better captures value when the network is actively providing a service. We chose a model where the fee is a fixed fraction of a quantity that adjusts to economic conditions. We evaluated the following economic indicators for determining the per-sector fee: Initial Pledge (IP), per-sector Block Reward (BR) and Circulating Supply (CS). - - The IP-based fee was discarded to avoid complex system dependencies, as changes to IP in future FIPs could unintentionally impact the per-sector fee. +- **Flat Fee vs. Dynamic Fee**: A fixed per-sector fee provides predictability and consistency, while a fluctuating fee based on network congestion, onboarding rate, or other variables better captures value when the network is actively providing a service. We chose a model where the fee is a fixed fraction of a quantity that adjusts to economic conditions. We evaluated the following economic indicators for determining the per-sector fee: Initial Pledge (IP), per-sector Block Reward (BR) and Circulating Supply (CS). + - The IP-based fee was discarded to avoid complex system dependencies, as changes to IP in future FIPs could unintentionally impact the per-sector fee. - The BR-based fee was discarded because the fee-to-reward ratio did not adjust properly to network growth, leading to high fees even when onboarding demand was low. See [here](https://github.com/filecoin-project/FIPs/blob/irenegia-removeBatchBalancer/resources/fip-replaceBatchBalancer/FIPxxxxAppendix.md) for more details. - - CS was ultimately chosen because it normalizes fees relative to the Filecoin economy, ensuring both adaptability and predictability. + - CS was ultimately chosen because it normalizes fees relative to the Filecoin economy, ensuring both adaptability and predictability. We reached this conclusion through simulation-based analysis, modeling the impact of fees under different network conditions. Specifically, we evaluated multiple input trajectories: 0.5×, 0.75×, 1×, and 2× the current onboarding, renewal, and FIL+ rates. Since both renewals and FIL+ are near 100%, we capped them at their current maximum (see Fig. 1).
-

Fig 1: Network state evolution for each input trajectory. +

Fig 1: Network state evolution for each input trajectory.

@@ -280,52 +261,49 @@ This FIP modifies actor behavior and will require a new Filecoin network version ### builtin-actors -Many of the test scenarios outlined below already exist within the test suite for builtin-actors. Ensuring that all of the various cases, particularly edge-cases, are covered will be important to ensure that the new fee mechanism is correctly implemented and behaves as expected. In addition, any existing test scenarios that test sector lifecycles should be updated to include invariants that check the new fee mechanism: that it is correctly calculated, tallied in the partition, remains correct over time, is correctly deducted at WindowPoSt time, is correctly capped and is correctly adjusted for terminations. +Many of the test scenarios outlined below already exist within the test suite for builtin-actors. Ensuring that all of the various cases, particularly edge-cases, are covered will be important to ensure that the new fee mechanism is correctly implemented and behaves as expected. In addition, any existing test scenarios that test sector lifecycles should be updated to include invariants that check the new fee mechanism: that it is correctly calculated, tallied in the partition, remains correct over time, is correctly deducted in `handle_proving_deadline()`, is correctly capped and is correctly adjusted for terminations. * Test that the batch balancer fee is removed from `PreCommitSectorBatch2` and `ProveCommitAggregate`, `ProveCommitSectorsNI`, `ProveCommitSectors3` * Test that the gas-limited constraints are removed from the protocol -* Test that the power actor correctly records the daily average circulating supply - both in per-epoch increments and per-day averages recorded in the AMT - * Test that the power actor can provide the correct AMT root CID for the circulating supply average data * Test that the per-sector fee is correctly calculated and added to the respective partition's `daily_fee` value when using `ProveCommitAggregate`, `ProveCommitSectorsNI`, `ProveCommitSectors3` * Tests should cover different batching variations * Test that `ProveReplicaUpdates` and `ProveReplicaUpdates3` do not have an impact on the fee mechanism -* Test that the per-sector fee is correctly charged at WindowPoSt time for all sectors in the active, faulty, and recovered states +* Test that the per-sector fee is correctly charged at the end of each deadline for all sectors in the active, faulty, and recovered states * Tests should cover different batching variations -* Test that manual early terminations correctly adjust the partition's `daily_fee` value at the next WindowPoSt -* Test that automatic early terminations correctly adjust the partition's `daily_fee` value at the next WindowPoSt -* Test that sector expiration correctly adjusts the partition's `daily_fee` value at the next WindowPoSt -* Test that the fee is correctly capped at the expected daily block reward at WindowPoSt time -* Test that partition compaction correctly recalculates the `daily_fee` value for each partition +* Test that manual early terminations correctly adjust the deadline's `daily_fee` +* Test that automatic early terminations correctly adjust the deadline's `daily_fee` +* Test that sector expiration correctly adjusts the deadline's `daily_fee` +* Test that the fee is correctly capped at the expected daily block reward at the time it is paid ### Calibration network Once Calibnet is upgraded, functional tests should be performed that cover: * Ensure that the circulating supply is a reasonable and dynamic positive number -* Ensure that the power actor is correctly recording the daily average circulating supply * Onboarding new sectors with `PreCommitSectorBatch2` and `ProveCommitAggregate`, `ProveCommitSectors3` (and `ProveCommitSectorsNI` if possible) and: * observing that the batch balancer fee is not applied - * observing partition state to ensure that the new fee mechanism is correctly implemented and behaves as expected -* Observing that the per-sector fee is correctly charged at WindowPoSt time for all sectors in the active, faulty, and recovered states -* Observing that manual early terminations correctly adjust the partition's `daily_fee` value at the next WindowPoSt + * observing deadline state to ensure that the new fee mechanism is correctly implemented and behaves as expected +* Observing that the per-sector fee is correctly charged at the end of each deadline for all sectors in the active, faulty, and recovered states +* Observing that manual early terminations correctly adjust the deadline's `daily_fee` value ## Security Considerations + This FIP does not affect underlying proofs or protocol security. ## Incentive Considerations -Filecoin’s network revenue model is currently tied to the gas usage, and the most amount of gas is used by storage onboarding methods. This creates an incentive misalignment, where economic considerations lead to an incentive to not optimize the gas usage of onboarding methods, as this could hurt overall network revenue. +Filecoin’s network revenue model is currently tied to the gas usage, and the most amount of gas is used by storage onboarding methods. This creates an incentive misalignment, where economic considerations lead to an incentive to not optimize the gas usage of onboarding methods, as this could hurt overall network revenue. The Batch Balancer mechanism exemplifies this concept: batching and aggregating abilities were introduced to increase gas efficiency of onboarding methods, but the batch balancer mechanism restricted use of these abilities to when the network demand was high, to protect Filecoin’s economic interests. -This FIP fixes this incentive misalignment by disconnecting the network revenue from gas usage. The removal of the batch balancer allows for aggregation to occur at any level of demand regardless of network utilization rate (such as current levels of demand). We expect this to lead to a reduction of about ~30% in per-sector onboarding gas. This would in turn result in a drop in base fee, and therefore a drop in gas-based network revenue. +This FIP fixes this incentive misalignment by disconnecting the network revenue from gas usage. The removal of the batch balancer allows for aggregation to occur at any level of demand regardless of network utilization rate (such as current levels of demand). We expect this to lead to a reduction of about ~30% in per-sector onboarding gas. This would in turn result in a drop in base fee, and therefore a drop in gas-based network revenue. -The explicit per-sector fee introduced by this FIP allows us to remove the batch balancer, and support other future gas usage optimizations, without adding macroeconomic risk. +The explicit per-sector fee introduced by this FIP allows us to remove the batch balancer, and support other future gas usage optimizations, without adding macroeconomic risk. -The removal of batch balancer and associated reduction in gas fees are up-front improvements to SP costs designed to unblock and support faster data onboarding. This up-front cost-reduction is balanced by the per-sector fee that is charged gradually over the sector lifetime, starting at a small fraction of daily block rewards and adjusting dynamically based on network economic growth rate. +The removal of batch balancer and associated reduction in gas fees are up-front improvements to SP costs designed to unblock and support faster data onboarding. This up-front cost-reduction is balanced by the per-sector fee that is charged gradually over the sector lifetime, starting at a small fraction of daily block rewards and adjusting dynamically based on network economic growth rate. -## Product Considerations +## Product Considerations From a product perspective, this FIP is expected to: - Decouple gas fees (blockspace costs) from service fees (storage-auditing costs): This separation creates a more resilient system, reducing sensitivity to base fee spikes and ensuring predictable and fair costs for SPs. - Simplify cost analysis and calculations for SPs: The network will provide a smoother user experience by clearly distinguishing between congestion control (managed via base fees) and payments for services unrelated to congestion. @@ -334,13 +312,13 @@ From a product perspective, this FIP is expected to: - Remove gas-limited constraints: Eliminating these unnecessary constraints simplifies the protocol and allows gas mechanisms to serve as the primary network constraint, making the system more adaptive and flexible to changing conditions. ## Implementation -builtin-actors PRs: -* Remove batch fee for precommit and lower BatchBalancer (TBD) -* Implement windowPoSt per sector fee (TBD) -* [Remove gas-limited constraints](https://github.com/filecoin-project/builtin-actors/pull/1586) - -## Copyright -Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). +1. Remove the batch balancer fee mechanism from sector PreCommit and ProveCommit operations (TBD) +2. [Remove gas-limited protocol constraints that are no longer necessary](https://github.com/filecoin-project/builtin-actors/pull/1586) +3. Implement per-sector daily fee mechanism based on circulating supply and block rewards (TBD) +4. [Fix `VerifySeal` gas bug](https://github.com/filecoin-project/ref-fvm/pull/2103) +5. Fix circulating supply calculation on Calibnet (TBD) +## Copyright +Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). From 85e8a64f33e6073483b326a1a0ebdbd5b8590db7 Mon Sep 17 00:00:00 2001 From: MollyM Date: Thu, 13 Feb 2025 05:52:49 -0800 Subject: [PATCH 19/27] fix grammar nit --- FIPS/fip-0100.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/FIPS/fip-0100.md b/FIPS/fip-0100.md index be71fc81..29a9c541 100644 --- a/FIPS/fip-0100.md +++ b/FIPS/fip-0100.md @@ -155,7 +155,7 @@ pub struct SectorOnChainInfo { } ``` -**Sector commitments**: At each of `ProveCommitSectors3`, `ProveCommitAggregate` and `ProveCommitSectorsNI`, the `daily_fee` is for each sector is calculated and recorded in `SectorOnChainInfo`. It is also added to the existing `daily_fee` total recorded in the `Deadline` the sector is assigned to. +**Sector commitments**: At each of `ProveCommitSectors3`, `ProveCommitAggregate` and `ProveCommitSectorsNI`, the `daily_fee` for each sector is calculated and recorded in `SectorOnChainInfo`. It is also added to the existing `daily_fee` total recorded in the `Deadline` the sector is assigned to. **Faults**: have no impact on a sector or deadline's `daily_fee` value. From b8e48464aabf46fe9e9f71e30148bda80d67920c Mon Sep 17 00:00:00 2001 From: irene <23217773+irenegia@users.noreply.github.com> Date: Thu, 13 Feb 2025 15:12:27 +0100 Subject: [PATCH 20/27] Update fip-0100.md typos --- FIPS/fip-0100.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/FIPS/fip-0100.md b/FIPS/fip-0100.md index 29a9c541..81408ec5 100644 --- a/FIPS/fip-0100.md +++ b/FIPS/fip-0100.md @@ -55,7 +55,6 @@ To have a rough estimate of the saving, we can compare these `ProveCommitSector3 - [Msg 3](https://www.filutils.com/en/message/bafy2bzacedezi6lm4warrfq2n6dxvpokowzt5isacbq2kojkz462yfpfq7lxm): ProveCommitSectors3 for 4 sectors, aggregated: 517.4 M/4 = 129.3 M per sector (2x smaller). The same logic applies to `ProveCommitSectorsNI`, where we have the same two options as in `ProveCommitSector3`. -TODO: add gas saving numbers for NI-PoRep. [^*]: A bug is currently causing single proofs (`VerifySeal`) to be charged an incorrect amount of gas units. So we added the missing units (42M per proof) to msg1 and msg2 in order to provide the future correct estimates (the bug is planned to be fixed in nv25). See [here](https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0076.md) @@ -75,7 +74,7 @@ We propose a replacement mechanism that preserves these effects while adhering t More in details: - At ProveCommit time, we compute the value `dailyFee = k * CS(t)`, where `k = 7.4 E-15` is a system constant and `t` is the sector activation epoch. The `dailyFee` value is stored but no payment is due at ProveCommit time. -- Then, at the end of each deadline, we compute: `dailyPayment = min (dailyFee, m * expected_day_reward)`, where `dailyFee` is a total for all sectors in the deadline, `m= 0.5` is another system constant and `expected_day_reward` is the updated value for the daily expected per-sector block reward for all sectors in the deadline. The `dailyPayment` value is burnt. This happens for each sector assigned to the deadline and onboarded after this FIP is deployed. Note that the payment is due for sectors in any non-exparing state (active, faulty and in recovery). +- Then, at the end of each deadline, we compute: `dailyPayment = min (dailyFee, m * expected_day_reward)`, where `dailyFee` is a total for all sectors in the deadline, `m= 0.5` is another system constant and `expected_day_reward` is the updated value for the daily expected per-sector block reward for all sectors in the deadline. The `dailyPayment` value is burnt. This happens for each sector assigned to the deadline and onboarded after this FIP is deployed. Note that the payment is due for sectors in any non-expiring state (active, faulty and in recovery). - If a sector is extended or updated, the `dailyFee` value is not changed but the cap will be computed considering the updated value of `expected_day_reward` (and therefore the `dailyPayment` is updated). The sector will keep paying `dailyPayment` for the extended duration. - When the sector expires or gets terminated, the sector is no longer counted in the `dailyFee` value for the deadline. From d0ebcf38109ef8432658ed21fa49b9b149549791 Mon Sep 17 00:00:00 2001 From: irene <23217773+irenegia@users.noreply.github.com> Date: Thu, 13 Feb 2025 15:42:57 +0100 Subject: [PATCH 21/27] Update fip-0100.md --- FIPS/fip-0100.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/FIPS/fip-0100.md b/FIPS/fip-0100.md index 81408ec5..913908bd 100644 --- a/FIPS/fip-0100.md +++ b/FIPS/fip-0100.md @@ -229,7 +229,7 @@ Filecoin node implementations compatible with Calibnet will be required to set t We aimed for a design that is simple to understand and model, and relatively simple to implement. With this in mind, we explored the following fee structures: -- **Upfront Payment vs. Ongoing Payment**: The first offers better predictability, while the second reduces the risk of creating an entry barrier. With this FIP, we chose a hybrid approach that captures the benefits of both by computing the fee upfront for predictability, but allowing it to be paid daily over sector lifetime instead of as a lump sum upfront. +- **Upfront Payment vs. Ongoing Payment**: The first offers better predictability, while the second reduces the risk of creating an entry barrier and a disincentive for sectors with longer durations. With this FIP, we chose a hybrid approach that captures the benefits of both by computing the fee value upfront for predictability, but allowing it to be paid daily over sector lifetime instead of as a lump sum upfront. Moreover, the daily payment option allows us to easily implement a security measure by capping the daily value at a fixed fraction of the per-sector block reward. - **Flat Fee vs. Dynamic Fee**: A fixed per-sector fee provides predictability and consistency, while a fluctuating fee based on network congestion, onboarding rate, or other variables better captures value when the network is actively providing a service. We chose a model where the fee is a fixed fraction of a quantity that adjusts to economic conditions. We evaluated the following economic indicators for determining the per-sector fee: Initial Pledge (IP), per-sector Block Reward (BR) and Circulating Supply (CS). - The IP-based fee was discarded to avoid complex system dependencies, as changes to IP in future FIPs could unintentionally impact the per-sector fee. From 7c368f764baf15624d473ba8e5ef5acb8e65c2c1 Mon Sep 17 00:00:00 2001 From: irene <23217773+irenegia@users.noreply.github.com> Date: Thu, 13 Feb 2025 17:39:43 +0100 Subject: [PATCH 22/27] Update and rename FIPxxxxAppendix.md to FIP0100Appendix.md also updated the content in the appendix --- .../FIP0100Appendix.md | 106 ++++++++++++++++++ .../FIPxxxxAppendix.md | 83 -------------- 2 files changed, 106 insertions(+), 83 deletions(-) create mode 100644 resources/fip-replaceBatchBalancer/FIP0100Appendix.md delete mode 100644 resources/fip-replaceBatchBalancer/FIPxxxxAppendix.md diff --git a/resources/fip-replaceBatchBalancer/FIP0100Appendix.md b/resources/fip-replaceBatchBalancer/FIP0100Appendix.md new file mode 100644 index 00000000..d8b92fce --- /dev/null +++ b/resources/fip-replaceBatchBalancer/FIP0100Appendix.md @@ -0,0 +1,106 @@ +## Appendix + +This document describes simulations related to FIP-0100: "Removing Batch Balancer, Replacing It With a Per-sector Fee and Removing Gas-limited Constraints". + +### Simulation Methodology + +#### MechaFIL Introduction +Simulations are conducted using the mechafil package, which is a Python implementation of a mechanistic model of the Filecoin economy. The inputs to the simulation are: +- Raw byte onboarding (PiB/day) +- Renewal Rate (%) - the percentage of expiring power which is renewed +- Fil+ Rate (%) - the percentage of onboarded power which is deal power + +Given a trajectory of inputs, the model will forecast the future state of the network, including network power, circulating supply, locked, pledge, and other related metrics. + +Figure 1 shows the different onboarding trajectories that are simulated. Various input trajectories are considered - 0.5x, 0.75x, 1x, and 2x the current onboarding, renewal, and FIL+ rates. +Renewals and FIL+ are capped at their current maximum, since both values are close to 100%. +
+ +

Figure 1: Network state evolution for each input trajectory. +

+
+ +### Proof Fees Modeling + +#### Circulating Supply (CS) Based Fees +We can describe this fee as follows, for a sector onboarded at time `t`: + +`sectorFee(t) = k1 * CS(t) * sectorDurationDay` + +In the simulation, the sector duration is fixed to 540 days. + +#### Block Reward (BR) Based Fees +We can describe this fee as follows, for a sector onboarded at time `t`: + +`sectorFee(t) = k2 * (sum_{d=1, ...,540} sectorBlockReward(t,d) * FeeMultiplier(d)) ` + +In the above formulations: +- `k1` and `k2` represent two different scaling factors; +- `CS(t)` is the circulating supply at time `t`; +- `sectorBlockReward(t,d)` is the per sector reward for a sector onboarded at time `t` during day `d`; +- `FeeMultiplier` represents the following multiplier function. +
+ +
+ +### Simulations + +#### Methodology +To understand the effect of BR-based vs CS-based fees, we consider the following 4 metrics: +- Onboarding Fee / Sector; +- Onboarding fee per sector / Pledge per sector; +- Onboarding fee per sector / 1 day of BlockReward per sector; +- Cumulative onboarding fees that would be collected; +- Fil-on-FIL Returns (FoFR[^*]) estimate before the per sector fee; +- FoFR after the per sector fee (including a savings estimate for removing batch balancer); +- The percentage change in FoFR from before per sector fee to after per sector fee. + +[^*]:Note: FoFR is defined as `(Returns - Fees)/Pledge` + +To account for the savings that will result from the removal of the batch balancer, we first must simulate the per-sector gas fee that SPs incur for onboarding sectors under the status-quo (i.e. no onboarding fee), and the expected savings from replacing the batch-balancer with the per sector fee. Predicting future network gas fees is extremely difficult, so projecting relative savings by switching to a more predictable fee structure is challenging. Our methodology is as follows, and we note that this is an approximation that can’t take into account the intricacies of how base_fee fluctuates, since our modeling is aggregated at the daily level rather than the epoch level. + +1. First, we estimate the per-sector gas fees under the status quo to be as follows: + - PreFip: `PreFIPPerSectorGasFee[d] = (x % CurrentDailyBurn)* feeRegimeScalar / (NumSectorsOnboarded[d]+NumSectorsRenewed[d])` + - PostFIP: `PostFIPPerSectorGasFee[d] = F * PreFIPPerSectorGasFee[d]` + + The `feeRegimeScalar` models the effect of both base fee and economic bounds (ex limited FIL to onboard) and `x` models the fraction of total gas fees due to onboarding in the pre and post fip scenarios at different levels of onboarding. `F` is the ratio of pre vs post-FIP gas savings that would be achieved. + +2. Next, we estimate how this factor `F` changes as a result of the onboarding fees and the removal of the batch balancer, as a function of the onboarding rate. The table below shows this. + + | Onboarding Rate (PiB/day) | Pre-FIP base fee | `x` | `feeRegimeScalar` | Post-FIP base fee | `F` | Justification | + | :---- | :---- | :---- | :---- | :---- | :---- | :---- | + | **0 \- 2.5 PiB** | 100-1000 attoFil | 50% | 1 | 100 \- 1000 attoFIL | 1 | When the daily RB onboarding is below 2.5PiB/day, no base fee spikes are caused in both scenarios (per and post FIP) | + | **\> 2.5 PiB** | 0.01-0.1 nanoFIL | 95% | 2 | 100 \-1000 attoFIL | 0.0001 | When onboarding increases beyond 2.5PiB/day, base fee spikes from current levels, but the maximum burned will be limited by the available pledge to onboard new sectors. We estimate that this factor will not exceed 2x. | + + Comments: + - When onboarding increases beyond 2.5PiB/day, base fee spikes from current levels, but the maximum burned will be limited by the available pledge to onboard new sectors. We estimate that this factor will not exceed 2x. + - Onboarding above 3.5 PiB can only happen through batching with current network conditions. In the Pre-FIP case, this means that >3.5 PiB onboarding can only happen if the base fee is equal or higher than the Batch Balancer crossover base fee (0.25 nanoFIL in the code). + - Flag: the 2.0x growth case (the red line modeled below - equivalent to ~6 PiB daily onboarding) is likely *over-estimating* 1Y Sector ROI due to underestimating current gas costs during high-growth network onboarding, and therefore over-estimates the reduction in 1Y Sector ROI Delta. + +#### Results + +For each trajectory, we can show the expected fee and derivative metrics as a function of time. +Figure 2 shows these metrics for the CS-based fee (with the cap at 50% expected_daily_reward). Figure 3 here shows these metrics for the BR-based fee. + + +
+ +

Figure 2: CS-based fee evolution as a function of various network metrics. The scaling factor k1 = 5.56 E-15 in the first row and k1= 7.4 E-15 in the second row. The daily payment is also capped at 50% of expected_daily_reward as a safety measure. +

+
+ +
+ +

Figure 3: BR-based fee evolution as a function of various network metrics. The scaling factor k2 =1% in the first row and = 2% in the second row. +

+
+ + + + +### Conclusions: +The Block Reward (BR, Figure 3) was ruled out because the fee-to-reward ratio did not exhibit the desired behavior—specifically, when network growth slowed, the ratio did not show any slowdown in the increase, which was not optimal. In particular, the total amount of fees burnt over time is less sensitive to the levels of onboarding demand, and there is a risk of fees being high, even when onboarding demand is low. + +Circulating supply (CS, Figure 2) was chosen. CS is a good basis for the per-sector fee because it normalizes fees relative to the Filecoin economy, ensuring both adaptability and predictability. More precisely: +- Stable Economic Reference: A fixed percentage of CS functions like a fixed USD fee if market cap remains stable, keeping costs predictable; +- Adapts to Market Conditions: If Filecoin’s valuation rises, fees increase in FIL terms, scaling with the economy. If the market stagnates, fees stay economically consistent. diff --git a/resources/fip-replaceBatchBalancer/FIPxxxxAppendix.md b/resources/fip-replaceBatchBalancer/FIPxxxxAppendix.md deleted file mode 100644 index 10789269..00000000 --- a/resources/fip-replaceBatchBalancer/FIPxxxxAppendix.md +++ /dev/null @@ -1,83 +0,0 @@ -## Appendix - -This document describes simulations related to FIP-0100: "Removing Batch Balancer, Replacing It With a Per-sector Fee and Removing Gas-limited Constraints". - -### Simulation Methodology - -#### MechaFIL Introduction -Simulations are conducted using the mechafil package, which is a Python implementation of a mechanistic model of the Filecoin economy. The inputs to the simulation are: -- Raw byte onboarding (PiB/day) -- Renewal Rate (%) - the percentage of expiring power which is renewed -- Fil+ Rate (%) - the percentage of onboarded power which is deal power - -Given a trajectory of inputs, the model will forecast the future state of the network, including network power, circulating supply, locked, pledge, and other related metrics. - -Fig 1 shows the different onboarding trajectories that are simulated. Various input trajectories are considered - 0.5x, 0.75x, 1x, and 2x the current onboarding, renewal, and FIL+ rates. -Renewals and FIL+ are capped at their current maximum, since both values are close to 100%. -
- -

Fig 1: Network state evolution for each input trajectory. -

-
- -### Proof Fees Modeling - -#### Circulating Supply (CS) Based Fees -We can describe this fee as follows, for a sector onboarded at time t: - -`sectorFee(t) = k1 * CS(t) * sectorDurationDay` - -In the simulation, the sector duration is fixed to 540 days. - -#### Block Reward (BR) Based Fees -We can describe this fee as follows, for a sector onboarded at time t: - -`sectorFee(t) = k2 * (sum_{d=1, ...,540} sectorBlockReward(t,d) * FeeMultiplier(d)) ` - -In the above formulations: -- FeeMultiplier represents the following multiplier function. -
- -
-- k1 and k2 represent two different scaling factors -- CS(t) is the circulating supply at time t -- sectorBlockReward(t,d) is the per sector reward for a sector onboarded at time t during day d - -### Simulations - -To understand the effect of BR-based vs CS-based fees, we consider the following 4 metrics: -- Onboarding Fee / Sector; -- Onboarding fee per sector / Pledge per sector; -- Onboarding fee per sector / 1 day of BlockReward per sector; -- Cumulative onboarding fees that would be collected. - -For each trajectory, we can show the expected fee and derivative metrics as a function of time. -Fig 2a and 2b shows these metrics for the CS-based fee (with the cap at 50% expected_daily_reward only for Fig 2b). Fig. 3 here shows these metrics for the BR-based fee. - -
- -

Figure 2a: CS-based fee evolution as a function of various network metrics. The scaling factor k1 = 5.56 E-15 in the first row and k1= 7.4 E-15 in the second row. -

-
- -
- -

Figure 2b: CS-based fee evolution as a function of various network metrics. The scaling factor k1 = 5.56 E-15 in the first row and k1= 7.4 E-15 in the second row. The daily payment is also capped at 50% of expected_daily_reward as a safety measure. -

-
- -
- -

Figure 3: BR-based fee evolution as a function of various network metrics. The scaling factor k2 =1% in the first row and = 2% in the second row. -

-
- - - - -### Conclusions: -The Block Reward (BR, Fig 3) was ruled out because the fee-to-reward ratio did not exhibit the desired behavior—specifically, when network growth slowed, the ratio did not show any slowdown in the increase, which was not optimal. In particular, the total amount of fees burnt over time is less sensitive to the levels of onboarding demand, and there is a risk of fees being high, even when onboarding demand is low. - -Circulating supply (CS, Fig. 2a nad 2b) was chosen. CS is a good basis for the per-sector fee because it normalizes fees relative to the Filecoin economy, ensuring both adaptability and predictability. More precisely: -- Stable Economic Reference: A fixed percentage of CS functions like a fixed USD fee if market cap remains stable, keeping costs predictable; -- Adapts to Market Conditions: If Filecoin’s valuation rises, fees increase in FIL terms, scaling with the economy. If the market stagnates, fees stay economically consistent. From 71c48f94404e05149399330cdc1a07b308be5700 Mon Sep 17 00:00:00 2001 From: irene <23217773+irenegia@users.noreply.github.com> Date: Thu, 13 Feb 2025 17:44:31 +0100 Subject: [PATCH 23/27] Update and rename FIP0100Appendix.md to fip0100Appendix.md --- .../FIP0100Appendix.md => fip-0100/fip0100Appendix.md} | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) rename resources/{fip-replaceBatchBalancer/FIP0100Appendix.md => fip-0100/fip0100Appendix.md} (97%) diff --git a/resources/fip-replaceBatchBalancer/FIP0100Appendix.md b/resources/fip-0100/fip0100Appendix.md similarity index 97% rename from resources/fip-replaceBatchBalancer/FIP0100Appendix.md rename to resources/fip-0100/fip0100Appendix.md index d8b92fce..4eb57056 100644 --- a/resources/fip-replaceBatchBalancer/FIP0100Appendix.md +++ b/resources/fip-0100/fip0100Appendix.md @@ -79,7 +79,7 @@ To account for the savings that will result from the removal of the batch balanc #### Results -For each trajectory, we can show the expected fee and derivative metrics as a function of time. +For each trajectory, we can show the expected fee and derivative metrics as a function of time[^**]. Figure 2 shows these metrics for the CS-based fee (with the cap at 50% expected_daily_reward). Figure 3 here shows these metrics for the BR-based fee. @@ -96,7 +96,7 @@ Figure 2 shows these metrics for the CS-based fee (with the cap at 50% expected_ - +[^**]: The link to the code which generated the plots is here: https://github.com/CELtd/cel/blob/kiran/notebooks/proof_fees/fees10.ipynb ### Conclusions: The Block Reward (BR, Figure 3) was ruled out because the fee-to-reward ratio did not exhibit the desired behavior—specifically, when network growth slowed, the ratio did not show any slowdown in the increase, which was not optimal. In particular, the total amount of fees burnt over time is less sensitive to the levels of onboarding demand, and there is a risk of fees being high, even when onboarding demand is low. From c502ec3ba170033a61ae91c6ac67bd0274e1f58b Mon Sep 17 00:00:00 2001 From: irene <23217773+irenegia@users.noreply.github.com> Date: Thu, 13 Feb 2025 17:55:08 +0100 Subject: [PATCH 24/27] Update fip-0100.md fixed broken link --- FIPS/fip-0100.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/FIPS/fip-0100.md b/FIPS/fip-0100.md index 913908bd..94025530 100644 --- a/FIPS/fip-0100.md +++ b/FIPS/fip-0100.md @@ -233,9 +233,10 @@ We aimed for a design that is simple to understand and model, and relatively sim - **Flat Fee vs. Dynamic Fee**: A fixed per-sector fee provides predictability and consistency, while a fluctuating fee based on network congestion, onboarding rate, or other variables better captures value when the network is actively providing a service. We chose a model where the fee is a fixed fraction of a quantity that adjusts to economic conditions. We evaluated the following economic indicators for determining the per-sector fee: Initial Pledge (IP), per-sector Block Reward (BR) and Circulating Supply (CS). - The IP-based fee was discarded to avoid complex system dependencies, as changes to IP in future FIPs could unintentionally impact the per-sector fee. - - The BR-based fee was discarded because the fee-to-reward ratio did not adjust properly to network growth, leading to high fees even when onboarding demand was low. See [here](https://github.com/filecoin-project/FIPs/blob/irenegia-removeBatchBalancer/resources/fip-replaceBatchBalancer/FIPxxxxAppendix.md) for more details. + - The BR-based fee was discarded because the fee-to-reward ratio did not adjust properly to network growth, leading to high fees even when onboarding demand was low. See [here](fip-0100/fip0100Appendix.md) for more details. - CS was ultimately chosen because it normalizes fees relative to the Filecoin economy, ensuring both adaptability and predictability. + We reached this conclusion through simulation-based analysis, modeling the impact of fees under different network conditions. Specifically, we evaluated multiple input trajectories: 0.5×, 0.75×, 1×, and 2× the current onboarding, renewal, and FIL+ rates. Since both renewals and FIL+ are near 100%, we capped them at their current maximum (see Fig. 1).
From 1e8cd396142d5b9edebdeab088b4def040c46cdd Mon Sep 17 00:00:00 2001 From: irene <23217773+irenegia@users.noreply.github.com> Date: Thu, 13 Feb 2025 18:02:31 +0100 Subject: [PATCH 25/27] Update fip-0100.md --- FIPS/fip-0100.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/FIPS/fip-0100.md b/FIPS/fip-0100.md index 94025530..35caf445 100644 --- a/FIPS/fip-0100.md +++ b/FIPS/fip-0100.md @@ -233,7 +233,7 @@ We aimed for a design that is simple to understand and model, and relatively sim - **Flat Fee vs. Dynamic Fee**: A fixed per-sector fee provides predictability and consistency, while a fluctuating fee based on network congestion, onboarding rate, or other variables better captures value when the network is actively providing a service. We chose a model where the fee is a fixed fraction of a quantity that adjusts to economic conditions. We evaluated the following economic indicators for determining the per-sector fee: Initial Pledge (IP), per-sector Block Reward (BR) and Circulating Supply (CS). - The IP-based fee was discarded to avoid complex system dependencies, as changes to IP in future FIPs could unintentionally impact the per-sector fee. - - The BR-based fee was discarded because the fee-to-reward ratio did not adjust properly to network growth, leading to high fees even when onboarding demand was low. See [here](fip-0100/fip0100Appendix.md) for more details. + - The BR-based fee was discarded because the fee-to-reward ratio did not adjust properly to network growth, leading to high fees even when onboarding demand was low. See [here](resources/fip-0100/fip0100Appendix.md) for more details. - CS was ultimately chosen because it normalizes fees relative to the Filecoin economy, ensuring both adaptability and predictability. From 31fbec0a4e14ee718c7adcb5b146c8f848908393 Mon Sep 17 00:00:00 2001 From: MollyM Date: Thu, 13 Feb 2025 09:08:43 -0800 Subject: [PATCH 26/27] Update FIPS/fip-0100.md --- FIPS/fip-0100.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/FIPS/fip-0100.md b/FIPS/fip-0100.md index 35caf445..d672c663 100644 --- a/FIPS/fip-0100.md +++ b/FIPS/fip-0100.md @@ -233,7 +233,7 @@ We aimed for a design that is simple to understand and model, and relatively sim - **Flat Fee vs. Dynamic Fee**: A fixed per-sector fee provides predictability and consistency, while a fluctuating fee based on network congestion, onboarding rate, or other variables better captures value when the network is actively providing a service. We chose a model where the fee is a fixed fraction of a quantity that adjusts to economic conditions. We evaluated the following economic indicators for determining the per-sector fee: Initial Pledge (IP), per-sector Block Reward (BR) and Circulating Supply (CS). - The IP-based fee was discarded to avoid complex system dependencies, as changes to IP in future FIPs could unintentionally impact the per-sector fee. - - The BR-based fee was discarded because the fee-to-reward ratio did not adjust properly to network growth, leading to high fees even when onboarding demand was low. See [here](resources/fip-0100/fip0100Appendix.md) for more details. + - The BR-based fee was discarded because the fee-to-reward ratio did not adjust properly to network growth, leading to high fees even when onboarding demand was low. See [here](../resources/fip-0100/fip0100Appendix.md) for more details. - CS was ultimately chosen because it normalizes fees relative to the Filecoin economy, ensuring both adaptability and predictability. From 07e0be4d7deab5c07f6d62c4eb4e66edfa3a8afd Mon Sep 17 00:00:00 2001 From: irene <23217773+irenegia@users.noreply.github.com> Date: Thu, 13 Feb 2025 18:12:21 +0100 Subject: [PATCH 27/27] Update fip0100Appendix.md CS graph updated in the appendix --- resources/fip-0100/fip0100Appendix.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/resources/fip-0100/fip0100Appendix.md b/resources/fip-0100/fip0100Appendix.md index 4eb57056..873d7ba1 100644 --- a/resources/fip-0100/fip0100Appendix.md +++ b/resources/fip-0100/fip0100Appendix.md @@ -84,7 +84,7 @@ Figure 2 shows these metrics for the CS-based fee (with the cap at 50% expected_
- +

Figure 2: CS-based fee evolution as a function of various network metrics. The scaling factor k1 = 5.56 E-15 in the first row and k1= 7.4 E-15 in the second row. The daily payment is also capped at 50% of expected_daily_reward as a safety measure.