Using gas lanes as a potential solution to FEVM-related gas issues: Mechanism and potential alternatives

[juanpmcianci]

Gas lanes & alternatives

This discussion is largely based on this writeup as well several discussions.

Problem statement.

The Filecoin Virtual Machine (FVM) is quickly rising in popularity and it is posed to attract a larger and much welcome user base to the Filecoin network. However, an as-of-now hypothetical (but serious) scenario that this larger user base might bring is what we call gas gentrification. In short, this refers to the phenomena where demand for FVM-related messages is so high that either

• (i) it drives the base fee upwards to a point where it might become difficult for some miners to submit network-critical messages (such as onboarding, sector recovery of proofs of storage) or
• (ii) that FVM users are simply willing to pay significantly higher tips to get their messages included, and thus pricing out some storage providers.

While the above scenarios are indication of success and adoption for the FVM, we would like to explore options to mitigate/avoid these scenarios. As such, we propose to introduce a version of the EIP1559 mechanism which allows for gas lanes, each with its own base fee and EIP1559-like price-discovery mechanism.

It is also worth mentioning that gas lanes have also been proposed as a solution to the potential gas sprawl issue, described here

Ideal proposed mechanism.

We describe here what would be a straighforward possible economic solution to the gas gentrification problem. As we later discuss, this version may not be the easiest or most feasible to implement, so we later present some alternatives that partly address these difficulties and criticisms.

More precisely, we propose to

1. Classify messages in $L$ different categories. (In the simplest form we would have $L=2$, where one lane would be reserved for SP storage related, or "control plane" messages, including:CompactSectorNumbers, DeclareFaults, DisputeWindowedPost, ExtendSectorExpiration, PreCommitSector, PreCommitSectorBatch, ProveCommitSector, ProveCommitAggregate, ReportConsensusFault, SubmitWindowedPoSt and TerminateSectors. The second lane would accommodate all other types of messages)
2. Divide the available block space into $L$ non-overlapping lanes of maximum width $w_\ell$ and target size $B_{\text{target},\ell}$.
3. Equip each lane with its own EIP1559-like transaction fee mechanism; i.e., assigning a base fee $p_{\ell,t}$ to each lane. This base fee gets adjusted on an epoch-to-epoch basis according to:

$$p_{\ell,t+1}=\text{max}\left(p_{\ell,t}\left(1+\frac{1}{8}\frac{G_{\ell,t}-B_{\text{target},\ell}}{B_{\text{target},\ell}}\right) , p_{\ell}^\text{min}\right)$$

with $p_{\ell}^\text{min}>0$ the minimum base fee to be paid per lane and $G_{\ell,t}$ the gas used on lane $\ell$ at epoch $t$. The target block sizes are subject to the constraint $\sum_{l} B_{{\rm target},l}\le B_{\rm target}$, where $B_{\rm target}$ is the current EIP-1559 target block size parameter. Generally the targets, $B_{{\rm target},l}$ could also change with time depending on network conditions.
Given this, the proposed multi-lane EIP1559 mechanism would proceed as follows:

1. For each class of message $c_\ell=1,2,\dots,L$:
   • Miners select the messages of class $c_\ell$ that they would like to include, according to their strategy $\mathsf{S}$, taking into account the the maximum block size for this class of messages is $w_\ell$ and the target utilization is $B_{\text{target},\ell}$. The total gas limit from each class of message is given by $G_{\ell,t}\leq w_\ell$.
2. The base fee for each lane gets updated according to the price-update function in Equation (1).

Under the scenario outlined above, we would need to define $3\times L$ parameters, namely $w_\ell$, $B_{\text{target},\ell},$ $p^\text{min}_\ell$, $\ell=1,2,\dots,L$. These parameters would need to be defined from the begining of the implementation, and might need to get adjusted over time.

Difficulty

It is not immediately clear whether gas lanes can be implemented. This is due to the fact that it is not always possible to identify the class of a message apriori and charge gas for it accordingly. This has been expanded upon by Anorth in the following bulletpoints:

• A top-level Filecoin message has some sender, receiver and method. The sender of the top-level message pays gas for the whole message execution. So this top-level message is what needs to be assigned to a lane.

• With user-programmed contracts, a top-level message might go to some smart contract, which then makes an internal call to a storage method. But we can't tell that without actually executing the message.

• Even if we did do some pre-execution to tell, this could then be abused to get cheap execution of non-storage work, by a contract that first called a trivial storage method (to get assigned to the cheap lane) and then did a bunch of expensive stuff that the user really wanted

