Exempt Base-fee burning for consensus related (Control-plane) messages

[steven004]

Summary

This is to proposal the exemption of the Base-fee burning for consensus related (Control-plane) messages. The proposed setting comes with the following benefits:

1. bridge storage providers over the heightening Base-fee/Gas cost,
2. prioritize consensus related (Control-plane) messages in a congested network, and
3. stimulate high-performing storage prividers with the un-burned Base-fee.

Motivation

Storage providers are facing heightened Gas cost for power growth and power maintenance after the recent NV16 upgrade as the Gas modeling has changed. A power growth slow down has also seen comparing to the pre-NV16 level, as is shown in the snapshot below from The starboard dashboard.

When NV16 takes effect, the Base-fee is flunctuating around the aggregation balance level, about 0.32nanoFil, therefore a 32G-sector storage provider needs roughly 2 months' block rewards to compensate the Gas cost for sector onboarding. As expected, the Base-fee could surge to a much higher level when the FVM M2 is landed while large numbers of user-programmed actors are running on Filecoin. Assuming the base fee reaches 5 nanoFil or higher by the time, there will be virtually no storage providers to support Filecoin data sealing since it is not rational of taking years' rewards to cover just the Gas cost, one among other costs for storage providers such as hardware, energy, technical supporting, collateral interest, etc. In a word, without further adjustment, the current mechanism cannot be sustained.

Background

EIP-1559 is implemented in Filecoin for better Gas fee prediction and protocol revenue generation. It was the first EIP-1559 adoption, even before its implemetation in Ethereum.

When EIP-1559 was discussed in the Ethereum community, Gas cost was not taken into consideration since there is no Gas cost for an Ethereum miner to solve the hash puzzle and generate blocks. Therefore, miners' cost is not related to the Base-fee. Minerds simply compete with each other to maintain the network, while comparing the block rewards and the real-world costs to measure their profitability.

When we considered the adoption of EIP-1559 in Filecoin, the Gas cost was merely a tiny portion of the total cost for a storage provider. It was not an issue until we realized the Base-fee could surge when FVM is landed and the smart contracts are enabled.

The exemption of Base-fee burning for consensus related messages is to relieve storage providers of the Gas cost struggles, and to better focus on data services and consensus.

Consensus-related (Control-plane) messages

We define all messages related to consensus/power are Control-plane messages, which include: CompactSectorNumbers, DeclareFaults, DisputeWindowedPost, ExtendSectorExpiration, PreCommitSector, PreCommitSectorBatch, ProveCommitSector, ProveCommitAggregate, ReportConsensusFault, SubmitWindowedPoSt and TerminateSectors.

All other messages are considered as Data-plane messages, including those sent to any user-programmed actors.

Control-plane messages are critical to the network's consensus and security. It should be prioritized under a congested network.

Proposal

For any Control-plane messages, the Base-fee Gas consumptoin is not burnt, but tranferred to the block generator along with the Gas Premium.

The core advantages are:

• The change is minor and the implementation is simple as there is no alteration of the Base-fee mechanism and has no impact on the Base-fee calculation or prediction. i.e. EIP-1559 works as designed.
• The unburned Base-fee consumption for the Control-plane messages would compensate against the potential high Gas cost that distresses the storage providers as the payoff period extends.
• It could be considered as a stimulus to those who prioritize consensus-related messages since the unburned Base-fee will be granted directly to the block generators. The block generators would prefer packaging Control-plane messages over Data-plane messages under the proposed setting.
• The Base-fee is paid by one storage provider, who grows and maintains power, to another storage provider, who generates the block. Proposed change would incentivize the storage providers to maintain better services for the consensus which creates a positive externality.

An alternative is to eliminate the Base-fee consumption for all Control-plane messages as a whole. However, it is not as beneficial as what proposed above since it breaks EIP-1559 targets and there is no stimulus effects.

Implementation

Most changes can be conducted in the VM implementation. Only the burning logic needs to be changed separately which is not significant and has no impact on the other logics. And the proposed change should also apply to the Control-plane messages that are invoked implicitely, e.g. by an user-defined actor.

Since more than 95% of the Gas are consumed by Control-plane messages in the current network (before user-defined actors enabled). Exemption of the entire Gas burning can be considered at this stage as a simplified, minimal code-changing implementation.

