Overview of Ethereum Shanghai Upgrade (Mainnet launch scheduled for 4/12/2023)
What else beyond consensus layer withdrawal and what is it?
Many media have already covered the most notable upcoming change to Ethereum network’s Shanghai Upgrade - consensus layer withdrawal.
This blog gives an overview of all of the technical changes to the Ethereum Virtual Machine with the upcoming Shanghai upgrade.
EVM Optimizations
The goal of this Ethereum improvement proposal is to always load the COINBASE addresses due to growing demand in using such function to handle conditional payment on a successful transaction.
Previously, users had to pay for transactions regardless of success or failure in block/transaction executions (See this example).
This helps with code execution efficiency as the change will always load COINBASE addresses in response to increased gas efficiency in cold loading Ethereum state. (See here for increased cost)
The goal of this change is to define specifically for pushing the constant value 0 onto the EVM stack simplifying the execution of Ethereum smart contracts.
To give more background, EVM is a runtime environment for smart contracts with various system/network states. Smart contract code (ie. solidity code) is compiled (translated) to bytecode and stored at an address be it on a local network, testnet, or mainnet. (See Assembly language to draw parallel)
EVM’s state changes (updating its memory) are handled via executing the stack of opcodes.
As stated in the EIP, roughly 11.5% of all the PUSH instructions is pushing the value of 0 onto the stack.
Furthermore, many are trying to achieve the same effect with other opcode calls increasing risks of misusing such instructions and complexity in executing the smart contract.
EVM Transparency and Itemizing
The goal of this proposal is to introduce gas metering on jumpdest-analysis on the initcode prior to execution.
What is jump and jumpdest?
In the stack execution (refer above for opcodes), JUMP instruction alters the program counter (instruction pointer pointing to where in the instruction set - list of opcodes - to execute next), to execute via another stack of opcodes.
This is used when creating a function where there is a new scope to start executing from.
Thus, jumpdest refers to the address which program counter will need to start executing from. It is also a requirement in EVM to maintain a jump table - restricting indirect branching JUMPs to only defined JUMPDEST opcode. (See here)
This is also always needed to start EVM execution. (See EIP-3690)
Why do we need jumpdest-analysis?
Jumpdest-analysis is performed on the init code (constructs the contract and retursn the runtime code to be stored on chain. Source here) prior to execution as it constructs the stack of opcodes to be executed.
Analyzing jumpdests in a smart contract helps to understand the control flow of the program that can be altered and potentially exploited thus enhancing security.
See code here.
Why do we need metering?
The work currently is not metered and not bounded how much this can cost.
This proposal brings more transparency on code execution and creates an extendable framework to improve the cost system transparency and customization for other parts of EVM operations.
EIP-6049 proposes to deprecate using SELFDESTRUCT opcode by warning about a potential future change.
The goal of this is to alert to engineers about avoid using such opcode as it has certain undesirable outcome. (See here)
Consensus layer withdrawal to execution layer
This is a proposal that defines the operation that allows users to withdraw staked ether from consensus layer to the execution layer (transacted via smart contract thus improving efficiency by defining such path.
This is an extension to the beacon chain implementation that launched in 2020.
More specifically, this implementation implements the push based mechanism rather a pull-based such that withdrawals are queued for process in the EVM stack (see above regarding opcodes) once it is dequeued from the consensus layer.
(See differences between push and pull architectures here and here.)
The end result of this is that specified recipient(s) will see an increase in account balance.
On the accounting level, this will work similar to COINBASE reward (see previous) where it is an unconditional balance increase. (See here for staking contract code)
Check out below for more resources
Further Reading
Upcoming events
[3/22/2023] Developer Day at GDC. RSVP here.
[3/23/2023] Web3 gaming apps powered by Gnoland. RSVP here.
Iterative Ventures is a web3 investment fund & community with the aim of supporting digital asset adoption. We have a focus on infrastructure and technology owing to our technical background.
Please reach out (team@iterativeventure.com) if you would like to learn more or collaborate, including being featured in our community events/ media outlet.
Follow us on Twitter and join our Telegram community to get the latest update!