An in-principle idea here is for every message to consume gas from various different lanes, however, core devs have expressed that the implementation of this is really complex.

Alternatives.

Here we summarize some of the alternatives that have already been discussed in private channels.

Dynamic internal fees.

One could, in pricinple, introduce a dynamic fee mechanism (EIP1559-like, or otherwise) to the amount of gas usage per method. This would not be a "gas lanes" approach, but rather a "resource pricing" mechanism, such as the one discussed by Diamandis et. Al.. In this setting, we would keep track of the gas used by each type of trasaction $\ell$ (internal or otherwise) and multiply the amount of gas used by an epoch-dependent factor $\alpha^\ell_t\in\mathbb{R}_{>0}$, which can either be a discount factor $(\alpha^\ell_t<1)$ or a "penalty" $(\alpha^\ell_t>1)$, with the understanding that $\alpha^\ell_t$ gets adjusted dynamically acording to some given criteria.

This would require carefully defining the update rule for $\alpha^\ell_t$, based on the global state of the chain, and would be subject to various constraints, such as a (positive) minimum value for each method.

Proof separation.

Anorth has alternatively, proposed to separate proof fees from execution gas. This can read in more detail here and here. As originally proposed, the goal is to have dynamically-priced onboarding fees, separate from the current EIP1559-driven gas cost. That is, these fees are meant to be a function of, e.g., {time-weighted average of onboarding rate, duration, sector size, baseline}, but not base fee. In theory though, this separation could be extended to other methods.

One way to "simulate" a gas lane is by combining these two approaches together, providing a heavy discount factor to control plane messages, mostly excempting them from base fees, while compensating that discount with explicit proof fees. Non-control-plane messages will still be subject to paying standard base fees, creating a separate pricing for control-plane messages.

Fee reimbursement.

A third alternative idea is to introduce a "fee-reimbursement" mechanism. In this setting, instead of burning 100% of the fees from gas usage (as currently done in the EIP1559 mechanism), a fraction of them can be burned and then the rest is given back to SPs. In this setting:

1. SPs pay an overestimated amount of gas
2. We internally keep track of track of the amount of gas used per transaction.
3. For a predefined period $P$ (e.g., a day), we keep track observe how much gas fee was burned overall by messages of type $\ell$ (say, control-plane messages).
4. Add X% of this number to to next period's $P$ minting.

This approach might require SPs to set up rather high limits on their gasFeeCap, which can potentially become problematic from a UX perspective. This mechanism also resembles that of token allowances from other networks (e.g., Ethereum), so there might be some security implications from it.

Other critiques & considerations

Gas lanes and the alternatives presented above still present some issues that need to be discussed. We list some of these issues bellow.

1. Added complexity. One potential drawback of the gas lanes model is the added complexity it introduces, as miners and users need to manage lane-specific parameters, such as lane widths, base fees, and target consumptions. This complexity could make it more difficult for users to estimate transaction costs and for miners to efficiently select transactions. Additionally, the gas lanes model might require more frequent monitoring and updates to keep lane parameters in line with the network's current state. This could lead to increased overhead for network operators and a higher chance of suboptimal adjustments if the monitoring and updating processes are not executed effectively.

2. Lane definition. The number of lanes $L$ in the proposed model needs to be carefully defined. Indeed, one could consider having e.g., 2 lanes, one for FVM messages and one for non-FVM, or 3 lanes, one for onboarding, one for PoSt, and one for everything else (including FVM), or many other choices. Furthermore, the choice of $L$ can have a significant impact on the efficiency and flexibility of the network.
A larger number of lanes allows for finer granularity in segregating transactions based on factors such as gas prices or priority levels. This in turn could lead to a more efficient allocation of resources and better handling of congestion. However, increasing the number of lanes can also result in added complexity for both miners and users, making it more challenging to determine the optimal lane for a transaction or to adjust lane parameters effectively. Therefore, when choosing the number of lanes, it is essential to strike a balance between granularity and simplicity to maintain efficient network operation.

3. Non-identifiability. This is the scenario where it is not immediately obvious whether a message belongs to a given class or not. In the 2 lane case, for example (FVM Vs. Maintenace), a contract that takes care of submitting maintenance would be difficult to classify in either group. This distinction would need to be analyzed in detail.

