What's coming in the Berlin Hardfork?
Looking at all the details of the upcoming fork
The Berlin Hardfork is scheduled for April 14th after block 12,224,00. Later to be followed by the London Hardfork in July which will include EIP-1559.
So let's take a look at the new changes and what you need to know as a developer.
EIP-2929: Increased gas costs for state access
EIP-2929 will increase the gas costs for state access. Those have been historically underpriced and lead to a DOS attack in 2016 where a lot of transactions were spammed that access the state of a large number of accounts. In response the gas costs were increased.
However, an analysis from beginning of 2020 came to the conclusion that they are still too low. The core problem here is that IO on a computer is very expensive to do. That's why we have things like RAM after all. The researchers found that their specifically crafted transaction would take 20 to 80 seconds for a node to process. In comparison a regular transaction takes only a few milliseconds.
This EIP only increases the gas cost when accessing a storage slot or account for the first time. The new cost for a first time storage slot access will be 2100, while access first first time access for accounts will be 2600. After that for any reads for multiple times, the cost will be reduced to 100, since the data will be in memory.
Further also storing via SSTORE becomes slightly more expensive by an additional 2100 for writing to a slot the first time. To quote the EIP: 'The change is needed to avoid the possibility of a DoS attack that “pokes” a randomly chosen zero storage slot, changing it from 0 to 0 at a cost of 800 gas but requiring a de-facto storage load.'
Lastly, SELFDESTRUCT
is also going to cost 2100 more if the recipient of the refund has not already been loaded. But keep in mind, the opcode may not exist for much longer anyways, see EIP-3298.
As previously discussed, the Openzeppelin v4 contracts already adapted to this new EIP and reduced state access where possible.
EIP-2930: Prepayments for state access
With EIP-2930 we can mitigate contract breakages from the higher gas costs. This would only affect a very small subset of deployed contracts, if you rely on a fixed amount of gas being used somewhere or are close to the block gas limit. In such a case, transactions sent to your contract can send the EIP-2930 transaction first to bring back the gas costs.
EIP-2718: Typed Transaction Envelope
With EIP-2718 we will finally get an easy way to add more transaction types. Previously any new transaction type additions were really hacky and you couldn't tell directly from looking at a transaction if this was a special type of transaction. This made it hard not only for the node software developers, but also for new transaction type standards.
Besides the new EIP-2930 prepayment transaction type, there are several other candidates for added transaction types, such as allowing someone other than msg.sender to pay the gas or multi-sig transactions. After Berlin hardfork, those standards will be easier to implement.
Not included: EIP-2315 - Simple Subroutines for the EVM
On short notice, this EIP was actually removed from the upgrade. For a full discussion of this issue see here.
We may get something similar to this EIP in the future, so let's go over it quickly anyways. EIP-2315 adds simple subroutine support with three new opcodes:
BEGINSUB
JUMPSUB
RETURNSUB
Improving not only the gas costs slightly, but also helping bytecode static analysis tools.
EIP-2565: Cheaper onchain crypto
Now I'm not talking about cheaper crypto prices. With EIP-2565 we get reduced gas costs for one opcode that is in the form of a precompile: ModExp
. This precompile was introduced in EIP-198 and will perform a modular exponentiation which is useful for many cryptographic schemes such as SNARKs and VDFs.
But apparently the gas costs were chosen way too high for this precompile. A new method to compute the gas costs is added via EIP-2565 to better reflect the computational complexity. As a result, onchain crypto will become cheaper.
Lastly, what do you need to consider as dev?
For you as a developer I would guess most importantly the increase state access costs will affect you. If you are one of the few for which this completely breaks your contract, consider using the prepayment transactions discussed above. Otherwise for new contracts limit state access as much as you can.
Solidity Developer