[Stebalien]

I agree that there is a legitemate concern here, but this proposal, as-is, would break the network.

• Large storage providers would be able to grow and prove their own power for free as they'd recover all gas costs.
• The base-fee would go to infinity because storage providers can include their own messages at no cost to themselves, continuously over-packing blocks.
• Nobody else would be able to get their messages included due to the infinite base-fee.
• Small storage providers would be entirely unable to compete as large storage providers because they produce fewer blocks.

This scheme is also more likely to inflate and devalue FIL than it is to increase revenue (the issue with any "increase the rewards" scheme) and directly transfer funds from small miners to large miners.

[jennijuju]

However, this doesn’t reduce the cost for new sp to participate in the network. Reading the proposal, participates are still being charged for the base fee gas, just the receivers are now changed to blocker producers - in which benefit larger SPs more (and may easily creates a larger getting larger, richer getting richer loop imo)
This proposal also adds more benefit for self packing, which put risks on smaller SPs control plane message to not land on chain soon or in time, or will take non-control plane message take a really long time to land onchain unless sender paying higher gas premium. This may also put network in risk as one can create high gas limit messages congest the network mpool, without paying anything via self packing.

[Stebalien]

The current economics depend on the funds being burned. I can do my best to show you where things may go wrong, but, at the end of the day, we'd need to model the proposed change to understand the impact.

Averaging doesn't change anything, unfortunately. It just shuffles things around a bit:

• Storage providers pack blocks proportional to their power. If they pack their own messages, they'll pay the gas into the pool.
• Storage providers win blocks proportional to their power. Assuming a stable (but ridiculously high) base-fee, a storage provider would expect to recover funds at the same rate.

Basically, input == output.

[steven004]

this doesn’t reduce the cost for new sp to participate in the network

The whole idea is not to reduce the cost of SPs. Any existing sp or new sp will need cost to grow and maintain power which is no change; but, the idea is to let the SPs could get back from the base-fee consumption pool next when when contribute to the consensus as block generators. The dispatching is like block reward, theoretically proportionally distributed to all the storage miners according to their power ratio, which is fair.

Self-packing is a problem we should definitely consider. A pool to smooth the dispatching came to my mind first for this. I appreciate if there is any better ideas.

[steven004]

Basically, input == output.

@Stebalien , thanks a lot. You have already showed me what's wrong. The Filecoin network is quite different than others. Storage providers are miners and also clients. I got it. I has to be input > output, or cost > reward.

[Stebalien]

thanks a lot. You have already showed me what's wrong. The Filecoin network is quite different than others. Storage providers are miners and also clients. I got it. I has to be input > output, or cost > reward.

Well, to be clear, the overall reward needs to exceed the cost. Otherwise no rational player would participate.

