Add EIP: Add time-weighted averaging to the base fee

EIPS/eip-7378.md

@@ -0,0 +1,85 @@
+---
+eip: 7378
+title: Add time-weighted averaging to the base fee
+description: Using geometric weights to average past block sizes into consideration
+author: Guy Goren (@guy-goren) <guy.nahsholim@gmail.com>
+discussions-to: https://ethereum-magicians.org/t/add-time-weighted-averaging-to-the-base-fee-mechanism/15142
+status: Draft
+type: Standards Track
+category: Core
+created: 2023-07-22
+---
+
+## Abstract
+
+This EIP proposes a new formula to update the base fee, derived from [EIP-1559](./eip-1559.md). The existing base fee update formula,
+
+$$b[i+1]\triangleq  b[i] \cdot \left( 1+\frac{1}{8} \cdot \frac{s[i]-s^* }{s^* }\right)$$
+
+only considers the last block size $s[i]$. This mechanism incentivizes proposers to collude with users to manipulate the base fee.
+
+We propose that even previous block sizes be considered by replacing the last block size with an exponential moving average. In particular, we suggest the following base fee update formula:
+
+$$b[i+1]\triangleq  b[i] \cdot \left( 1+\frac{1}{8} \cdot \frac{s_{\textit{avg}}[i]-s^* }{s^* }\right)$$
+
+where $s_{\textit{avg}}[i]$ is defined by:
+
+$$s_{\textit{avg}}[i] \triangleq \alpha\sum_{k=1}^{\infty} (1-\alpha)^k\cdot s[i-k+1]$$ 
+
+and $\alpha\in(0,1)$ is a smoothing factor.
+
+## Motivation
+
+To reduce bribe motivation when the demand for blockspace is high (see Incentive Considerations section) and to reduce oscillations, thus, having a more stable fee setting mechanism.
+
+Proposers use a mechanism described in EIP-1559 to determine which messages to include in a block. This mechanism includes a "base fee": a portion of the transaction fee that is burned. The base fee varies according to the fill rate of blocks. A target block size is defined. If a block exceeds the target size, the base fee increases, and if it is smaller, the base fee lowers.
+
+Research on the subject have revealed issues with this transaction fee mechanism. It has been shown to be [unstable in cases](../assets/eip-7378/LMRSP.pdf). Moreover, it has been shown that the dynamic nature of the base fee, which is influenced by the fill rate of blocks, opens the door for [manipulation by miners (proposers) and users](../assets/eip-7378/AGHH.pdf). The desired behavior of the system under a stable high demand, is for it to reach an equalibrium where the base fee -- $b$ -- is the significant part of the gas fee, and the tip is relatively small -- denoted $\varepsilon$ (for reference, Ethereum's base fee often has $\frac{b}{\varepsilon}\approx 20$). According to [Roughgarden](../assets/eip-7378/TR1559.pdf) this is a rational equalibrium under the assumption that proposers do not think ahead. However, we expect a proposer to optimize its behavior by also considering its future payoffs. In essence, since neither the proposer nor the user are getting the burnt fee, by colluding they can both tap into the burnt fee for a win-win situation for them both.
+
+A [theoretical work](../assets/eip-7378/AGHH.pdf) describes how both proposers and users can initiate such an attack. For example, we can imagine that users who wish to pay lower costs will coordinate the attack. Roughly, a user (or group of users) that has transactions with a total $g$ amount of gas bribes the proposer of the current block (no matter the proposer's power) to propose an empty block instead. The cost of such a bribe is only $\varepsilon \times {s^* }$ -- the tip times the target block size. Consequently, the base fee reduces in the next block. If we accept that EIP-1559 reaches its goals, e.g., users would typicaly use a simple and honest bidding strategy of reporting their maximal willingness to pay plus adding a small tip ($\varepsilon$), then in the honest users' steady state, gas proposals leave the proposers with an $\varepsilon$ tip. Given that other users are na\"ive (or slow to react), our bribing user will include its transactions with any tip larger than $\varepsilon$ -- making the attack profitable whenever $g \frac{b^* }{8} >s^* \varepsilon$.
+
+
+## Specification
+
+$s[i]$ is replaced by $s_{\textit{avg}}[i]$, where:
+
+$$s_{\textit{avg}}[i] \triangleq \alpha\sum_{k=1}^{\infty} (1-\alpha)^k\cdot s[i-k+1]$$ 
+
+which simplifies to the recursive form
+
+$$s_{\textit{avg}}[i] = \alpha\cdot s[i] + (1-\alpha)\cdot s_{\textit{avg}}[i-1]$$
+
+where $\alpha\in(0, 1)$ is the smoothing factor. A higher smoothing factor means that the average responds more quickly to changes in block size (e.g., if $\alpha = 1$ the proposed formula degenerates to the existing rule).
+
+## Rationale
+
+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, the Ethereum network choice was to use EIP-1559 for the TFM (one stated reason was to try and simplify the fee estimation for users, and reduce the advantage of sophisticated users). 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 severity are in direct relation to the demand for block space, and currently only mildly impact the Ethereum network. If demand to use Ethereum increases, however, these problems are expected to exacerbate. We may want to prepare for this beforehand.
+
+The change is based on [this work](../assets/eip-7378/AGHH.pdf) that described a rational strategy in which bribes are profitabe. 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 future fluctuations in the base fee.
+Moreover, the theoretical analysis does not consider the income from classic MEV strategies. (Actually, the described strategy may be seen as another form of MEV.) The fact that classic MEV (sandwich, front running, etc.) are not included in the analysis, means that the proposed solutions to classic MEV (obscuring transactions etc.) will also not help against the described strategy. The problem that we tackle in this EIP is at the core of the base fee mechanism, with no further assumptions (such as MEV or predictability of randomness).
+
+Remark: An additional alternative strategy that is not fully discussed [here](../assets/eip-7378/AGHH.pdf) but one may consider is to reduce the 'max change denominator' (the learning rate) from 1/8 to something smaller. However, this is problematic since it significantly affects the responsiveness of the base fee, making it slow to respond to actual persistent changes. The reason for using geometric series weights is precisely to achieve the favorable tradeoff of still responding quickly while mitigating incentive misalignments.
+
+### Incentive Considerations
+
+The proposal is designed to improve the incentive compatability of the TFM. A [game theoretic analysys](../assets/eip-7378/AGHH.pdf) shows that the current TFM, which is based on EIP-1559, encourages bribes. 
+
+One of the main goals of EIP-1559 was to simplify the bidding for users. It was articulated [theoreticaly by Roughgarden](../assets/eip-7378/TR1559.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 considerd less good. However, one may argue that a TFM that encourages bribes is worse than a TFM that encourages not revealing one's full preferences.
+
+Although a first price auction is a safe bet regarding TFMs, the Ethereum network chose 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.
+
+## Backwards Compatibility
+
+This change requires a hard fork since the base fee is enforced (for blocks to be considered valid).
+
+## Test Cases
+
+TBD
+
+## Security Considerations
+
+Needs discussion.
+
+## Copyright
+
+Copyright and related rights waived via [CC0](../LICENSE.md).