4. Multi-dimensional knapsack problem solved by the miners. Introducing gas lanes results in a "multi-constraint" knapsack problem for the miners when deciding which blocks to pack (in the setting where they want to maximize miner tips). This problem is NP-hard, which means finding an optimal solution can be computationally intensive. However, miners can employ heuristic or approximation algorithms to obtain near-optimal solutions within reasonable time frames. These algorithms can consider factors such as transaction fees, gas prices, and priorities to create a balanced and profitable block, however, it is unclear to us if this would represent a significant techincal challenge.

5. A free market solution? It is important to mention that block-packing and hence, base fee, are largely miner-dependent. Thus, there is always possibility that miners will try to "self-preserve", becoming more selective of the messages they decide to include on each block. As a very simple example, miners (or a sizeable proportion of them) could, in principle, shift towards prioritizing messages that they can identify as being storage-related. This could, in principle, solve the gentrification problem by itself. However, there is a lot of nuance in this scenario, and the CEL is currently working at understanding this situation in more depth.

[Fatman13]

Great proposal! Absolutely needed to secure SP's maintenance needs.

The number of lanes in the proposed model needs to be carefully defined.

I think the bottom line for SPs is to have winning and windowPost go through without being burdened with extra gas cost from raised basefee from fevm related messages.

[stuberman]

Even PublishStorageDeals fee is very high. PoST is needed for survival, other fees relate to sealing. Right now sealing deals is unprofitable.

[stuberman]

This matter is extremely urgent, SPs are no longer sealing due to gas fees being exorbitant.
Per fgas 1 PiB has a 3,000 FIL gas cost.

[scotthconner]

How does this being urgent match up with the write-ups seemingly hypothetical problem? Are gas lanes urgent, or is SP profitability urgent? Is gas lanes THE mechanism to solve this problem, or one potential consideration? Are there other levers that could be pulled to make sealing rational, etc, or is gas lanes the only way to achieve it?

[SealStorage-Jacques]

This is a great idea and much needed for the network.
It would be useful to also revisit batching as it doesn't work "great" and the cost for batching shouldn't high when the gas fees are low which causes SPs to oscillate back and forth and then further causes traffic issues causing GAS spikes, basically it should be possible to run with batching permanently enabled with having to over pay when gas is actually low.

[LaurenSpiegel]

Classify messages in
different categories. (In the simplest form we would have
, where one lane would be reserved for SP storage related, or "control plane" messages, including:CompactSectorNumbers, DeclareFaults, DisputeWindowedPost, ExtendSectorExpiration, PreCommitSector, PreCommitSectorBatch, ProveCommitSector, ProveCommitAggregate, ReportConsensusFault, SubmitWindowedPoSt and TerminateSectors. The second lane would accommodate all other types of messages)

Why is PublishStorageDeal not included?

[juanpmcianci]

Thanks for the comment, Lauren. That list was mostly meant as an example.

[luckyparadise]

@juanpmcianci many thanks for putting together this proposal. Is this something you are actively working on? How soon do you think you can draft a FIP for this? Lastly - are you happy to present this at our next Core Devs call this week?

[ZenGround0]

An in-principle idea here is for every message to consume gas from various different lanes, however, core devs have expressed that the implementation of this is really complex.

Is there a summary of this argument? It's not clear to me why it would have to be a particularly complex extension of FVM gas accounting. Here is a draft of a solution: privileged system actor methods could signal a context change and start accounting for gas in a different lane's context. Message limit applies over all lanes but block gas limit is accounted for given the current lane's context. At end of execution FVM returns gas used in each lane and different base fees are applied. It's not clear we'd even need to change message or header structure, though we'd probably want to modify receipts for GasUsed per lane. Where does this solution break down?

[scotthconner]

I feel like that argument has origin in the line of thinking expressed under "Difficulty":

Even if we did do some pre-execution to tell, this could then be abused to get cheap execution of non-storage work, by a contract that first called a trivial storage method (to get assigned to the cheap lane) and then did a bunch of expensive stuff that the user really wanted

What we'd want to see is which actions would give a message a cheaper "consensus" gas price. Here, the author is suggesting there are schemes where small insignificant methods could provide access to cheaper non-storage related execution. Essentially, gaming it.

A solution needs to contain a crisp identification of what must be executed to get a different lane priority. For instance, start with only PSD and WindowPOST. This way, significant activity must be undertaken to even produce a valid message to begin with. I think the origin of the discussion is assigning the entire message to a gas lane.

What it sounds like you're describing is a situation where only certain portions of the execution path get the discount? In this way, you're saying any such gaming wouldn't be rational as the discount would only go towards certain activities?

