Add Cost opportunity for New Miner Creation (FIP-0077)

[remakeZK]

Note: this started a pre-FIP for discussion that turned into https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0077.md

Simple Summary

• Add opportunity cost (in FIL) to each node creation to prevent the miner ID creation spam.

Abstract

By imposing a cost, this proposal helps prevent the spamming of creating miner IDs in order to:
1)  lighten the network chain storage burden
2）save wasted resources and future increment of gas that caused by wasted storage
3）avoid the malicious attacks achieved by creating a large number of accounts to cause network congestion and unstable gas fees

Problem Motivation

By August 2023, according to the statistics of Filscan, there are 601,131 Miner IDs have been built with only 4,862 actives. The actual ID usage counts for merely 0.8% and the abuse of ID creation trend continues. The actual ID usage only counts 3.7% for the recent two months (125 Miner IDs are active out of 3,254 newly created).


Many users randomly create numerous nodes just to get preferred IDs, wasting resources and burdening the network for no purpose. Moreover, those wasted nodes occupy the storage of the network; with time elapsed, the waste resource rate will increase, along with increasing the future gas price because of those unnecessary storages of the network. Furthermore, there is a risk of exposure to potential attacks by creating numerous accounts, causing network congestion.

Specification

In creating a new node,

• Currently: there is no cost associated with creating new miners, so users spams many new nodes without limit
• Proposed:
  There are two options:
  1. Require spending of a one-time 10FIL to create a new miner ID and deposit the 10FIL into miner account as locked rewards.
  2. Charge a fee (e.g.10FIL) to create a new miner ID, which gets burned immediately.

Design Rationale

Adding an opportunity cost will prevent such spammy behavior; moreover,

1. Depositing fees as locked rewards does not incur actual costs but will occupy funds and bring opportunity costs. Users need to weigh the opportunity cost of locking funds for 180 days per new node. Also, the more nodes created, the more funds need to be locked. This can prevent users from abusing node creation. Additionally, this mechanism helps determine whether each new node will be fully utilized since idle miners will waste locked funds in vain.

2. Burning fees align network incentives by imposing real costs for usage and decreasing token supply circulation, potentially increasing FIL price.

Backward Compatibility

The charging fee of node creation might increase the entry barrier of new SPs, but 10FIL is a small amount in terms of initiating. Moreover, the proposed first solution of converting fees to 180-day locked rewards adds no real capital cost, only opportunity cost. This encourages on-demand account creation, as users will create accounts based on actual needs, ensuring practical use of each new account.

[anorth]

I'm not sure how much of a real problem this is. Your statistics look believable, but the question is how much of an actual cost is this to the network or its participants? It's probably not zero, but could be quite small.

Nevertheless, both your proposed ideas appear simple to implement. The locking approach will require cron processing of their vesting table, but I think it's safe to assume only a small number of such miners that wouldn't require cron anyway to process deadlines.

A few suggestions:

• Rather than a fixed 10 FIL, the fee might be indexed to the circulating token supply (e.g. 0.00001% of supply, the fraction chosen to be about 10 FIL today). This number will then stay roughly in line with token inflation/deflation over the long term.
• 10 FIL seems quite cheap, even at much higher token prices.
• For option (1) of a deposit, I suggest the amount could be set much higher, since it will be eventually returned to the SP. Any serious SP is going to need enough FIL for the pledge of many TiB?

[steven004]

It is great if simple code change could stop of miner creation abuse though the cost is small since the impact lasts all along to the endless future, I think.

Rather than a fixed 10 FIL, the fee might be indexed to the circulating token supply (e.g. 0.00001% of supply, the fraction chosen to be about 10 FIL today). This number will then stay roughly in line with token inflation/deflation over the long term.

From better UX point of view, I would be more support of a fixed number. The new SP needs to know exactly how much FIL she needs to put into the creation message. A changing number will make it a little bit harder for the new miner creation. At the same time, I would expect there will be almost no one to create idle minerIDs if we set the number right.

For option (1) of a deposit, I suggest the amount could be set much higher, since it will be eventually returned to the SP. Any serious SP is going to need enough FIL for the pledge of many TiB?

If 10Fil burnt for option(2), then perhaps 100Fil for option(1) is more reasonable as the capital cost is still lower than 10FIL, and it returns to the SP in 180days.

[Stebalien]

