<a id="sectionSpec"></a>
## Specification
<!--The technical specification should describe the syntax and semantics of any new feature. The specification should be detailed enough to allow competing, interoperable implementations for any of the current Filecoin implementations. -->

The following equation describes the main part of the change, that is, replacing $s[i]$ by $s_{\textit{avg}}[i]$. For $q\in (0,1)$,

$$s_{\textit{avg}}[i] \triangleq \frac{1-q}{q}\sum_{k=1}^{\infty } q^k\cdot s[i-k+1]$$

which simplifies to the recursive form
$$s_{\textit{avg}}[i] = (1-q)\cdot s[i] + q\cdot s_{\textit{avg} }[i-1].$$

The change to the learning rate $\phi$ (from constant to adaptive), is defined by the following rule with parameters $\alpha$ and $\gamma$, and is bounded to be within $[\phi_{\min},\phi_{\max}]$.
$$\text{if } (1-\gamma){s^* } \le s_{\textit{avg}}[i]\le (1+\gamma){s^* } \text{ \hspace{0.5cm} then \hspace{0.5cm} } \phi[i+1] \gets \max \left( \phi[i]-\alpha, \phi_\min \right) $$
$$\text{ else \hspace{0.5cm} } \phi[i+1] \gets \min \left( \phi[i]+\alpha, \phi_\max \right) .$$

This scheme provides us with multiple knobs that can be adjusted:
- $q$ - which determines the concentration of the average. Roughly, smaller $q$ values result in $s_\textit{avg}$ resembling the very last block sizes, while larger $q$ values smoothen the average over a longer history.
- $\alpha$ - the additive term used to increase and decrease the learning rate. Larger $\alpha$ values result in faster adjustments to changes in demand but might lead to instability.
- $\gamma\in(0,1)$ - the threshold for deciding if the average is "close" or "far" from the desired block size. A "far from desired" average results in an increase of the learning rate while a "close" results in reducing the learning rate.
- $\phi_\min\in(0,\phi_\max)$ - the minimum learning rate. Roughly, the smaller $\phi_\min$ is, the more stable the system is in case of an approximately stable demand. However, small $\phi_\min$ values make it longer to adapt to changes in demand.
- $\phi_\max\in(\phi_\min,1)$ - the maximal learning rate. Roughly, the larger $\phi_\max$ is, the faster the system can adapt to sudden changes in demand. However, large $\phi_\max$ values can lead to cases of instability of the base fee even when the demand barely changes.

### Parameter setting
Setting the right parameters is a work of art more than science, and it depends on the particular characteristics of the system. Therefore, tuning these parameters will require extensive data and experiments after Filecoin launches FVM and demand patterns emerge. Nonetheless, leaving the update rule unchanged is also a choice with unforeseeable consequences.

