Audit Lotus's default gas params

[arajasek]

We should make a pass over default gasfeecaps (and any other gas-related params) in Lotus. The task should be roughly:

• Build a table of the existing gas-related defaults (there's at least MaxPreCommitGasFee, MaxCommitGasFee, MaxWindowPoStGasFee, MaxPublishDealsFee, MaxMarketBalanceAddFee, maybe more?)
• Estimate what each of these messages are "worth", in terms of the cost of them not landing on time
• Either propose changing the current default, or justify the existing cost
• Analyze the impact of base fee spikes driven by these values -- will smaller / poorer miners be severely affected? Should we consider lowering the defaults based on what would be best for the network?

[momack2]

• Also include what the resulting network parameters will be if the entire network operates with the default values - ex what will the result be for BaseFee, etc.
• "cost of not landing on time" should try to set a good maximum that will create a healthy network for all miners, not that only works for the max size miner or an average miner (ex, defaulting WindowPoSt to 50 FIL makes no sense for a small miner who has much less than 50FIL)

[whyrusleeping]

We should also try to write down and iterate on our 'gas pricing theory', that is, how should people be thinking about what gas prices to set for a particular message?

Caution, general exploration of the problem space ahead:

In each of these cases, the message landing on chain within some given time frame has a particular value to us. The gas fee CAP we specify is the Maximum value we are willing to pay to make that happen. If the chain is going to demand more than that, we are fine with it not getting in on time. That said, pricing theory should probably adapt to certain bits of knowledge about how long your deadline is (~10 minutes for windowed post is very different than 24 hours for ProveCommit, but that ProveCommit is likely to be head of line blocking other messages you might want to land... so...)

A separate value we can specify is the GasPremium, the gas premium is what we typically think about when discussing gas fees, its paid to the miner as an incentive to include your message over the messages of others. Since we have the network base fee, this tends to get forgotten a bit, but its still pretty important. The fee cap still gates how much you might pay in total, but the gas premium value specifies how much of that value could go to the miner, increasing the minimum amount you might pay.

So, all of these things really only matter if the chain is full. If the chain is not at capacity, theres no reason for all messages to not make it onto the chain as they come in (barring external incentives, and the fact that a message with no gas premium probably isnt worth a miners time to include). When the chain is 'full' this means there are enough messages to fill up 100% of the chains 'available' space. However, the chain always has 'extra' capacity that can be used, but using this capacity increases the network base fee. A 'steady state' congested network is one where all the messages being sent center around a particular fee cap value, and the chain will end up using only 100% capacity (on average). This happens because if the fee is low enough to include >100% capacity, then the fee goes up, and fewer messages make it into the next tipset, which lowers the base fee again. When the chain is in this state, you can change either or both of the fees to get your message included more quickly:

Increasing the base fee of your message under congestion ensures that when the base fee oscilates back upwards next, the chain will have space for your message to be included. This does not necessarily prioritize your message, but it does result in it getting included as soon as base fees rise above the median. (which, given the spikiness of the base fee mechanism, happen often). If you have honestly priced your message, and the rest of the network are honestly pricing their messages, then this gets your message in quickly without any other side effects, however if the network is not honestly pricing messages, someone specifying a higher fee can cause a change in the median which shifts the congestion fee baseline higher.

Increasing the gas premium of your message will cause miners to prioritize your message above other messages within the same candidate inclusion pool. That is, if your message can get into a particular block, and you increase the gas premium, your message can jump the queue ahead of other messages that can make it into that particular block. However, in a steady state of network congestion, this won't have much of an effect because the network base fee takes priority on claiming funds from your messages fee, so if your fee cap is right at the limit of being includable in a block, the miner won't get much anyways.

Given all that, it seems prudent to give the miners enough of a premium to bother processing your message, then set the fee cap to satisfy HonestMessageInclusionValue / GasLimitEstimate = FeeCap. Determining HonestMessageInclusionValue then ends up being the hard part, since it depends on time. If a message is worth 10FIL to me IFF its included in the next 30 blocks, but if it slips past that deadline you might end up paying a high gas fee anyways. (Note: We should really have a mechanism to invalidate a message after some time...)

[whyrusleeping]

Heres the current defaults, along with some average gas limit values for those messages, and implied base fee numbers:

| Method       | Default Cap in FIL | Typical Gas Limit | Implied Fee Cap (nanoFIL) |
| ------------ | ------------------ | ----------------- | ------------------------- |
| PreCommit    | 0.05               | 32108808          | 1.557205113               |
| ProveCommit  | 0.05               | 63940120          | 0.7819816416              |
| WindowedPost | 50                 | 836837040         | 59.74878932               |
| PublishDeals | 0.03               | 55929717          | 0.5363874807              |
| AddBalance   | 0.01               | 6301760           | 1.586858275               |
| Overall      | 0.1                |                   |                           |

[whyrusleeping]

Right off the bat i'll note that 0.1 for the 'unspecified default' seems way too high. That should probably be 0.01 or less.

[whyrusleeping]

And here's a recent collection of chain usage (as a percentage of block gas space used) by method:

By Method:
ProveCommitSector	57.45%	(total: 8981604771489, count: 140469)
PreCommitSector	24.98%	(total: 3904687955783, count: 121608)
SubmitWindowedPoSt	14.05%	(total: 2196697231341, count: 2625)
PublishStorageDeals	3.18%	(total: 496935538014, count: 8885)
AddBalance	0.24%	(total: 37671923322, count: 5978)
DeclareFaultsRecovered	0.09%	(total: 14341361856, count: 356)
Send	0.00%	(total: 557474815, count: 875)
DeclareFaults	0.00%	(total: 526268495, count: 22)
WithdrawBalance	0.00%	(total: 205821986, count: 30)
CreateMiner	0.00%	(total: 133215467, count: 6)
ChangeMultiaddrs	0.00%	(total: 17666848, count: 16)
ChangeOwnerAddress	0.00%	(total: 16093356, count: 2)
Propose	0.00%	(total: 5976715, count: 2)
ChangeWorkerAddress	0.00%	(total: 2763212, count: 2)
ChangePeerID	0.00%	(total: 1091678, count: 1)

[momack2]

Ideally we should ship any low-hanging fruit in 0.10.1. Any obviously wrong things we can stick into a PR to begin correcting things? @arajasek

[arajasek]

Based on an analysis, only minor changes were deemed appropriate and shipped in #4408