However, in terms of gas cost, there needs to be a point at which the cost of message inclusion exceeds the expected reward for some players (so it can act as a market) and a point at which the cost exceeds the expected reward for all players (so that the price won't rise to infinity).

[Stebalien]

As expected, the Base-fee could surge to a much higher level when the FVM M2 is landed while large numbers of user-programmed actors are running on Filecoin.

Once we hit the "batch balancer" limit, we a buffer before the base-fee will start increasing again as ProveCommitSector messages will turn into ProveCommitAggregate messages. However, this is a legitimate concern.

One potential solution is to introduce a distinction between control-plane and data-plane messages however, instead of simply giving the burnt FIL to the miner, there would simply be two base-fees: one for data-plane messages, and one for control-plane messages.

That would allow these base-fees to fluctuate independently, ensuring that a high-base-fee due to data-plane messages doesn't affect the control-plane base-fee.

[Stebalien]

We'd need an additional field in the block header to specify two base-fees, but tracking these base-fees isn't too hard, really. I'm not saying it's easy, but, at the very least, it wouldn't require new economic modeling (just some design and code).

Now, this is for messages sent from off-chain to storage provider actors (which I assume will be the common case). On-chain messages are trickier because a single "transaction" may perform control-plane operations, and non-control-plane operations. It's possible, but also less critical.

[steven004]

Let's assume that the base-fee for control-plan messages is not higher than data-plane messages. It is reasonable due to the concern mentioned in this discussion. Based on this, the solution is identical as, from the result point of view, partially exempting the control-plane base-fee consumption, i.e. paying back partial base-fee consumption to the storage provider, while we do not change the base-fee mode.

Then, put our thoughts together, it will like:

1. we agree to burn less to make the system sustainable, especially when the base-fee is high to some level;
2. There could be different approaches to implement this:
   i. To have different base-fee mechanisms for control-plane and data-plane messages, this requires block header change, and will lower the cost of storage providers to grow and maintain power;
   ii. To keep the current base-fee mechanism, but only partially burn control-plane messages' base-fee consumption, and return remaining to the sender, the storage provider who grow or maintain power. (this implementation looks kind of ugly, but anyway it could work);
   iii. To keep the current base-fee mechanism, partially burn control-plan messages' base-fee consumption, and dispatch remaining to block generators, as stimulus to prioritize control-plane messages over data-plane messages.

I would prefer approach iii to approach ii since we really want to have control-plane messages to be treated at higher priority, and the first two approaches has no much difference.

[Stebalien]

The problem with option 3 is that small storage providers would effectively be funding large storage providers through gas fees, making it significantly harder to "break in" to Filecoin.

Option 2 is definitely the simplest. I don't like it as much as option 1 because it doesn't auto-balance (we'd have an issue if the data-plane becomes more than twice as valuable as the control-plane), but it doesn't require a significant change and can be tuned with a very simple network upgrade.

(this implementation looks kind of ugly, but anyway it could work);

I'm not sure about this, actually. It requires keeping as set of base-fee multipliers on-hand, but that's not so bad.

[Stebalien]

I'd actually recommend writing a proposal for option 2.

[steven004]

Great. I think this discussion can be closed while a new proposal for option 2 is submitted, since this one was not really thought thoroughly.
But, before submitting a new proposal, I would like to have better understanding of this statement:

The problem with option 3 is that small storage providers would effectively be funding large storage providers through gas fees, making it significantly harder to "break in" to Filecoin.

If we take option 3, as mentioned before, we can set up a simple pool to dispatch the remaining gas-fee to next several rounds' block generators to defend against self-packing attack, making it work like the block reward, refund to storage providers proportionally according to their power ratio.

The option 3 is for prioritizing control-plane messages over data-plane messages, as most networks do, but, if this is not a favor feature, or people do not really think control-plane messages should have higher priority, option 3 is not needed.

[Kubuxu]

As Steb and Jenifer highlighted, the proposal as written cannot work.
For the EIP-1559 to function it is critical that fees are burned, otherwise, block producers gain the ability to manipulate the base fee to an arbitrary level. I'm also not aware of any analysis for colluding block producers in the case of fees being refunded or paid to block producers.

The EIP-1559 has a strong property that if there exists collusion between block producers to lower the base fee and reap GasPremium (reverting to the old Bitcoin-style of network fee system), it is more profitable to defect from the collusion over working within it. This means that such collusions are generally unprofitable and EIP-1559 has only one stable solution.

I'm also not convinced that messages onboarding new storage should be in the same category as messages maintaining the storage.

Furthermore, the split into separate planes of messages has its drawbacks, it works on the assumption that control-plane would be cheaper than the data-plane but it is a questionable assumption. If the split were to be performed, most likely, the control and data planes would be allocated fixed parts of chain bandwidth. This would reduce the bandwidth on each corresponding plane, as underutilisation of either could be filled out without the split.

[Stebalien]

Furthermore, the split into separate planes of messages has its drawbacks, it works on the assumption that control-plane would be cheaper than the data-plane but it is a questionable assumption. If the split were to be performed, most likely, the control and data planes would be allocated fixed parts of chain bandwidth. This would reduce the bandwidth on each corresponding plane, as underutilisation of either could be filled out without the split.

If done properly, splitting into two gas values shouldn't affect utilization.

• If the chain isn't fully utilized, blocks could be mostly filled with control-plane messages and gas would stay constant (because blocks aren't full).
• If the chain is fully utilized, gas for the control-plane/data-plane would go up proportional to use.

Actually, I'd expect the opposite. Right now we have a wave pattern where the base-fee goes up, utilization goes down, base-fee goes down, utilization goes up. With two base-fees, I'd expect the chain to swing from one type of message to the other and maintain a much steadier utilization.