fix(build)!: adjust FilReserved for FIP-0100 for non-mainnet

[rvagg]

This is the calibnet fix mentioned in FIP-0100, but it's also for 2k and butterfly. It's a PR into the rvagg/fip-0100 branch, for independent reviewing because this one needs explaining.

Bear with me while I explain the logic here, I want to get this on the historical record without having to put it all in the code.

The aim is to bring circulating supply to a positive value (well, nonzero), and to push it into the millions so we can have comparative values to mainnet. Mainnet is currently at 698M FIL. The FIP states that we're going to bring Calibnet up to 300M but I'm going to change that and push everything closer to 600M just so we have very comparable numbers for fee calculation to mainnet (I'll update the FIP text for calibnet).

The basic equation for circulating supply is:

$$CS = \max(0, FilVested + FilMined + FilReserveDisbursed - FilBurnt - FilLocked)$$

FilReserveDisbursed is the thing we're going to tinker with, it's further broken down as:

$$CS = \max(0, FilVested + FilMined + (InitialFilReserved - FilReserved) - FilBurnt - FilLocked)$$

InitialFilReserved is fixed in Lotus as 300M FIL. But we have different FilReserved (f090 balance) values across our network configs. On mainnet it's 282M, but seems to be set to 900M (or thereabouts) in genesis on butterfly and calibnet (currently 869M on calibnet), and 700M when you start a 2k network, or even an itest without the 2k tag. I don't have an explanation for these numbers, I'm just rolling with it. Butterfly and 2k are easy to adjust in the future, calibnet less so.

For mainnet, calculate CS by filling in:

$$CS = \max(0, 489942212706911624810780299 + 368308309891806770091483994 + (300000000000000000000000000 - 282933381038226594769936954) - 40385212415096332500414561 - 136827985628170331804063944)$$ $$CS = 698M$$

For calibnet:

$$CS = \max(0, 330780229228386605786661888 + 70513551539223285753426670 + (1300000000000000000000000000 - 869144570890006671285774984) - 32241695511329683287634028 - 4227151872445836887470146)$$ $$CS = \max(0, -200M)$$

Butterfly is a bit weirder because it starts off with a FilVested of ~10M FIL, at height 1 we work it out as:

$$CS = \max(0, 10633800385165826624205808 + 0 + (300000000000000000000000000 - 900000000000000000000000000) - 0 - 1440)$$ $$CS = \max(0, -586M)$$

2k starts off with a ~0 vested and a mining reserve of 700M FIL; something like this:

$$CS = \max(0, 0 + 0 + (300000000000000000000000000 - 700000000000000000000000000) - 0 - 0)$$ $$CS = \max(0, -400M)$$

So, with this PR, we introduce a switch at Teep (nv25) upgrade height, so that the Circulating Supply value that gets passed into the FVM will flip. For mainnet we leave it alone, but we make the following changes:

Calibnet 300M -> 1.2B

$$CS = \max(0, 330780229228386605786661888 + 70513551539223285753426670 + (1200000000000000000000000000 - 869144570890006671285774984) - 32241695511329683287634028 - 4227151872445836887470146)$$ $$CS = 695M$$

Butterfly 300M -> 1.6B

$$CS = \max(0, 10633800385165826624205808 + 0 + (1600000000000000000000000000 - 900000000000000000000000000) - 0 - 1440)$$ $$CS = 710M$$

2k 300M -> 1.4B

$$CS = \max(0, 0 + 0 + (1400000000000000000000000000 - 700000000000000000000000000) - 0 - 0)$$ $$CS = 700M$$

---

The diff isn't super clean because I also moved some variables around in the params files to put the auxiliary settings with their upgrades because they were getting a bit too separated.

I also need to manually fix the itest ensemble because it's not normally run with -tags 2k, so I copy in the 2k settings that I care about to each ensemble build.

I'm removing buildconstants.FilReserved and buildconstants.FilAllocStorageMining entirely, we don't use them internally and you can extract them from the other variables that are exposed in there.

(Also, sorry, my brain hurts too if it's any consolation when reviewing this)

(Edit: updated original numbers to get closer to 700M on each)

PR title now matches the required format.

[rjan90]

InitialFilReserved is fixed in Lotus as 300M FIL. But we have different FilReserved (f090 balance) values across our network configs. On mainnet it's 282M, but seems to be set to 900M (or thereabouts) in genesis on butterfly and calibnet (currently 869M on calibnet), and 700M when you start a 2k network, or even an itest without the 2k tag. I don't have an

Just adding to the history here, that I believe the FILReserved (f090 balance) was set higher on the test networks as hack/workaround to get to the 2B FILBase, instead of adding all types of msig/vesting wallets for different initial investors/FF/PL to these networks.

[rvagg]

Having written all of that, I will admit to having second thoughts on changing the FIP or calibnet. 900M makes circulating supply correct on calibnet. 1.1B makes it closer to current mainnet, but not technically correct. We'll still get fees calculated, they'll just be nearly half of what they will be on mainnet. Maybe that's not terrible.

I'd still like to make butterfly and 2k closer to mainnet, and as I said, we can easily change those values for these ephemeral networks in the future.

[rvagg]

Suggested change

	var UpgradeTeepInitialFilReserved = wholeToNano(1_100_000_000) // FIP-0100: 300M -> 1.1B FIL
	var UpgradeTeepInitialFilReserved = wholeToNano(900_000_000) // FIP-0100: 300M -> 900M FIL

This would match the current FIP. Need to consider whether it's better to be correct, or make it closer to mainnet just to test fee calculation. 🤔

[rjan90]

I think one of the goals for Calibnet is to try to mirror Mainnet. While it has achieved that with regards to SP hardware usage, block times, and proofs, the economics has been really skewed.

I'm in favor of aligning Calibnet more closely with Mainnet's economic conditions. Although we may never fully replicate Mainnet econ due to differences in scale and miner numbers, adjusting the circulating supply to be more accurate to what Mainnet is a positive step forward in my opinion.

[rvagg]

filecoin-project/FIPs#1133 & filecoin-project/FIPs#1105

Proposing another 100M FIL to get us to an almost exact match with mainnet. I'm still not sure about it, but these really are just test networks so we can tweak them as we need and it would be nice to have equations resolving to very similar values as mainnet.

[rvagg]

Latest commit fixes some things and adjusts the numbers a little bit more to get us closer to 700M which is really what the target should be if we're matching mainnet. I'm still a little torn on accuracy vs matching mainnet, but it would be nice to have a better testing environment. We'll see if filecoin-project/FIPs#1133 gets merged.

@rjan90 re testing - I've not done anything to actively test butterflynet but I did get on to the currently running one to inspect the state and calculations, which is where my numbers are coming from in here. 2k testing I can do locally through itests, and you can see in my latest commit I had to fix the nv24 migration test because it was breaking with my changes, the UpgradeAssemblyHeight change specifically. But it all makes sense and I added more notes about why the changes are made and how they work together to make everything execute properly. What I ended up doing in the itests is setting the InitialFilReserved to 700M, so its actually accurate from genesis for the mining reserve, and then do the additional bump at Teep so what we'll see it doing is go from actually accurate, to inflated to get us to a CS close to 700M.

[rjan90]

Took the branch for a spin on my calibration network node, and set the upgrade epoch to 2467050:

Circulating supply before the upgrade:

lotus state  circulating-supply --vm-supply
Circulating supply:  0 FIL
Mined:  70577664.517308813132145682 FIL
Vested:  331025785.573779965756217202 FIL
Burnt:  32243030.484932989752921826 FIL
Locked:  4233426.164476084875132204 FIL

Migrations:

2025-03-07T07:58:00.089Z	WARN	statemgr	stmgr/forks.go:250	STARTING pre-migration
2025-03-07T07:58:00.161Z	INFO	fil-consensus	filcns/upgrades.go:3012	Creating migration jobs
2025-03-07T07:58:02.161Z	INFO	fil-consensus	filcns/upgrades.go:3012	Performing migration: 123764 of 123772 jobs processed (61877/s) [2s elapsed]
2025-03-07T07:58:02.696Z	INFO	fil-consensus	filcns/upgrades.go:3012	Done creating 157108 migration jobs after 2.5s
2025-03-07T07:58:03.703Z	WARN	statemgr	stmgr/forks.go:263	COMPLETED pre-migration	{"duration": 3.614123026}
------
2025-03-07T08:58:32.148Z	WARN	statemgr	stmgr/forks.go:202	STARTING migration	{"height": "2467050", "from": "bafy2bzacec2vyxmohmfsrt4amt57bcelpolxag2ckotbizh2ijqijttvsjc6e"}
2025-03-07T08:58:32.324Z	INFO	fil-consensus	filcns/upgrades.go:3012	Creating migration jobs
2025-03-07T08:58:34.281Z	INFO	fil-consensus	filcns/upgrades.go:3012	Done creating 157125 migration jobs after 2s
2025-03-07T08:58:34.470Z	WARN	statemgr	stmgr/forks.go:211	COMPLETED migration	{"height": "2467050", "from": "bafy2bzacec2vyxmohmfsrt4amt57bcelpolxag2ckotbizh2ijqijttvsjc6e", "to": "bafy2bzacec5xvlxmkr3kguz657ycjdjxiwm4qnhnfizog5pvkklqfjlam24vu", "duration": 2.322295557}

Circulating supply after the migration:

lotus state  circulating-supply --vm-supply
Circulating supply:  695998687.800397868318023737 FIL
Mined:  70580720.219537282613540871 FIL
Vested:  331037788.896461187217404256 FIL
Burnt:  32243030.484934148124519106 FIL
Locked:  4235719.943362292089943101 FIL

Which is right on target/according to the calculations above

[rjan90]

Changes look good to me. Guess the outstanding question is some signal on the accuracy vs matching mainnet CS.

[rvagg]

filecoin-project/FIPs#1133 merged