The next Ethereum update will contain one of the most anticipated updates by the community: the possibility of withdrawing the ETH locked in the Beacon Chain.
During their weekly meeting, the Ethereum Foundation developers have reached a consensus on 8 proposals for improving Ethereum (EIP), which will be implemented in the next major update, called Shanghai.
These proposals should be included in the next hard fork by Ethereum which should take place sometime in 2023, possibly during the second quarter of the year.
Shanghai is a highly anticipated update for the Ethereum community since will implement the possibility of withdrawing ETH locked in the Beacon Chain. This means that users who locked their tokens to participate in validation will be able to recover their funds as well as staking rewards.
Until the launch of the hard fork, developers will be able to test applications and how EIPs work implemented in Shandong, the testnet of Ethereum, which was launched in October.
Do you know what Ethereum improvement proposals are?
Find out all about these proposals from developers to improve the operation and performance of Ethereum and how they are implemented on the network.
The 8 proposals for the future of Ethereum
EIP-3540: EVM Object Format
EIP-3540 introduces a format of extensible and versioned container for the EVM with a one-time validation at deployment time.
This version allows code and data to be separated, making it easier to implement changes and improve the Ethereum Virtual Machine in the future.
EIP- 3651: Warm Coinbase
This proposal It aims to “warm up” the Coinbase address at the beginning of each transaction execution, according to the actual cost of reading the account.
In this way it is intended reduce the prices of these types of transactions, since these addresses are initially cold in the access list entered in the EIP-2929, which causes a certain imbalance in the gas cost.
EIP-3670: EOF contracts with validation code
EIP-3670 introduces the code validation at the time of contract creation for EOF format contracts. It will also reject contracts that contain truncated PUSH data or undefined instructions. This change will not affect legacy bytecode, that is, EOF raw code.
Current contracts do not require validation of correctness, so EVM implementations can decide how to handle bytecode with undefined instructions. This EIP aims to bring the validity of the code to consensus, to make it easier to manage and reason about the bytecode. At the same time, the paths for EVM to decide which instruction is valid in each execution are reduced.
EIP-3855: PUSH0 Instructions
A PUSH0 (0x5f) instruction is introduced that pushes the constant value 0 onto the stack.
This EIP is introduced for reduce the gas cost of all those instructions that seek to stack or push a zero value. At this time, due to the type of encoding, a high gas cost is generated, since it performs two operations, which causes the use of complex operations, the value of which may depend on the context and cause errors.
EIP-3860: Limits and counters code
EIP-3860 seeks to extend EIP-170 by introducing a maximum size limit for the initcode.
At the same time, a 2 gas charge per 32 byte chunk of initcode to represent the cost of the jump analysis. Finally, the size limit gives rise to a new property: the EVM size, code offset, and jump offset are set to a 16-bit value.
EIP-4895: The Beacon Chain allows withdrawals in the EVM
This is one of the most anticipated features. With it, a system-level operation is introduced to support the validator withdrawals that “push” from the Beacon Chain to the EVM.
These operations create unconditional balance increases for specific recipients. Basically, it allows withdrawals from Beacon Chain validators enter the EVM.
EIP-4758: Disable SELFDESTRUCT
This EIP renames the SELFDESTRUCT code to SENDALL, while replacing its functionality. In this way, SENDALL will serve to send all Ether in an account to the calling user.
SELFDESTRUCT requires large account state changes as it removes all code and storage. With the implementation of the Verkle trees this will not be possible as each account will be stored in many different keys that will not be connected to the root account.
Other proposals approved to be implemented in Shanghai
In addition to the proposals described above, the next hard fork will also implement the EIP-4844, focused on taking advantage of the full potential of sharding.
To do this, it will implement the first system of proto-danksharding and is expected to increase network performance, while reducing transaction rates and improving scalability.
[hubspot type=cta portal=20298209 id=38fb28e1-1dc1-40e3-9098-5704ca7fcb07]
