EIP-1559 transactions are typed transactions (see EIP-2718), where the type for EIP-1559 transactions is specified as 0x02
. The payload of the EIP-1559 transactions consists of (as JSON):
{
"gas": "0x5208", // = gasLimit
"maxFeePerGas": "0xb2d05e00",
"maxPriorityFeePerGas": "0xb2d05e00",
"input": "0x", // = data
"nonce": "0xa",
"to": "0xc6d5a3c98ec9073b54fa0969957bd582e8d874bf",
"value": "0x0",
"accessList": [],
"chainId": "0x5"
}
Here is an example of the above EIP-1559 transaction on Etherscan (on Goerli): https://goerli.etherscan.io//tx/0xeb403182d4e2f2705d012e864ac5316c54ceddfc0ee583c730c918040520a75a
The raw transaction receipt of this transaction looks like this:
{
"blockHash": "0xee4df7e9d55b56162346fb779c074fe897bc6bb737051ab776a83a2b6f15962d",
"blockNumber": "0x4fef3c",
"contractAddress": null,
"cumulativeGasUsed": "0xa410",
"effectiveGasPrice": "0xb2d05e00",
"from": "0xc6d5a3c98ec9073b54fa0969957bd582e8d874bf",
"gasUsed": "0x5208",
"logs": [],
"logsBloom": "0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000",
"status": "0x1",
"to": "0xc6d5a3c98ec9073b54fa0969957bd582e8d874bf",
"transactionHash": "0xeb403182d4e2f2705d012e864ac5316c54ceddfc0ee583c730c918040520a75a",
"transactionIndex": "0x1",
"type": "0x2"
}
Note that the type is not used as transaction payload itself, but rather specified as the EIP-2718 transaction type (where a transaction consists of TransactionType || TransactionPayload
).
The maxFeePerGas
is the total fee you are willing to pay per unit of gas. maxPriorityFeePerGas
(which is sent to the miner) is the total priority fee you are willing to pay, which should be lower than or equal to the maxFeePerGas
. How much you end up paying is gas × (baseFee + maxPriorityFeePerGas)
, assuming maxFeePerGas
is higher than the current base fee. The difference between the maxFeePerGas
and the actual used gas price is "refunded".
Legacy transactions will still work, but the gasPrice
of legacy transactions will be used as both the maxFeePerGas
and maxPriorityFeePerGas
, so you'll never end up getting a refund. The miner will always take the difference between the base fee and the max fee. To get the full benefit of EIP-1559 it's recommended to set both fields.
For more details on how the max fees should be estimated or how EIP-1559 can be implemented in general, I recommend you check out the EIP-1559 Cheatsheet for Implementers.
Let's quickly understand how the fee is changed in EIP-1159.
- Base Fee: Base fee is determined by the network itself.
- Max Priority Fee: Optional. Determined by the user and paid directly to the miner.
- Max Fee Per Gas: This is the absolute maximum fee you want to pay per unit of gas.
In the EIP-1159 transaction; we supply maxFeePerGas
and maxPriorityFeePerGas
. The base fee is automatically calculated by the network.
Now the base fee can increase/decrease but we have already supplied the max fee we want to pay in maxFeePerGas
. So if baseFee
increases in the next block, the priority fee can be adjusted to make sure the total fee never crosses the max fee.
Base Fee + Priority Fee <= Max Fee
Now about calculating the fee;
we need to get the base fee from the blockchain node and we can then decide how much max fee we want to make. Ideally, if you want your tx to be valid even after 6 blocks (assuming the base Fee increases to a maximum per block); you can use given formulae to calculate the max fee.
Max Fee = (2 * base fee) + Priority fee
So in terms of how do we get each field:
baseFee = await (web3.eth.getBlock("pending")).baseFeePerGas
priorityFee = choose yourself
MaxFee = (2 * baseFee) + priorityFee
Best Answer
Good question!
A hard fork doesn't necessarily mean the functionality wouldn't be backwards compatible. It means that users of the blockchain need to upgrade their clients, and that clients with the old version are no longer compatible with the blockchain. I would word it like this: client compatibility and function compatibility are different things.
Yes, you can still use the legacy transaction model, but it will not benefit from the newest changes. Here's some more info: https://eips.ethereum.org/EIPS/eip-1559#backwards-compatibility . You just can't use the legacy clients (they won't get synchronized).
Granted, it's a bit tricky to try to figure out what does it exactly mean that the EIP is backwards compatible. All the places just say "yes it's compatible, it just won't benefit from the new system". So I'm not 100% clear on that.