Sealing Transaction Fee Rate

[jbenet]

Problem

Chain congestion due to sector sealing messages -- PreCommit and ProveCommit -- is driving up the BaseFee and making WindowPosts, Deals, and other messages very expensive. Other proposals (#24, #24-b, #42) propose ways to make WindowPost cheaper or get a dedicated control gas plane, but most of those solutions will take significant time to implement.

It seems that Miners for now have settled on a BaseFee expense between 1-5 nFIL (gas expenditure dominated by PreCommit and ProveCommit.

Temporary Solution

The other solutions discussed are the right thing to do. But in the meantime:

We might alleviate the pain by introducing a gas fee rate increase for PreCommit and ProveCommit messages. This means multiply the gas fee by a SealingFeeRate -- a factor, say 10x or even 20x. This will cause parties that are sealing massive amounts currently (in this difficult congestion period) to arrive at a BaseFee about 10x cheaper.

Scales with BaseFee. because this is a multiplication on top of the gas costs of those messages, it will scale with the BaseFee, and will cause the network to find the miners' price point much faster.

Burn fees pass to miners sealing. This is unlikely to reduce burn fees, only move the proportion paid by most users (sp WindowPosts) to be paid by miners growing their storage significantly.

Downside: harms sealing new storage. This harms all sealing, not just CC sectors. This will hurt new sectors with storage, as they will be more expensive to seal. This may be an acceptable price to pay until we get a better solution in.

Network Policy Lever. This creates a network policy lever that trades off between cheaper capacity onboarding or cheaper everything else.

Implementation Notes

This should be very easy to implement. this is why I'm proposing it. This should be a relatively straight forward change to introduce in gas accounting.

Other Solutions

#24, #24-b, #42 and more

[f8-ptrk]

It seems that Miners for now have settled on a BaseFee expense between 1-5 nFIL (gas expenditure dominated by PreCommit and ProveCommit.

this does not mean that miners are paying that because they want to or can afford it. most miners are paying the 3-6 (that's what we are actually at...) nFIL because they have to. if they don't - they will end up with a power share that equals basically 0 rewards.

Making Posts cheaper, raising fees on sealing messages will not change any of the dynamics going on right now. If you, we raise the fees for sealing messages we will just see more miners die faster (go to where there is no power increase...decreasing rewards... death).

The problem in my eyes is the following:

EIP1995 combined with Filecoins "the more you seal the higher are the rewards" and almost 100% messages on CC sector seal we have the following situation:

there is a point where the benefits of sending more messages out weights the costs it creates via base fee. that is a dangerous thing to have. it reverses what EIP1995 intends to do.

so raising the cost for sealing will not do anything good for most miners. it might even hurt more miners than it benefits.

if you want to raise the sealing costs then you need to couple it with the amount of messages a miner sends. baseFee*sectorNum would be drastic but in the end a way better approach to getting control of sealing costs that the base fee creates.

do i have data to proof my claim that this is what is happening? no - i have no time - i need to push messages by hand... with 2000FIL cash on hand i can show you live how much a miner doesn't care about the base fees and how it benefits a miner more to send more messages than the basefee increase for doing so hurts him!

if we do not get rid of "more messages --> more costs for everyone" combined with "more messages --> profit for one" the situation will not resolve in any way. letting a few strain the resources while raising the costs for using them for everyone will not work out for much longer.

sorry for the sloppy answer, it might not meet the quality standards of what we need here. i might find time to actually deliver data on the claim that there are miners out there that benefit from higher base fees later this year.

[steven004]

Instead of introduction of SealingFeeRate, I would think it is easier to set a wdPostFeeFactor (or even more general - ControlPlanMessageFeeFactor). e.g. let wdPoStFeeFactor = 1/10。 There is no much impact to others, and perhaps easier to implement.

And, actually, it is similar as what I proposed in #24 (comment), which means burn less for critical (or control plane) messages. And, of course, when the basefee is much lower, a miner can set higher premium for wdPoSt message to let other miner package it into a block.

[askender]

I, as a small miner, still support this Temporary Solution. My reasons are below:

• a SubmitWindowedPoSt msg will cost about 1.3933 FIL these days, it is really hard times for small miners. Because of the brutal issue: https://github.com/filecoin-project/lotus/issues/5017 , a 10TiB small miner maybe has 3 deadlines and needs to send 3 SubmitWindowedPoSt msgs. My trick now is sending away FILs of control-address and Worker-Balance before the 2rd&3th deadline, and sending back when all deadlines gone. And 2 DeclareFaultsRecovered msgs are needed. So 2 msgs becomes 6 msgs.
• We really don't need so many CC sectors. (We have already paid too much for future. Hardwares of today is not the best of tomorrow. We should protect the Earth.) High BaseFee makes verified deals(10x power) not so attractive. We should encourage real/verified deals more and CC sectors less.
• Small miners used to wish to maintain/increase power perpercentage a month before. They only want to survive now.

[f8-ptrk]

if we raise the costs for sealing sectors x10 you need 2000-4000 FIL to get 10TB!!!!! those who can afford it will just go on rampaging the resources with sealing messages. it will just be smaller percentage of those who do not care about how high fees are now.

we do not need more expensive messages - we need to put the high costs on those who cause them.

[askender]

It is not a good time for new miners now, because of the TPS problem.
As the SealingFeeRate is 10x, many miners will consider stop mad-increace-CC-sector, thus bring down basefee. Of cource the basefee mayby change drastically, but that is still ok.

Remember it is Temporary Solution, we should set a deadline for the Temp Solution replaced by better Solution
Maybe we can set SealingFeeRateForCCSector to 20x, SealingFeeRateForDeals to to 10x and SealingFeeRateForVerifiedDeals to to 1x.
People can still store random-data deals to themselves, they have to pay for PublishStorageDeals too(they should) and lost the benefit of replace-with-real-deals.
Maybe it is time to forget CC sector.

We can do better in Filecoin Plus to help small miners and developers, not help auto-devops-big-miners which contribute less to the ecosystem/ecology.

Some big-miners are cheating their Individual investor who know nearly nothing about IPFS/Filecoin, they will make filecoin less attrative and more centralized.
They can be even cheating in Slingshot phrase 2 to got more filecoin candy. (They may have many miners to send deals to each other. They claim that the miners belong to their Individual investors.)

We have to admit Filecoin is in danger, small miners wish to help themselves and the network too. FIPs which can be implemented in 1 month need to be discussed more.

I have a bad idea which let big miners experience the pain of small miners more:
https://filecoinproject.slack.com/archives/C0179RNEMU4/p1605771178021700?thread_ts=1605717762.393000&cid=C0179RNEMU4

[f8-ptrk]

Maybe we can set SealingFeeRateForCCSector to 20x, SealingFeeRateForDeals to to 10x and SealingFeeRateForVerifiedDeals to to 1x.

let's just ask PL to hand out rewards and give up block mining!

Maybe it is time to forget CC sector.

good solution. honestly. lets just forbid CC sectors. permanently. and while we are at drastic solutions let's cut the expiration date on existing CCs to, lets say 14 days - then we can start with a clean chain on new year...

if we want to keep CC sector sealing we will have to couple the cost for it to the amount of CC sectors someone seals. maybe even normal deal sectors.

[raulk]

In my head there are three different message categories depending on how they affect the liveness and dynamics of the network, and the parameters of the consensus plane. It's important to recognise these categories because they would likely benefit from having different sets of guarantees applied to it, potentially via different gas/fee circuits/planes.

System-maintenance / power-maintaining messages

SubmitWindowPoSt

• These are essentially compulsory system messages.
• They sustain chain consensus, and are necessary to maintain status quo and homeostasis of the network.
• If all miners suddenly stopped submitting wdpost, the system would cease making progress, and potentially the chain would halt (theoretically; IIRC, there's a backstop mechanism to keep the chain live even in a doomsday event like this).
• In the current protocol, this message is absolutely necessary for the continued operation of the chain and, therefore, the network.
• Potentially DeclareFaults[Recovered] could be included in this category, as miners might want these messages to go on chain urgently.
• One could regard this category as not being subject to auction.

Power-altering messages

PreCommitSector, ProveCommitSector, TerminateSector

• These message affect the miner power attributions and therefore the parameters of Expected Consensus.
• These messages are not homeostatic, they actively grow or shrink the network.
• The idea is that by recognising this category separately, the protocol could apply a dedicated fee/auction policy to throttle/control growth either symmetrically or asymmetrically (e.g. by making onboarding sectors linearly more expensive for already large miners).

User messages (power-neutral messages)

• This is the "other" category of messages.
• These absolutely belong in auction-land, but they do not affect consensus making in any manner, nor the size of the network.

---

I'm not sure about PublishStorageDeals. This seems to be a system message too, could potentially belong in the system-maintenance category. But it is not consensus-critical like SubmitWindowPoSt. There could be a flat fee applied to non-critical system messages, so that they go through the same priority circuit, but they do not benefit from a financial advantage). Maybe DeclareFaults also belongs in that subcategory.

[kaitlin-beegle]

Marking this thread inactive, as FIP-0010 seems to have addressed the issue. Will circle back in core devs meeting on 8/12/21 to confirm.

[kaitlin-beegle]

Closing due to inactivity.