Everything you need to know about Ethereum’s Shanghai Upgrade
& EOS launching EVM supporting

Two of the most important events in the crypto space in 2023 took place this month.

Ethereum Shanghai Upgrade

On April 12th Ethereum's Shanghai upgrade took place; also known as Ethereum Shapella upgrade, the name came from Shanghai (Sh: the first two letters in Shapella) which is the name of the city hosting the Devcon 2 conference and Capella (apella: the last part of Shapella) is the brightest star in the northen constellation of Auriga.

"The merge represents the joining of the existing execution layer of Ethereum (the mainnet we used prior to the merge) with its new proof-of-stake consensus layer the Beacon Chain" - source: Ethereum.org

to simply put it, prior to the merge the network has two layers running in parallel; the execution layer (PoW) and the consensus layer (PoS) the Shanghai upgrade took place on the execution layer and Capella took place on the consensus layer. The merge represents the transition process where the two networks come together, thus PoS consensus algorithm will replace PoW for good without losing any of the Ethereum State that includes transactions, DApps, contracts, and balances.

Shanghai upgrade introduced new EIPs:

1- EIP-6049:

• This EIP deprecates the SELFDESTRUCT opcode and warns against its use. A breaking change to this functionality is likely to come in the future.

2- EIP-3855:

• This EIP introduces a new opcode of PUSH0 is 0x5f in the Ethereum EVM as part of the Shanghai hard fork of the Shapella Upgrade which did not exists previously.
• This instruction aims to help reduce gas costs and storage costs for contracts that need to push constant 0 onto the stack.
• An analysis on Mainnet shows that ~11.5% of all the PUSH* instructions executed push a value of zero.
• It has no immediate data, pops no items from the stack, and places a single item with the value 0 onto the stack. The cost of this instruction is 2 gas.
• It aims to reduce contract code size, lower the risk of contract misuse of other instructions, and reduce the need to use DUP instructions for duplicating zeroes.
• One potential issue with the introduction of PUSH0 is that already deployed contracts using this opcode could change their behavior after this EIP. However, the authors are not aware of any impact on security, and jumpdest-analysis is unaffected as PUSH0 has no immediate data bytes.

3- EIP-3651:

• This EIP starts the COINBASE address warm, it's one of the protocols aiming to reduce gas cots, and here are these EIPs:

• EIP-2929 => Introduced state access list to the transaction gas computation where the more states the transaction access, the higher gas fees. => Defined some warm accesses from the start as they're already accessed at the start of the transaction.
• EIP-2930 => It was proposed in the Ethereum's Berlin upgrade. => The proposal allowed developers to specify transactions access lists making it easier to process transactions when their storage reads are predictable.
• EIP-1559 => It was proposed in the Ethereum's London upgrade. => Ethereum historically priced transaction fees using a simple auction mechanism, where users send transactions with bids ("gasprices") and miners choose transactions with the highest bids, and transactions that get included pay the bid that they specify. This leads to several large sources of inefficiency. => The proposal introduced three main concepts under COINBASE conditional payments: 1- base fee : amount which is adjusted up and down by the protocol based on how congested the network is. When the network exceeds the target per-block gas usage, the base fee increases slightly and when capacity is below the target, it decreases slightly. The base fee per gas is burned. 2- priority fee: the maximum fee per gas per transaction to be given to miners to incentivize them to include their transaction. 3- max fee: the maximum fee per gas per transaction to be paid in total which is equal base fee plus priority fee.
• EIP-3651 => It was proposed in the Ethereum's Shanghai upgrade. => The proposal made COINBASE address warm at the start of transaction execution. => Accessing COINBASE prior to this proposal was overpriced because the address was initially cold under the access list framework introduced in EIP-2929. => At the start of transaction execution, accessed_addresses shall be initialized to also include the address returned by COINBASE (0x41). => The addresses currently initialized warm are the addresses that should already be loaded at the start of transaction validation. The ORIGIN address is always loaded to check its balance against the gas limit and the gas price. The tx.to address is always loaded to begin execution. The COINBASE address should also be always be loaded because it receives the block reward and the transaction fees.

3- EIP-3860:

• This EIP extends EIP-170 where maximum value for initcode was set to 24576 bytes to the new maximum value of 49152. If length of transaction data (initcode) in a create transaction exceeds MAX_INITCODE_SIZE, transaction is invalid.
• Introduced an extra charge of 2 gas for every 32 bytes chunk of initcode. If the transaction doesn't have enough gas to cover INIT_WORD_COST, transaction is invalid.
• For the CREATE and CREATE2 instructions charge an extra gas cost equaling to initcode_cost(initcode). This cost is deducted before the calculation of the resulting contract address and the execution of initcode.
• If length of initcode to CREATE or CREATE2 instructions exceeds MAX_INITCODE_SIZE, instruction execution exceptionally aborts.

5- EIP-4895:

• Support validator withdrawals from the beacon chain to the EVM via a new "system-level" operation type.
• To maintain Beacon Chain integrity, allow it to function as intended, and carry out transactions and smart contracts, it needed validators just like any other PoS-based blockchains where miners do not exist.
• Therefore, those who wanted to partake in the future of the so-called Ethereum 2.0 were able to stake 32 ETH to secure the Beacon chain. The ETH was staked in the Beacon Depositor contract. Validators would then earn rewards for securing the network during this development stage on their ETH.
• This EIP provides a way for validator withdrawals made on the beacon chain to enter into the EVM. The architecture is "push"-based, rather than "pull"-based, where withdrawals are required to be processed in the execution layer as soon as they are dequeued from the consensus layer.
• Withdrawals are represented as a new type of object in the execution payload - an "operation" - that separates the withdrawals feature from user-level transactions. This approach is more involved than the prior approach introducing a new transaction type but it cleanly separates this "system-level" operation from regular transactions.
• There are 2 types of withdrawals: Full withdrawals => allow validators to exit their stake completely, taking their entire balance of ETH, including the original 32 ETH, as well as any rewards they may have accrued. Partial withdrawals => only allow validators to access the excess (balances over the 32 ETH) needed to run a validator node.

EOS Blockchain launches Beta version of its Ethereum EVM mainnet.

On April 14th The EOS Network Foundation (ENF) has announced the beta launch of the EOS EVM mainnet, which aims to improve interoperability between two blockchain ecosystems, Ethereum and EOS.

EOS deployed its EVM as a smart contract written in solidity which will bridge Ethereum and EOS blockchains to allow interoperability between the 2 ecosystems, where Ethereum will benefit from the one-second block interval speed of EOS and its low fees and EOS will benefit from Ethereum's popularity and resources.

This will allows us, Solidity developers to deploy mass-scale DApps with lower gas fees and faster speed on EOS which expands our horizon in addition to the beta version of Polygon's zkEVM, the zero-knowledge rollup scaling solution that was released on March 27th.

"Combining the performance of EOS with the familiarity of Ethereum, Solidity developers are in for a treat," Rose tweeted last week. "At 800+ swaps per second, $EOS EVM will be BY FAR the fastest EVM, benchmarked 3x faster than Solana + BNB and 25x faster than Avax."