1. The state/storage cost should be covered by existing gas fees. However, this touches on a deeper issue where storage gas fees fluctuate based on the base-fee, which doesn't really make sense. IMO, the low state-storage fees are the real issue here.
2. Unless a sector gets sealed (power gets onboarded), additional miner actors are basically "free" from the network's perspective (disregarding the state/storage costs). The network won't spend any more time on them than it would on empty accounts.

So, I'd love to see a FIP presenting a way to make storage fees independent from the regular base-fee, changing based on expected state growth instead of compute demand. That should solve the main issue here (also solving it for EVM actors) without adding a hard-coded fee for miner actors.

[anorth]

#557 (@Kubuxu is exploring refinements of this general ideal).

[joshua-ne]

The damage from creating miner actors is only noticeable when it happens both fast and in large amounts. So I think a very simple method would be requiring the value in creatingMiner message to be like 500FIL. We do not even need to lock this fund (thus will not need any cron tasks).

Of course, attackers may withdraw the fund and attack again. But this mechanism would greatly slow them down and they will need a lot of funds to attack on a large scale at a time.

[remakeZK]

500FIL works, but has to be locked funds, since attackers can use scripts to generate multiple messages in a short period of time, create and withdraw funds various times within the same block time, and still could attack in a short period of time without requiring a lot of cost. therefore, locking funds is a necessary step to prevent this situation from happening.

[jennijuju]

avoid the malicious attacks achieved by creating a large number of accounts to cause network congestion and unstable gas fees

I'm not sure how much of a real problem this is.

Id like to point out this was a real issue occurred in March 2021 where someone spammed the network with thousands of thousand of CreateMiner messages with very cheap cost. It caused a couple issue:

• base fee increases and congests the mpool
• stress some nodes from block producing opportunities
• chain performance (cron jobs overload - which was addressed in nv12 upgrade)

The recent profiling work @ZenGround0 has been working on has confirmed that the cron cost for truly empty actors is minimum (to 0), while miners with small amounts of sectors cost us a lot in terms of overhead. That being said, adding opportunity cost for miner creation could potentially prevent unstable network base fee and longer term chain overhead.

[jennijuju]

@remakeZK I personally think opportunity 2 is slightly better as 1 requires new cron job, and avoiding cron overhead seems worth taking into consideration for network longer term stableness as it scales.

[jennijuju]

If locked, is there any reason why we want to use locked reward which will be vested over cron jobs? is there an option to produce with pledges with less regular cron checks - not sure if it worth adding a new state field & a dedicated cron process just for that state tho.. @ZenGround0 wdyt?

[anorth]

Using the existing vesting schedule is no extra code or overhead, assuming that most miners go on to actually earn a reward. Which, if well priced, will be the case. I quite like the small stake aspect that it introduces, vs burning as a pure cost imposed before the SP has provided or earned anything.

I think that making the vesting mechanism generally more efficient and/or independent of cron is a separate topic. Whatever improvements we make there would automatically apply here.

[jennijuju]

Thanks @anorth for the actor impl explanation!

burning as a pure cost imposed before the SP has provided or earned anything.

This is a good callout. I would then suggest that maybe, on top of the fund would be unlocked after 180days, we could add on the miner actor should also be reaching the minimum mining threshold. ( reaching the minimum mining threshold is the margin when a miner (actor) is contributing to the network consensus and help secure the network)

[steven004]

on top of the fund would be unlocked after 180days

@jennijuju , this may introduce additional layer of complexity to the implementation. The simplest way is to leverage the existing 180-day vesting mechanism, with minimal code change. From my perspective, they are almost equivalent to have 500FIL vested only after 180 days, or have 1000FIL being vested linearly within 180 days. And, in my opinion, 500FIL locked for 180-day vesting would effectively deter potential attacks and prevent abuse of creation.

[jennijuju]

Many users randomly create numerous nodes just to get preferred IDs,

I think another reason why folks were doing this was to get a preferred deadline schedule for the actor to minimize the human operational/maintenance cost. With https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0070.md - this "use case" should be resolved tho.

[anorth]

Note that FIP-0070 is not likely to land, so getting a preferred deadline schedule remains relevant.

[jennijuju]

With the recent discussion in #972 on enabling certain SPs to join and leave the network easier - this proposal seems to have a conflicted design goal for the network. Should CC miners also pay and lock this fee?

[The-Wayvy]

Yes I think this conflicts with 972

It tries to solve a problem that doesn't exist (over-usage).

The chain is not congested at all.

It's a ghost town and we should focus on making it simpler and cheaper for people to experiment on.

