Alex NorthAlso previously known as “proof fees” (but there will be other types of proofs not subject to these fees) and “onboarding fees” (they’re not only about capacity onboarding).
Context https://github.com/filecoin-project/FIPs/discussions/557
Latest from Kubuxu: Removal of Batch Balancer through Onboarding Fees
Goals
- Align network fees with value provided to SPs (and transitively to clients)
- Don’t increase SP costs in current network conditions (so base fees might be zero), but provide for network revenue capture as utilisation increases
- Decouple these fees from gas, remove the batch balancer
Sketch
Three potential fees for network services.
Capacity
CC and other sectors provide value to the network as consensus security and spare capacity. CC sectors are provably not valuable for data, can’t earn beyond the block rewards.
- Either no fee, or at least a very low baseline when capacity is not growing
- Capacity fee could be dynamic, scale with network raw growth rate
- Value transfer to holders if SPs are growing capacity fast
- This is closest direct alternative to the batch balancer, which charges PoRep.
Data update
Proof of data replication is the essential service that SPs can offer to clients. Setting non-zero data (either initially or through replica upgrade) is assumed to be valuable to SP. Value could be either a client is paying directly, or FIL+ subsidy, or some other reason. The network provides value to SP with a trustable, reliable proof of data replication to a counterparty.
- Fixed fee per sector size, proof aggregation doesn’t make a difference.
- Data fee could scale with to the rate of events
- Essentially a write throughput fee for the network. Each write costs X FIL, and X depends on the rate of writes observed.
- Implementation needs a counter tracking the network-wide rate of data update events over some time period
- Implementation of aggregated replica update proofs, or similar, could provide the cost saving that makes room for this fee to capture some incremental value
- This fee will directly affect SP costs of deals, so will set a floor for paid deal costs.
Data maintenance
Maintaining assurance of a data replica is also valuable to the SP, similar to the initial replication
- Fee per sector size and duration
- Could charge up front according to a commitment duration ❌
- This couples the fees to the idea of commitments, which is limiting
- Charging up-front is harder for SPs cash flow – they probably bill over time
- Could charge during Window PoSt
- Could charge during deadline cron
- Avoid adding costs to Window PoST
- Amortize better even when deadline maintenance is kicked out of cron.
- Implementation needs a counter for “data sectors” (non-zero data) in deadline metadata, on which to levy fee.
- Should the fee be fixed or variable?
- Variable costs make SP planning more difficult
- Variable cost allows demand-based pricing
- Unclear if a cost saving can be introduced near-term to give this fee room to earn.
Questions
- Fees related to block rewards or circulating supply?
- Without batch balancer, is proof fee the only linear part?