There is a perfect and very clear explanation of gas fee calculation at ethereum.org, both before and after the London upgrade. However, there is some ambiguity in the explanation of the maxFeePerGas parameter, which is optional in a transaction. In this text, we aim to clarify it.
Let’s cite the explanation from Ethereum.org:
Let's say Jordan has to pay Taylor 1 ETH.
In the transaction, the gas limit is 21,000 units, and the base fee is 10 gwei.
Jordan includes a tip of 2 gwei.
The total fee would now be: units of gas used * (base fee + priority fee),
where the base fee is a value set by the protocol, and the
priority fee is a value set by the user as a tip to the validator.
i.e., 21,000 * (10 + 2) = 252,000 gwei or 0.000252 ETH.
When Jordan sends the money, 1.000252 ETH will be deducted from Jordan's account.
Taylor will be credited 1.0000 ETH. The validator receives the tip of 0.000042 ETH.
A base fee of 0.00021 ETH is burned.
Additionally, Jordan can also set a max fee (maxFeePerGas) for the transaction.
The difference between the max fee and the actual fee is refunded to Jordan,
i.e., refund = max fee - (base fee + priority fee). Jordan can set a maximum amount
to pay for the transaction to execute and not worry about overpaying "beyond" the
base fee when the transaction is executed.
So, why would one set the max fee if the total fee is known beforehand? The answer is that the total fee is not known for sure, but only expected. When the transaction is broadcast to the network, it should be received by the validators and confirmed. This takes some time. During this period, when the transaction is yet unconfirmed, a sudden change in the base fee, which is controlled by the Ethereum network, can make the transaction fee greater than expected. In the example, if the base fee jumps from 10 to 20, the total fee rises to 21,000 * (20 + 2) = 462 kgwei from the previous 252 kgwei. The max fee setting to 300 kgwei would limit the fee paid to 300 kgwei instead of 462 kgwei.