Strong pass on this FIP.

[The-Wayvy]

What are the "malicious attacks" enabled by relatively cheap creation of miner IDs?

Has an attack like this ever happened?

[jennijuju]

@The-Wayvy yes in like 2021 - there was a small incident where the chain mempool was flood by CreateMiner message that lead to PoSt and other useful messages for data and sector onboarding to not land onchain efficiently

[The-Wayvy]

The mempool can be spammed with any message

Is there anything about the ID creation message that makes it more suited for spam attacks than other messages?

[ipfsforcezuofu]

On behalf of the author @remakeZK , I agree with @anorth’s points regarding the conflict with FIP-972. Until a pledge mechanism tailored to different miner types is explicitly designed, it is not feasible to create separate policies to prevent miner ID attacks. The current CreateMiner function does not distinguish between CC, DC, or hybrid miners, so a universal approach remains necessary for now.

Regarding spam, while CreateMiner is not the only message that can be abused for spam attacks, it has historically contributed to chain congestion. Therefore, it is important to develop a solution to deter this specific vector.

[rvagg]

A couple of miscellaneous thoughts as I get up to speed on this FIP:

1. Now that FIP-0100 has been accepted and is about to go into use, there is a minor concern about the miner bootstrap problem of sectors needing to pay fees before the miner goes past minimum consensus power and starts winning block rewards. Mostly that just means that setting up a new miner actor for use means you need to put a few FIL into the balance and it'll be OK, but it's another documentation step and it would be easy to overlook it. If this FIP were activated, then we'd solve that problem by locking up more than enough funds to cover fees for 180 days even if the miner didn't win block rewards in that time.
2. There's been some work recently looking at miner actor cleanup, including relying less on cron for automatic cleanup, this FIP may overlap with some of that work, or potentially conflict with it. For example - perhaps instead of requiring funds be put into vesting that a deposit gets locked and can only be unlocked once the miner actor is fully cleaned up (e.g. dead sectors removed, everything compacted), i.e. a clean-up deposit. Something to keep in mind if that work progresses, if we come up with some concrete proposals that can be turned into one or more FIPs then this one could be subsumed into that work.

[BigLep]

If this FIP were activated, then we'd solve that problem by locking up more than enough funds to cover fees for 180 days even if the miner didn't win block rewards in that time.

This is a good point. I think it would be ideal to update https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0077.md calling out that it addresses this pain point. I'd also want to see an accompanying PR to update the docs that were added for FIP-0100 at filecoin-project/filecoin-docs#2396

[ipfsforcezuofu]

If this FIP were activated, then we'd solve that problem by locking up more than enough funds to cover fees for 180 days even if the miner didn't win block rewards in that time.

On behalf of the author @remakeZK, I agree that the deposit could technically be used to pay sector fees. However, this cannot fully guarantee adequate coverage, since the deposit amount is fixed and vests over 180 days, while the timing for a new miner to begin sealing sectors and the total number of sectors may vary. As a result, the deposit may not always cover all necessary fees throughout the bootstrap period.

There's been some work recently looking at miner actor cleanup, including relying less on cron for automatic cleanup, this FIP may overlap with some of that work, or potentially conflict with it.

I fully support the long-term goal of improving miner actor and cron cleanup mechanisms. Once the related proposals are finalized, the deposit function can certainly be adjusted accordingly to align with those changes.

[momack2]

Reading through the FIP - the proposal to make the deposit equal to the pledge costs of reaching 10TiB up front. This seems high for the goal of mitigating miner spam. Would say 10% of that amount (6 FIL instead of 62 FIL) still achieve the same goal without causing such a high upfront burden for folks to get started as an SP?

[BigLep]

This seems like a reasonable ask to me and should be answered or addressed before the FIP moves out of last call in my opinion.

[Tanisha-fil]

This might be worth exploring further—especially if the primary objective is economic friction rather than capital commitment. Curious to hear the author's thoughts here on what best balances security and accessibility — @remakeZK

[tediou5]

From my perspective, I completely agree that the amount can be further adjusted. We don't want this FIP to impose an excessive burden on regular miners.

[ipfsforcezuofu]

On behalf of the author @remakeZK, I agree that setting the deposit at 6 FIL should still be effective in deterring spam, especially given the past incident where the network was flooded with thousands of CreateMiner messages. At the same time, this lower deposit reduces the entry barrier and addresses SPs’ concerns about initial costs, achieving a better balance between security and accessibility.