Below is a possible option for the initial parameter setting (which is based only the [honeymoon data](https://arxiv.org/pdf/2110.04753.pdf) from Ethereum --- blocks 12935000 to 13079999).
- $q = 0.5$
- $\alpha = 0.025$
- $\gamma = 0.25$
- $\phi_\min = 0.0125$
- $\phi_\max = 0.75$

### Additional info
EIP-1559 allows for a variable block size, but a valid block size must be in the range $s[i]\in[0,2s^*]$.

Unlike in Ethereum, in Filecoin the value $s[i]$ is determined not by a single block's size but [by the average size of a block in the previous tipset](https://spec.filecoin.io/#section-systems.filecoin_vm.gas_fee). This affects the issue from both sides. On the positive side, the averaging reduces the profitability of bribing a single miner. On the negative side, given the possibility to choose different tipsets to build ontop, a rational miner might be incentivized to choose the "emptier" tipset in order to reduce the base fee for its current block, thus affecting the present and not just the future.

## Design Rationale
<!--The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work, e.g. how the feature is supported in other languages. The rationale may also provide evidence of consensus within the community, and should discuss important objections or concerns raised during discussion.-->
An intuitive option for the Transaction Fee Mechanism (TFM) that adjusts supply and demand economically is *First price auction*, which is well known and studied. Nevertheless, in Filecoin the choice was to use EIP-1559 for the TFM. In this proposal, our design goal is to improve the TFM (of EIP-1559) by mitigating known problems that it raises. It is important to note that these problems do not yet inflict the Filecoin network. If Filecoin gains traction, however, they are expected to rise. We may want to prepare for this beforehand.

The suggestion is composed of two parts: (i) using an average over epochs of block sizes rather than only the latest, and (ii) using an adaptive learning rate. The first part is the basis of the proposal. The second is an additional improvement (that depends on the first part being implemented). We therefore discuss them separately.

### $s_\textit{avg}[i]$ instead of $s[i]$
The change is based on [this work](https://drive.google.com/file/d/1o_47aiN1BWegOmG8utYh4a47TM0OOa12/view?usp=share_link) that described a rational strategy in which bribes are profitable. Choosing to average based on a geometric series weights results in two desired properties: (i) the computation and space complexity are both in O(1), and (ii) the average gradually phases out the impact of a single outlier block without causing significant fluctuations in the base fee.

### Having an adaptive learning rate instead of $\phi=1/8$
This suggestion is based on a [research work](https://arxiv.org/pdf/2110.04753.pdf) dealing with the learning rate in Ethereum, which was arbitrarily set to $\phi=1/8$. Intuitively, a hige value of $\phi$ leads to more instability, while a low value of $\phi$ leads to slow adaptations to changes in demand. Having $\phi$ adaptive rather than constant seems like a good way to go. In particular, Additive Increase and Multiplicative Decrease (AIMD) was considered in this [paper](https://arxiv.org/pdf/2110.04753.pdf). AIMD has the benefit of reducing larger $\phi$ values faster than smaller $\phi$ values, but requires the tuning of an extra parameter -- $\beta\in(0,1)$ -- which determines the Multiplicative Decrease rate. For their suggested parameters of $\alpha=0.025$ and $\beta=0.95$, however, the difference between AIMD and AIAD does not appear to be significant. Therefore, we suggest to first consider the simpler Additive Increase Additive Decrease method.

## Backwards Compatibility
This change requires a hard fork since the base fee is enforced (for blocks to be considerd valid).

## Test Cases
To early to say

## Security Considerations
<!--All FIPs must contain a section that discusses the security implications/considerations relevant to the proposed change. Include information that might be important for security discussions, surfaces risks and can be used throughout the life cycle of the proposal. E.g. include security-relevant design decisions, concerns, important discussions, implementation-specific guidance and pitfalls, an outline of threats and risks and how they are being addressed. FIP submissions missing the "Security Considerations" section will be rejected. A FIP cannot proceed to status "Final" without a Security Considerations discussion deemed sufficient by the reviewers.-->
The more complicated a mechanism is, the more it is vulnerable to unforeseen security threats. The case of EIP1559 is just one example of it. We hope to mitigate those risks, however, discussions might show us differently.

## Incentive Considerations
<!--All FIPs must contain a section that discusses the incentive implications/considerations relative to the proposed change. Include information that might be important for incentive discussion. A discussion on how the proposed change will incentivize reliable and useful storage is required. FIP submissions missing the "Incentive Considerations" section will be rejected. An FIP cannot proceed to status "Final" without a Incentive Considerations discussion deemed sufficient by the reviewers.-->
The proposal is designed to improve the incentive compatibility of the TFM. A [game theoretic analysys](https://drive.google.com/file/d/1o_47aiN1BWegOmG8utYh4a47TM0OOa12/view?usp=share_link) shows that a TFM based on EIP-1559 encourages bribes. Roughly, because the base fee in the next block depends on the size of the the current block, a miner that creates an empty block reduces the base fee of the next block by a factor of $\phi$. The opportunity cost for mining an empty block instead of a normal block is only the tips it contains. Thus, the cost of bribing a miner is only compensating it for the lost tips. In case the base fee is significantly larger than the tips, the bribing user gains a significant reduction in the base fees of the next block, making the bribe profitable.

One of the main goals of EIP-1559 was to simplify the bidding for users. It was articulated [theoretically by Roughgarden](https://timroughgarden.org/papers/eip1559.pdf) as users bidding their honest valuations being an optimal strategy. In contrast, when using first price auctions for the TFM (as done by Bitcoin and previously in Ethereum), it is typically sub-optimal for a user to bid its honest valuation. In other words, a TFM that encourages users to not fully reveal their preferences is considered less good. However, our opinion is that a TFM that encourages bribes is worse than a TFM that encourages not revealing one's full preferences.

We believe that a first price auction is the best way to go regarding TFMs, however, Filecoin chooses to use EIP-1559 and burn transaction fees (perhaps for reasons other than game-theoretic ones). We therefore suggest to mitigate the current incentives for bribes using the above proposal.

## Product Considerations
<!--All FIPs must contain a section that discusses the product implications/considerations relative to the proposed change. Include information that might be important for product discussion. A discussion on how the proposed change will enable better storage-related goods and services to be developed on Filecoin. FIP submissions missing the "Product Considerations" section will be rejected. An FIP cannot proceed to status "Final" without a Product Considerations discussion deemed sufficient by the reviewers.-->
Beside mitigating the incentives for bribes, we see two other potential benefits from a product perspective.
- The new averaging mechanism would reduce spikes and extreme oscillations of the base fee.
- The AIAD would adapt faster to significant changes in persistent demand (not a momentary peak).

The above should lead to a better user experience. For example, with this proposal, it would be less likely for an SP to be surprised by an outrageous base fee exactly when it wants to post its proofs.

## Implementation
<!--The implementations must be completed before any core FIP is given status "Final", but it need not be completed before the FIP is accepted. While there is merit to the approach of reaching consensus on the specification and rationale before writing code, the principle of "rough consensus and running code" is still useful when it comes to resolving many discussions of API details.-->
None currently.

## Copyright
Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).

_Originally posted by @guy-goren in https://github.com/filecoin-project/FIPs/discussions/686_