With the completion of the Merge, the crypto community now turns its focus to the Shanghai Upgrade. What can we expect from it?
The countdown is officially over, and the Merge is complete. Ethereum has moved from a Proof-of-Work to a Proof-of-Stake consensus without a hitch, and the network moves towards a sustainable future with increased scalability on the roadmap.
While the Merge may be a significant milestone on the Ethereum roadmap, the upcoming upgrade — the Shanghai Upgrade — is another highly anticipated event thanks to its promise of implementing withdrawals for staked Ethereum that were deposited pre-Merge.
The Shanghai Upgrade is the next enhancement to the Ethereum network that will introduce a series of major improvements and other minor upgrades to the chain. Ethereum developer Tim Beiko previously iterated on his blog that the upgrade will introduce three critical Ethereum Improvement Proposals (EIPs) which are EIP-3540, EIP- 3074, and EIP-3670.
The first proposal looks to separate code and data with the creation of an Ethereum Virtual Machine (EVM) Object Format or EOF, the second aims to implement two EVM instructions to delegate account control to a smart contract, and the third will enable code validation for EOF contracts.
Other core details of the Shanghai Upgrade also aim to address the withdrawal of staked Ethereum on the Beacon chain, reducing Layer-2 blockchain transaction fees, and introduce ‘Shard Blob Transactions’ which lays the groundwork for full sharding function in the future.
But the list of confirmed proposals is still to be determined. While the Shanghai Upgrade was briefly touched on in the latest Ethereum Core Devs Meeting on September 15, the actual discussion for the next phase will take place after the Devcon Bogotá conference happening in Colombia next month.
What Ethereum proposals are slated for review at the moment? We run through the list below.
One of the important proposals highlighted by Tim Beiko, EIP-3540 calls for the separation of code and data which code validation on the network benefits while allowing changes to be introduced easily in the future.
At the moment, code validators such as those in Layer-2 scaling solutions like Polygon follows a tedious process to process transactions. They either require modifications prior to deploying a contract, implement a fragile method, or utilise a costly and restrictive jump analysis method.
The proposed separation would lead to easier use for coding smart contracts while lowering transaction fees, also known as gas fees.
Termed a companion EIP to the earlier proposal by Tim, EIP-3670 aims to introduce code validation for EOF smart contracts. Smart contracts in the network currently do not require strict validation for correctness, and there is no streamlined process to handle undefined instructions.
The proposal aims to streamline code validity so that it becomes easier to implement reasoning in bytecode, which is the EVM machine language. To create a clear start and stop duration for the smart contract, the EOF contract must have a valid initcode and a clear terminating instruction for the contract to be created. The proposal depends on the notation set by EIP-3540, hence the term companion EIP.
EIP-4895 is perhaps the key focus of the Shanghai Upgrade for investors who hold staked Ethereum. The proposal aims to introduce a system operational support to support the withdrawals and allow the asset to be withdrawn from the Beacon Chain.
Going into the fine details of the process, the withdrawn tokens are represented as a new object in the block, also known as an ‘operation’. Since withdrawal originate from the system instead of an end-user, the process is isolated from standard transactions and carried out separately.
The execution for withdrawals is also different with no gas fees being charged for un-staking the asset. That is due to the limitation placed on the maximum number of withdrawal transactions at any given time; This keeps operational cost low and leads to negligible gas fees.
One of the smaller upgrade mentioned by Tim, EIP-3860 aims to limit the size of the initcode notation and introduces gas fee metering as well. For context, initcode initiates the process of creating a smart contract via bytecode.
Currently, gas fee charges for initiating and executing smart contracts are not streamlined. Initiating the initcode Can cost either 4 or 16 gas depending on the number of bytes, and the cost for deploying code is 200 gas per byte with 24,576 bytes being the maximum size of a smart contract. A quick reminder on file sizes — a byte is made of 8 bits; a kilobyte is 210 or 1,024 bytes; and a megabyte is 220 or 1,048,576 bytes.
No gas fee is applied to a CREATE2 notation, which is a deterministic type of contract. Another way of seeing CREATE2 is the developing saying “I’ll deploy this contract at a particular address in the future.”
To streamline the charges in a fair manner, the maximum size of the smart contract will be increased to 49,152 bytes, and 2 gas will be charged for every 32-byte used. This applies to both initcode and CREATE2 notice to create a fairer gas fee charge, and a transaction will be canceled if it goes over the maximum limit.
This proposal improvement aims to add new code instructions to push the value of zero onto the stack. Many smart contract instructions utilise the number zero as an input, which is encoded as PUSH1 0.
The instruction execution costs 3 gas, and incurs another 200 gas in deployment cost. The overall cost is not ideal, which leads to developers trying various other instructions to achieve the same result. This inevitably leads to larger smart contracts with the potential to malfunction if the instructions are changed in the future.
To remedy this, EIP-3855 aims to introduce the instruction PUSH0 into the code. This places one item with the value 0 onto the stack, and will only cost 2 gas in fees without incurring further deployment cost. The benefit is it reduces the contract code size, plus removes the need to duplicate zeroes to be used as input.
A proposal that focuses on Coinbase addresses, EIP-3651 aims to execute transactions from these address as ‘Warm’ executions. The Ethereum network has seen an increasing number of Coinbase transactions. One of the reasons could be attributed to the Coinbase Pay function, which allows users to buy or transfer cryptocurrencies directly from non-custodial wallets.
Since Coinbase addresses are labeled as ‘Cold’, it costs the network more in gas fees to access them. Developers have noticed that most blocks have at least one transactions from a Coinbase address, if not more. For context, an Ethereum block is produced every 12 to 14 seconds which shows the volume of transactions coming from Coinbase addresses.
By labeling the addresses as ‘Warm’, network validators can receive the block reward and transaction fees when validating the blocks. The proposal will have the added benefit of allowing users to avoid paying for transactions that would bounce too.
Ethereum Improvement Proposals that were mentioned in Tim Beiko’s blog earlier but are noticeably absent are EIP-3074, which aims to two EVM instructions to delegate account control to a smart implement contract.
Another missing proposal from the list, EIP-4488, would have aimed to reduce transaction fees on L2s by lower the cost of storing data on L1. This would have been achieved by decreasing transaction calldata gas cost, while adding a limit of how much transaction calldata can be in a block.
EIP-4844, which would have introduced shard blob transactions, is removed from the list of ongoing confirmed proposals as well. The proposal would have introduced shard blob parameters and type aliases to the code, allowing blob transactions that would mimic the same format they would be when sharding is fully implemented. This was intended to provide temporary scaling relief without imposing extra development burdens.