[ZenGround0]

What it sounds like you're describing is a situation where only certain portions of the execution path get the discount? In this way, you're saying any such gaming wouldn't be rational as the discount would only go towards certain activities?

Yeah exactly. We are free to modify both system actors and FVM which should be enough to exactly distinguish between lanes at execution time and get perfect accounting of storage lane gas versus other gas. I don't know the details of wasm instruction instrumenting implementing gas so this approach might break down somehow. But we should understand and communicate how before committing to more complicated solutions.

[Stebalien]

An in-principle idea here is for every message to consume gas from various different lanes, however, core devs have expressed that the implementation of this is really complex.

This would require modifying the message format to include multiple gas limits and base-fees (one per lane). Annoying, but doable. It also complicates message selection (we're effectively selecting for multiple blocks). But that's also doable.

However, I'm confused by:

Divide the available block space into $L$ non-overlapping lanes of maximum width $w_\ell$ and target size $B_{\text{target},\ell}$.

Doesn't this assume that demand is identical for all lanes? Otherwise, we're wasting chain bandwidth. E.g., with two lanes and one dedicated to windowed posts, we'd be wasting ~25% of chain bandwidth at all time (windowed posts only take 25% off chain bandwidth, not 50%).

I don't think we want per-lane block gas maximums. Instead, we likely want a target block gas distribution.

[ZenGround0]

This would require modifying the message format to include multiple gas limits and base-fees (one per lane). Annoying, but doable.

I'm not convinced this is necessary. What about GasLimit is the sum of all gas from all lanes. GasFeeCap is just the maximum basefee from any lane the message will be accepted at? We lose some potential user control over spending in different lanes but the current user interface is unchanged.

In particular: 1) a message never spends more than GasFeeCap*GasLimit 2) GasLimit is always spend greedily on whatever expenses execution encounters first

[AxCortesCubero]

I agree here, the description you quoted is not exactly what I have in mind, which is that gas lanes would be only about assigning different target sizes only, but any one given block, any lane is able to occupy the whole block by paying extra tips, just that that will cost them, that will increase that lane's base fee the next epoch, as well as reduce the base fee of the other lane, which would encourage going back to the targets.

One can conceive of gas lanes with separate maximum sizes, or without, I think without makes more sense to add some flexibility.

we'd be wasting ~25% of chain bandwidth at all time (windowed posts only take 25% off chain bandwidth, not 50%

In any case, we'd want also a mechanism that selects an appropiate lane size. If windoed posts require only 25%, then we wouldnt give them a lane that is 50% wide. Though that requires a mechanism to properly decide what the appropiate sizes of lanes should be at a given time. For instance a windowed post gas lane could have a size that is in some way proportional to network raw power.

[Stebalien]

