Audit impact of increasing `DEFAULT_MAX_PROVING_PERIOD` on Calibnet

[rjan90]

Summary

On Calibration network, FWSS was deployed with DEFAULT_MAX_PROVING_PERIOD set to 240, resulting in proving cycles 12 times per day. This accelerated proving frequency, combined with limited SP count on Calibnet and block production, is pushing network capacity to its limits and causing sustained high basefee.

Problem

• FOC alone is consuming most of Calibnet's capacity due to the 12x proving frequency
• High basefee is draining PDP SP wallets rapidly (over 1M tFIL spent in the past week just to keep PDP SPs operational)
• This funding pressure is limiting our ability to conduct reliable testing and validation on Calibnet

Action Required

Before making this change, we need to audit all software components that may be affected, including:

• Curio - primary concern
• PDPVerifier contract
• Other dependent services (TBD)

[TippyFlitsUK]

Update: This has caused significant issues with Calibration PDP node testing over the past week. As a result, reliable PDP testing on Calibration is currently not viable - http://77.42.75.71:8051/calibration

[BigLep]

There were FilOz discussions on this today (2026-02-04).

I currently thing we should delay doing the work of increasing DEFAULT_MAX_PROVING_PERIOD on Calibnet so as not to put extra load on engineers in the critical path for FOC GA.

In the interim I think our steps are:

1. Get more SPs in Calibration - This is happening in Stabalize Calibration network (calibnet) filecoin-project/core-devs#210. FOC WG TPMs can coordinate this to get done.
2. Do a round of dataset cleanup on Calibration - This is tracking in Cleanup Calibration datasets to (temporarily) reduce chain bandwidth pressure before GA #411. FOC WG TPMs can communicate need, and it will need engagement from folks like @beck-8 and @silent-cipher .