Ethers.js: EIP-1559 Transaction Support

[ricmoo]

This has already been started locally, but I'm throwing together a quick issue to help track it (in commits) and to include relevant literature.

For those unfamiliar with EIP-1559, it uses a new fee structure to provide more stable gas fees across block, improving the user experience and attempting to minimize economic inefficiencies which lead to many users overpaying for their transactions.

It's goal is not necessarily to make transactions cheaper, but will make it easier to know how much to pay for a reasonable inclusion duration, and cause fees paid for transactions to more accurately reflect fair-market value.

More links: (this will be updated as I find more resources):

• EIP-1559 Cheatsheet
• Calaveras Block Explorer
• Calaveras JSON-RPC Endpoint
• Calaveras Faucet

Old Links:

• Baikal Testnet info
• Baikal Faucet

[FrederikBolding]

We are definitely eagerly awaiting this at MyCrypto to start playing around with it. Let me know if you need any help at all!

[marcgarreau]

hi from web3.py! following along too as we'll be starting down this path either this or next week. 👀

[ricmoo]

So, one problems that has come up is the default choices for maxFeeGas and maxPriorityFeePerGas.

It makes total sense that maxFeeGas >= maxPriorityFeePerGas, however the current advice is:

• maxFeePerGas = 2 * getBlock(-1).baseFee
• maxPriorityFeePerGas = 1 gwei

This has the following consequence. On Calaveras, right now the baseFee is 7 wei (not gwei). This means:

• maxFeePerGas = 14 wei
• maxPriorityFeePerGas = 1 gwei

And 14 wei < 1 gwei. So, what should be do?

Option 1:

• maxFeePerGas = min(2 * getBlock(-1).baseFee, 1 gwei)
• maxPriorityFeePerGas = 1 gwei

Option 2:

• maxFeePerGas = 2 * getBlock(-1).baseFee + 1 gwei
• maxPriorityFeePerGas = 1 gwei

Options 3

• ???

Both options will likely massively overpay (100's of millions times more to the miner than the burn) on a network with a low base fee.

Ideas?

[zemse]

What if we have default maxPriorityFeePerGas as 0?

In pre-EIP1559 system, there has been an option to set a minimum gas price for eth clients, and mostly it has been 1 gwei across testnets and mainnet (before last year's increase). I assume this is to prevent spam txs when network has less traffic. That's why if ethers.js had 0 default gas price tx (which is less than the min gas price by nodes), then it'd not be possible to demo ethers.js without using a gasPrice override.

However, post-EIP1559, this minimim gas price is in the form of baseFee (unless miners also want to utilize their ability to set a minimum priority fee). As long as the baseFee is set sufficient, i.e 2x of latest block's base fee, having a priority fee as 0 should still work (at least on less crowded testnets). For mainnet use, almost everyone sets a manual gasPrice (from some gas price oracle).

Edit: since we are setting maxFeePerGas as 2x base fee, and if that is 14 wei. If baseFee turned out to be 8 wei, then even if maxPriorityFee is set as 1 gwei, the priority fee cannot be more than 14 - 8 = 6 wei ?

[ricmoo]

If you set a maxPriorityFee of 0 though, you will 100% never get mined though. Miners will not mine a transaction that does not cover their costs for uncle risk. We need priority fees to prevent mining empty blocks.

Micah suggested we go with Option 2, and the discussions on discord have convinced me. :)

I've made those changes to the eip-1559 branch, if anyone wants to check it out. :)

One nice thing of EIP-1559 is we will no longer require any gas oracle. And it looks like any oracle data we might need to make better decisions in the future may be included in the Geth JSON-RPC, such as a histogram of priority fees paid. Then we can add some nice logic to ethers to "just work" for anyone doing normal things and overriding will only be necessary for developers doing more advanced things. :)

[ricmoo]

In this case, what we would end up with is:

• maxFeePerGas = 14 wei
• maxPriorityFeePerGas = 1000000000 wei

I was originally concerned, because I was thinking of priority fee like a tip, and I would never tip $500 million on a $3 coffee. But Micah pointed out that we shouldn't think of it like a tip. The priorityFee is the costs the miner must absorb (operation cost + needed profit) to justify their continued work and the baseFee is more of a mechanism to figure out "who wants it more" and weed out spam/low-value transactions. So it is ok to have a large discrepancy between these values, since they represent different things entirely. :)

[marceljay]

The priorityFee is the costs the miner must absorb (operation cost + needed profit) to justify their continued work

I don't get why this is assumed, because there is a block reward. I thought the tip is really just to be mined quickly when there is congestion to give the miners an way to prioritize. And the mechanism is supposed to make ether more valuable.

[ricmoo]

@marceljay Check out the EIP in the OP. After the London Hardfork (which will include EIP-1559) the subsidy reward is destroyed, not given to the miner like it is today. That is the new incentive model which is why “tips” (or bribes) are necessary.

The economic model is a lot different and quite unrelated to the gasPrice auctions today, so there is a lot of additional modelling and economic ballet to study up on. :)

Sorry, I don’t know what I was thinking when I wrote that. I need to revise my answer as that last one is entirely incorrect. :s

The block subsidy reward only rewards the miner for the resources used to mine a block, but there must be an incentive to include each transaction, otherwise it would be easier to just mine empty blocks, and no reason to bother including anything else.

Each transaction also requires some additional time to process, and increases the processing time of each other node to verify a successful block before that block gets accepted and propagated. As a result, including additional transactions has an extra cost; each transaction increases the odds that a block will get uncled (or worse orphaned), so the priority fee is required to offset the cost of that risk.

[ricmoo]

@marceljay Sorry. My previous answer was wrong. I updated it and am tagging you to make sure you see it. Sorry about that.

[ricmoo]

This has been published in 5.4.0. Try it out and let me know how it works for you! :)

[jmrossy]

@ricmoo Do these updates for EIP-1559 break any compat with old txs (i.e. can 5.4.0+ be used on Mainnet still)?
And related, is the intention to keep backwards compat after EIP-1559 is live on Mainnet?

[ricmoo]

@jmrossy Everything is 100% backwards compatible. It has to be this way to continue supporting other networks (e.g. matic, xDai, etc).

The new provider.getFeeData can be used to detect if a network supports EIP-1559. If a transaction does not have an explicit type, ethers will use this to detect the best option to use on a given network, transparently to the developer. :)