That seems reasonable. However, we would need multiple gas limits if we want to have separate block gas limits per-lane (which we probably don't want anyways).

[anorth]

Notes from a discussion between @AxCortesCubero @Kubuxu @ZenGround0 and @anorth.

Problems

• Total block space is fixed. Mechanisms act differently under contention.
• We can’t generally identify which "lane" a message belongs to from the outside, but can feasibly do so for regions of execution within a message.
• We need fees to encourage SP efficiency, cannot give complete refunds etc

Approach 1 – require external but imperfect identification of message lanes

• Most messages that will be essential will use a known set of message numbers, and those methods can be constrained not to invoke user-programmed code. Make a gas lane for those messages only. Calls indirected through smart contracts etc won't get the discount, but are  probably deriving some value from that behaviour that may compensate.
• Potential to stifle FVM-based innovation, e.g. access control contracts.
• With no urgent issue, shouldn’t we try to build something better? This is temporary – we’d want to re-solve this in the future.
• We could settle on this in an emergency, but still significant work to do to actually roll it out. Policy decisions about lane width, function to vary the split, etc.

Approach 2 - single message multiple lanes

• Within message execution, account for multiple lanes in FVM. During certain syscalls, switch lanes to account against different lane. Each lane has a base fees etc.
• Gas lanes need target widths summing to total block target etc.
  • Adjusting the targets is the control mechanism. Target determines the base fee for given demand levels.
  • Policy needed for dynamic adjustment of widths, embodying the priority of storage-related messages
• Should lanes have limit = 2x target? Or can any lane take the whole block?
• When lane target exceeded, base fee for that lane increases (and others decrease if below target)
• Cost-efficient inclusion for storage message is given by a sufficient lane target for them.
  • Competition in other lanes will increase those lanes' base fees, but not the storage lane. Storage message will need to set higher miner tip than other message to ensure inclusion in any block, if sufficient message in other lane willing to pay the base fee.
• Would we need to change the message format? Single gas limit, price etc for multiple lanes can probably work.

Approach 3 - base fee discounts

• Account gas units used in multiple lanes (FVM, e.g. at syscalls) but within a single block target & limit
• Apply a discount to the base fee for consumption in different lanes.
• SPs ensure inclusion of storage messages by setting a higher miner tip, with total cost reduced by the base fee discount
• No multidimensional base fee. The control mechanism is the discount rates rather than lane target throughputs.
  • Do we need dynamic adjustment of lane discounts?

A specific, simplified instance of this approach 3 is 100% discount of gas consumed in a single storage-operations lane.

Approach 4 - refunds for power (pseudo gas lanes)

• Look at total network power growth and maintenance, infer gas usage needed for that
• Give back some FIL to SPs later based on their power and growth, e.g. through block rewards (hard to do fairly?)
• Requires policy for the refund amounts for onboarding, snapping, maintenance
• Refund needs to scale with congestion, as measured by base fee over the period

Explicit proof fees

• Recapture network revenue potentially given up by gas lane mechanisms that discount base fee.
• Also valuable for other reasons, removing batch balancer, revenue despite technological progress on execution throughput

[anorth]

Note that in both approaches 2 (assuming lane target but no limit) and 3, storage messages still need to compete with other messages on miner tip. If there enough messages in each lane willing to pay the base fee for that lane, then the miner will chose those with higher tip. A non-storage message can compete effectively with storage messages by offering a higher tip. The total cost of that message will be higher (high lane base fee, or no discount), but among parties willing to pay the base fee, this reverts to a first-price auction.

The most significant difference between the two mechanisms is that, given a lane target, the base fees will adjust according to the EIP-1555 mechanism so that, say, high-value non-storage messages can't dominate for long before pricing themselves out. A similar result may be achieved with dynamic adjustment of lane discounts, depending similarly on targets and usage.

Because the miner tip is revenue to the miner, miners may be fairly ok with competing on it. With a sustained higher miner tip, miners will earn it according to power (while spending it according to power and growth), so for them it's just moving tokens around inside their group. The higher miner tip from non-miner users is revenue to the miner collective that might otherwise have been burnt, so these mechanisms effect a small redirection of funds from base-fee-burn to miner revenue.

[anorth]

It's worth thinking about how such mechanisms could be introduced gradually, initially having only weak effects which we can observe and learn from.

For multidimensional base fee lanes, the minimum perturbation might be a lane target adjustment mechanism that reacts to changing demand quite quickly, and has only a slight bias for the storage lane. This would most closely approximate having no lanes, but with a delayed response.

For discounts, the minimum perturbation would a small discount, perhaps with no dynamic adjustment.

[juanpmcianci]

Here's a comparison among the proposed implementations/alternatives of gas lanes. The full document can be found here

• From the table above, it would make sense to investigate A2, A3, and A5 in more depth. We will be focusing on A3 in the next weeks, as it is not as well-understood as A2.
• A similar study will be conducted with more quantitative aspects.
• Gentrification is currently not an issue, however, the network is experiencing high gas costs driven by other factors, such as PSD. It would be worth it to discuss avenues for how to either include these messages into the gas lanes model OR discuss a separate solution to that extent.

[jennijuju]

this refers to the phenomena where demand for FVM-related messages is so high that either

according to @Kubuxu - "FEVM messages represent 0.48% of chain bandwidth over the last 7 days. "

• is this demand worth complicating the network gas mechanism (not a simple one)?
• if this is for future proofing:
  • whats the % of FVM related messages of the total network messages worth adding such complexity?
  • do we have any guess on when that % may be reached, or how can we define the signal for it?
• With the effort to pushing more operations to user land, I see a world where miner proxy contracts/ staking contracts/SP pool contracts that could exist where SP operations (like PSD, terminate sectors, extend sectors and so on) are handled in user actor. Are they then considered as SP lane or FEVM lane?

[AxCortesCubero]

We completely agree FVM messages are not a large problem right now, and are not the reason base fees have been higher recently. I think our estimates are higher than that 0.48%, but still the statement is the same.

is this demand worth complicating the network gas mechanism (not a simple one)?

In my view it is worth having a concrete solution ready and quick to deploy, if this should become a large problem suddenly, as it could. As long as FVM usage remains this low, sure it is not worth implementing and adding complexity.

if this is for future proofing:
whats the % of FVM related messages of the total network messages worth adding such complexity?

Kind of yes for future proofing, to be ready with a solution. The percentage at which it becomes a problem is a bit hard to define, more importantly is about whether FVM is affecting normal SP operations: FVM drives up gas to a level that first it affects sector onboarding, and in a more extreme case sectors start failing because it is not worth paying for Window PoST anymore.

First signals would be related to onboarding, but harder to define, something like: has there been a reduction in onboarding rate, and that seems to be caued with an increase in base fee and and increase in the amount of gas in the average block that is used by FVM?

With the effort to pushing more operations to user land, I see a world where miner proxy contracts/ staking contracts/SP pool contracts that could exist where SP operations (like PSD, terminate sectors, extend sectors and so on) are handled in user actor. Are they then considered as SP lane or FEVM lane?

Yes, that is the problem of message identification that we have been discussing here. It would be easy to just give a separate lane to pure "SP messages" sent directly from an SP, and not give that benefit to "mixed messages" where the storage messages are sent from some user defined actor with a mix of other messages. That is the A1. Restricted gas lanes option described above in @juanpmcianci 's message. That has the advantage of being easy to implement, but not super future proof. A better solution with more time for development would be the others described, that can account properly for mixed messages sent from user actors.

[anorth]

is this demand worth complicating the network gas mechanism (not a simple one)?
if this is for future proofing:
whats the % of FVM related messages of the total network messages worth adding such complexity?
do we have any guess on when that % may be reached, or how can we define the signal for it?

This level of demand isn't a problem. These mechanisms are to handle the inevitable changes to that situation. The fact that user gas usage is so low now, while FEVM is new, only serves to leave a lot of room for it to get soooo much worse. And this is something that can change very quickly.

The fraction of FVM messages isn't a great metric, though it is hard to come up with really good ones prospectively. What really matters is the total gas costs of onboarding and maintaining storage, how that relates to total SP returns, and how much non-storage messages are changing that from what it otherwise might be. Even a small non-storage message fraction could have a big impact if, say, maintenance required most of the chain bandwidth (not the case today).

The table above looks pretty good to me. I will be really sad if we get forced into implementing A1 due to an all-too-possible rapid change in circumstances. It will represent eng-months of work, and eng-months more work to back it out and replace with something better. I think that A2/3 will work, even if we need to tweak parameters after initial implementation and perhaps add A5 to balance network revenue.

[jennijuju]

submit network-critical messages (such as onboarding, sector recovery of proofs of storage) or

I would like to argue that DisputeWindowPoSt/ReportConsensusFault/sector recovery/window post message are more critical than new onboarding messages. Try to phrase in original post's language:

In short, this refers to the phenomena where demand for onboarding sectors messages is so high that either

(i) it drives the base fee upwards to a point where it might become difficult for some miners to submit network-critical messages like consensus fault report, bad storage dispute,proof of storage or recover proof of storage.
(ii) that SPs are simply willing to pay significantly higher tips to get their messages included, and thus pricing out network security critical messages and reduce the incentive for network participants to steward network consensus/secuirty (I.e: message fee > rewards)

[AxCortesCubero]

This is a question that is kind of left open here for community discussion. We generally talk about "sp messages" vs "general FVM".
That is a start of the conversation, but for sure we could decide that could be further refined, "sp messages" can do a number of different things.

The first distinction for me would be between "onboarding" messages and "maintennance" messages, we could decide that one function needs gas lanes more urgently than the other. But one could also separate different ways "CC sectors" vs "Deal sectors",...

So that's part of the point of this discussion, we should agree on what categories we'd want to separate.

[Kubuxu]

(ii) that FVM users are simply willing to pay significantly higher tips to get their messages included, and thus pricing out some storage providers.

Given the basefee system, this state is very transient. Competition on the mining tips (GasPremium) only happens when the basefee is lagging behind demand due to the rapid adaptability of the basefee, the basefee will quickly catch up.

[AxCortesCubero]

Yes this statement is transient, about how that will happen, FVM will gain more space in the block by paying higher tips. Then it is true, the base fee will go up, to a level where only FVM users, and a smaller fraction of SP's are willing to pay that amount. So higher tips is a statement of how we are going to get there, and higher base fees is a statement about how we're going to stay there.