Expectations for backwards-incompatible changes / removal of features that may come soon

The time between now and the merge, and possibly a little bit after the merge, is going to be a time of significant change for the Ethereum protocol. These changes are needed for many reasons: proof of stake and scalability, others to enable stateless validation, and others to simplify the protocol and make it easier to maintain it in the long term, all setting the stage for a more sustainable long-term Ethereum protocol. However, some of these changes are backwards-incompatible, in that they may break existing applications or render them uneconomical.

In all cases, these incompatibilities affect only a small portion of use cases, and there are alternative ways to get the same functionality, but nevertheless it's important to talk about these proposals early, so that developers have as much of a heads up as possible, and so that we have as much time as possible to refine the proposals to minimize disruption.

After the merge and the other important changes that are already in the roadmap today are complete, I continue to think that it would be valuable for the Ethereum protocol to "ossify", changing much less going forward so as to maximize developers' feeling of stability and ability to rely on protocol features. However, such an ossification is best done after we take into account our learnings from the past 6 years and make this one last push to make some major improvements to Ethereum.

This is my attempt at a partial listing of some changes that may happen.

See also: this doc, though the actual changes proposed there only cover the EVM, and this post is broader.

History storage changes

• After the Ethereum application state is moved over to the beacon chain as part of the merge, we may want to discard the ethereum PoW chain, and no longer support any transaction or history queries going back into the PoW chain. This greatly simplifies clients, as they can simply forget all the pre-merge protocol rules and thus have a smaller and leaner codebase going forward, but it does mean that dapps that rely on looking back into history need to find some other way to do so.
• Even outside of the context of the merge, we likely want to move toward a model where "the network" is only expected to be responsible for the most recent 1 year of history (including txs/blocks/receipts). This prevents clients from incurring ever-growing storage burdens, but it does once again mean that dapps that require old history will need an alternative way to get it.

Statelessness / state expiry

See my other post on this topic.

State expiry is definitely likely to be the one change in this list that requires the most significant changes for contracts; contracts that do not change probably will not break (as the most recent state expiry schemes ensure that if you can find a witness, you can continue using existing contracts as is for as long as you want), but developers will likely need to build new versions of contracts to remain gas-efficient.

EVM changes

• EIP 2929 (going into the upcoming Berlin hard fork), changing how SLOAD and calls/account accesses are priced. The first time an account or storage slot is accessed is now about 3x more expensive, but subsequent accesses are around 5-10x cheaper. On average, this only increases gas costs paid by users by ~0.3%, but it significantly improves the chain's DoS resistance and bounds on witness size.
• Gas repricing for code witness size: when we add code Merklization, to finish the job of bounding witness size we will need to charge some cost per chunk of code accessed in a transaction (eg. 400 gas per 32 byte chunk accessed). In general, this would somewhat increase the gas cost of "simpler" transactions (eg. an ERC20 approval accessed about 16 chunks so about 6.4k gas would be added) but it would only negligibly affect more complex transactions that loop over the same code many times. Gas limits can be adjusted upwards so that on average scalability remains the same as it was before, but even still, some applications may need to be rewritten to remain economical.
• Removal or neutering of SELFDESTRUCT: see this whole document for the rationale.
• Removal of refunds (proposed for the London hard fork), or limiting how refunds work, with the main goals of reducing block gas usage variance and freeing up blockchain space and storage being used by gastoken contracts.
• Removal of the 2300 gas stipend: a simplification to the protocol, removing a hard-coded value and hence making future gas cost changes more feasible
• Replacing some precompiles with EVM code implementations: this could be done mainly to simplify the protocol and the client code complexity, but it would inevitably come with gas cost changes.

Miscellaneous

• Ethereum is switching from RLP + hexary Patricia trees to SSZ and possibly Verkle trees. This means that contracts that verify Merkle proofs into history will stop working at some point and will need to be rewritten. To allow developers to make Merkle proofs going forward, one possible route is to make an explicit "history/state proof verification precompile", so that whenever the state structure changes the precompile can change too, but of course this has not yet been implemented.
• Block hashes will no longer be a good source of randomness after the merge.
• The DIFFICULTY opcode will be useless after the merge (duh)
• In the long run, quantum computers will break ECDSA and BLS, and so everything that uses ECDSA or BLS will have to switch, and even ethereum 2.0 itself will have to move from BLS to a post-quantum aggregable signature scheme. Fortunately, there has been a lot of work done recently by Starkware and others on making such schemes more efficient, so we are very confident that we will survive the transition; but contract developers should necessarily be aware that this will happen.

There are likely items that I have missed, but this covers at least some of the important things that are worth watching out for. I highly encourage application developers and others to participate in this process and do so early, so that the protocol changes that end up happening can be done in a way that is as minimally disruptive as possible.