Add Cost opportunity for New Miner Creation

[remakeZK]

This is a pre-FIP for discussion.

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?

[anorth]

This would seem to conflict with the notion of data-only miners (no consensus power), who would not necessarily expect to need any pledge. Though we are quite some way from explicitly designing this.

For context, the proposed deposit of 10TiB pledge is 0.1958 * (10 TiB / 32 GiB) = ~62 FIL today, so not very much for a once-off cost (but enough to deter creating hundreds or thousands of spammy miners)

[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?

[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.