# Article draft: Current Ethereum ###### tags: `blockchain-research` [toc] ## The background I was inspired to write this article by two people, [CC](https://twitter.com/ChihChengLiang) and [Vitalik](https://twitter.com/VitalikButerin/status/1599166783541628928?s=20&t=p8z_c_itePQNMdi90sGNOQ). They agreed that the best way to learn Ethereum is to watch **all core dev meetings** and read the relevant meeting notes, hackmd docs, issues & PRs, and EIPs until you are clear on Ethereum's current roadmap, what are the concerns and worries of core devs, what is the role of each upgrade/EIP, etc. Besides that, I was inspired by the community. Ethereum has an excellent open source culture, you can see all the meeting videos on [EF YouTube](https://www.youtube.com/@EthereumFoundation/search?query=meeting), and the agenda for future discussions in [ethereum/pm](https://github.com/ethereum/pm) (more, [Tim](https://tim.mirror.xyz/) and [Kim's](https://www.galaxy.com/research/insights/ethereum-all-core-developers-call-151/) notes). The ethereum developers are doing their best to make the community understand the current upgrades and improvements to ethereum. So I think writing articles like this is valuable to the community! ## The main things After Ethereum successfully merged on September 15, 2022, Ethereum shifted its attention to subsequent improvements, namely [Shanghai Upgrade](https://github.com/ethereum/execution-specs/blob/master/network-upgrades/mainnet-upgrades/shanghai.md) (Execution Layer) and [Capella Upgrade](https://github.com/ethereum/consensus-specs/blob/dev/specs/capella/beacon-chain.md#introduction) (Consensus Layer). There are mainly a few things 👇 - Beacon Chain Withdrawals - EOF - EIP-4844 - Other EIPs They play different roles. Beacon Chain withdrawals is the **core** of Shanghai upgrade, and EOF will be included in Shanghai only if there is no delay to withdrawals. In addition, because EIP-4844 may cause withdrawal delay, [it was moved out of the Shanghai upgrade](https://github.com/ethereum/execution-specs/pull/663) (if the EOF delay is also moved out). But all of us know that EIP-4844 is a critical improvement to Ethereum, so we make it the **center** of the next upgrade ([Cancun upgrade](https://github.com/ethereum/execution-specs/blob/master/network-upgrades/mainnet-upgrades/cancun.md)). In case you are learning about Shanghai upgrade for the first time, I will explain the related terms and EIP separately. ### Beacon Chain Withdrawals Understanding "withdrawals" requires a basic understanding of the history and evolution of Beacon Chain. **No Beacon Chain** Before the Beacon Chain, Ethereum was a complete monolithic blockchain, its consensus engine (PoW) and execution engine (EVM) worked together without coupling and separation. ![](https://hackmd.io/_uploads/BkK4jy8zh.png) ###### <Center>Monolithic Chain</Center> **Phase 0** After that, Beacon Chain was [launched](https://beaconscan.com/slot/0) in [Phase 0](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/beacon-chain.md#introduction) (December 2020). Ethereum has changed from a monolithic chain to a combination of two parallel chains (i.e. Beacon Chain and Execution Chain). The only way of communication between them is the [deposit contract](https://github.com/ethereum/consensus-specs/blob/dev/solidity_deposit_contract/deposit_contract.sol#L65), deposit and lock your 32ETH to become a [validator](https://ethereum.org/en/staking/) (this role similar to a "miner" under PoW). ![](https://hackmd.io/_uploads/Bk3Boy8Gh.png) ###### <Center>Pre-merge</Center> **Altair** And soon, Beacon Chain ushered in [the first hard fork](https://blog.ethereum.org/2021/10/05/altair-announcement), which is the [Altair upgrade](https://github.com/ethereum/consensus-specs/blob/dev/specs/altair/beacon-chain.md#introduction). This upgrade makes some simple fixes. (the upgrades of the consensus-layer [is named by stars](https://github.com/ethereum/eth2.0-pm/issues/215)) **Bellatrix** The second hard fork upgrade is called [Bellatrix](https://github.com/ethereum/consensus-specs/tree/dev/specs/bellatrix), also known as "[the merge](https://ethereum.org/en/upgrades/merge/)". We merged the Beacon Chain into the Execution Chain. At this time, Ethereum has changed from two parallel chains to one chain but has two layers, namely the consensus layer and the execution layer. These two layers communicate through the [Engine API](https://docs.teku.consensys.net/en/latest/Concepts/Merge/#execution-and-consensus-clients). At a total difficulty of `58750000000000000000000`, Bellatrix upgrade (CL) and [Paris upgrade](https://github.com/ethereum/execution-specs/blob/master/network-upgrades/mainnet-upgrades/paris.md) (EL) were launched at the same time. Through [EIP-3675](https://eips.ethereum.org/EIPS/eip-3675) and [EIP-4399](https://eips.ethereum.org/EIPS/eip-4399), we successfully replaced the consensus of Ethereum from PoW to PoS! ![](https://hackmd.io/_uploads/BJHPs1Lf2.png) ###### <Center>Post-merge</Center> **Capella** This is the third hard fork upgrade of the Beacon Chain (named after the [Capella star](https://en.wikipedia.org/wiki/Capella)!), and it will also start at the same time as the Shanghai upgrade (EL). Through [EIP-4895](https://eips.ethereum.org/EIPS/eip-4895), the withdrawals from Beacon Chain to EVM is achieved. This is also the current main work of the consensus layer and each client team. After the upgrade is completed, all validators can withdraw their ETH. The total deposits in Beacon Chain have exceeded [15,741,431 ETH](https://beaconcha.in/), and dynamic validators are important to the economic layer of Ethereum. ![](https://hackmd.io/_uploads/S1Mdj18M2.png) ###### <Center>Total deposits</Center> ### EOF As a super enthusiast of EVM, I believe many people have been looking forward to EOF for a long time. A few years ago, there were discussions and improvements related to "[Ethereum account versioning](https://ethereum-magicians.org/t/ethereum-account-versioning/3508)". Until now, EOF has become a reality and has been finalized to be included in the scope of Shanghai upgrade (in fact, EVM has not changed much since Genesis Block). Simply put, the current EVM has only one set of interpretation and validation rules to handle all existing contracts (we call them "**legacy contracts**"). And EOF (consisting of five EIPs) introduces a new smart contract format, which we call "**EOF contracts**". And the clients/EVM interpreter also has corresponding updates. So we now have two sets of EVM interpretation and validation rules, and they exist in parallel. EVM will be able to handle both legacy contracts and EOF contracts (in the longer future, we may replace all legacy contracts with EOF contracts). Why EOF, what benefits does it bring? 👇 - **EVM versioning**. This makes it easy to introduce or [deprecate](https://github.com/ethereum/pm/issues/250) features (but what is deprecated in EOF is still supported in legacy contracts), preventing the EVM from becoming more and more complicated and ugly. Adding features to the EVM is now more difficult than removing them, and EOF may change that. - **Add new control flow operations**, completely abandon dynamic jump and runtime JUMPDEST analysis, more cost-effective. (And making code transformations easier, etc.) - **Move what the EVM validates at runtime (e.g. stack `underflow`, `overflow`) to deployment time**. This makes the overhead of the EVM lower and makes the contract code more secure (potential bugs will not be deployed on Ethereum). - **Code and data are separated**. We will have an executable-but-opaque code section, and a readable-but-unexecutable data section In addition, EOF is mainly composed of five EIPs, and I will briefly introduce the role of each EIP. If you want to learn more about EOF, I suggest you go to the past discussions, such as "[EVM encapsulation format](https://notes.ethereum.org/@axic/evm-object-format)" and "[Everything about EVM](https://notes.ethereum.org/@ipsilon/evm-object-format-overview)", and these five EIPs (there is a [Unified specification](https://notes.ethereum.org/@ipsilon/eof1-unified-specification?utm_source=substack&utm_medium=email)). Very helpful! 👇 - **EIP-3540: EVM Object Format (EOF) v1** [This EIP](https://eips.ethereum.org/EIPS/eip-3540) introduces the EOF container and specifies the fields contained in all EOF contracts (you can check the complete fields [here](https://notes.ethereum.org/@ipsilon/eof1-unified-specification?utm_source=substack&utm_medium=email#Container)). In addition, it relies on [EIP-3541](https://eips.ethereum.org/EIPS/eip-3541), which guarantees that the deployment of EOF format contracts will be rejected before Shanghai upgrade. - **EIP-3670: EOF - Code Validation** [This EIP](https://eips.ethereum.org/EIPS/eip-3670) is based on [EIP-3540](https://eips.ethereum.org/EIPS/eip-3540) and adds more validation rules for EOF contracts. Wrong EOF code cannot be deployed, you can see all code validation rules [here](https://notes.ethereum.org/@ipsilon/eof1-unified-specification?utm_source=substack&utm_medium=email#Code-Validation). - **EIP-4200: EOF - Static relative jumps** [This EIP](https://eips.ethereum.org/EIPS/eip-4200) introduces new jump instructions - `RJUMP`, `RJUMPI` and `RJUMV`, which are used to point to relative locations of executed code. Through this EIP, we can initially remove JUMPDEST analysis (dynamic jump, `JUMP` and `JUMPI`). - **EIP-4750: EOF - Functions** [This EIP](https://eips.ethereum.org/EIPS/eip-4750) goes one step further, it introduces the concept of "EVM function" (which is an independent subroutine), and introduces `CALLF` and `RETF` to call & return EVM functions. Through [EIP-4750](https://eips.ethereum.org/EIPS/eip-4750) and [EIP-4200](https://eips.ethereum.org/EIPS/eip-4200), we can completely abandon JUMPDEST analysis (dynamic jump, `JUMP` and `JUMPI`). - **EIP-5450: EOF - Stack Validation** [This EIP](https://eips.ethereum.org/EIPS/eip-5450) adds more validation rules, and transfers stack `underflow/overflow`, `inefficient gas`, etc. from runtime checks to deployment-time checks. This can further reduce the overhead of the EVM (currently `underflow/overflow` is checked by the EVM interpreter when running the contract code). Personally, I think EOF is a significant improvement for EVM, so I hope to see it deployed in Shanghai upgrade (and without delaying withdrawals). For the EOF roadmap, we will keep both legacy contracts and EOF contracts at the beginning, and then we may transfer existing legacy contacts to EOF contracts (obviously not the highest priority). But this may have some impact on zkEVM. 👇 - Depends on **the number of EOF contracts**. If most of the contracts are legacy contracts, the existing zkEVM does not need to be modified too much to be compatible with EOF. - If all existing contracts turn to EOF contracts, we need to **add EOF-related constraints in all circuits** (such as the separation of data and code, which may change the existing bytecode circuit). - For opcodes, `JUMP` and `JUMPI` may be deprecated because EOF disables dynamic jumps. And according to [vitalik's Proposal](https://ethereum-magicians.org/t/eof-proposal-ban-code-introspection-of-eof-accounts/12113), `CODECOPY` and `CODESIZE` may also be abandoned in the future. Also, we need to **write constraints for new opcodes** (such as `RJUMP`, `RJUMI`, `RJUMV`, `CALLF`, `RETF`, etc.) But in general, zkEVM always needs to change with EVM (zkEVM serves EVM), and when zkEVM is used for Layer 1 ([type1](https://vitalik.ca/general/2022/08/04/zkevm.html)), every EVM upgrade will also take zkEVM into account, and simultaneous upgrades (EVM + zkEVM) are possible. So I don't think it's a big deal to keep zkEVM updated. For EOF. There are still many improvements in the future, such as considering banning EOF codes from being directly read by `CODECOPY`, `CODESIZE`, `EXTCODECOPY`, `EXTCODESIZE` and `EXTCODEHASH`, and achieve **automatic-mandatory conversion** of EVM versions (version `n` code can be automatically converted to version `n+1`). EVM code can even be converted to equivalents of other VM codes. > If we decide to change from the EVM to some other VM (eg. WASM, Cairo…) in the future, it would be possible to automatically transform EVM code into code of the new VM that has equivalent functionality. ### EIP-4844 [EIP-4844](https://eips.ethereum.org/EIPS/eip-4844) is completely designed for Rollups to further reduce the cost of data submission and verification (according to [L2fee](https://l2fees.info/), the transaction fee of L2s is already 4-20x cheaper than L1). Proto-danksharding comes from [proto.eth](https://twitter.com/protolambda/status/1495538286332624898?s=20&t=gw0ro2tsi0dgJb_VZhrPbA)'s simple implementation of [Fully-Danksharding](https://notes.ethereum.org/3t5cbN7cQnG6VxjgNMKymA) on ETH Denver. It is easier to implement than fully sharding, which is important for Ethereum scaling. The reason for this is proto danksharding doesn't actually "shard" the data, or require data availability sampling: it has each node download all the data, but discard it after ~2 weeks. Although EIP-4844 is simple enough, its implementation still widely involves the following aspects. 👇 - [EIP itself](https://ethereum-magicians.org/t/eip-4844-shard-blob-transactions/8430) (done) - [Consensus-spec](https://github.com/ethereum/consensus-specs/pull/2850) (WIP, roughly done) - [Engine-API spec](https://github.com/ethereum/execution-apis/blob/main/src/engine/experimental/blob-extension.md) (done) - [Client implementations](https://github.com/ethereum/pm/blob/master/Breakout-Room/4844-readiness-checklist.md#implementation) (WIP. Refer to [Geth](https://github.com/ethereum/go-ethereum/pull/26283) and [Prysm](https://github.com/prysmaticlabs/prysm/issues/11579)) - [KZG ceremony](https://github.com/ethereum/KZG-Ceremony) (done. You can join the ceremony [here](https://ceremony.ethereum.org/)) - [Tooling](https://github.com/ethereum/pm/blob/master/Breakout-Room/4844-readiness-checklist.md#tooling), [Devnets](https://notes.ethereum.org/@timbeiko/4844-devnet-3), etc. (WIP, roughly done) - [Testing](https://github.com/Inphi/eip4844-interop) (WIP) This is my prediction of the current work progress of EIP-4844 (please take it with caution), and I hope to see EIP-4844 deployed to the Ethereum mainnet before June. ![](https://hackmd.io/_uploads/rybtsk8zn.png) ###### <Center>EIP-4844</Center> Although the progress of EIP-4844 is very fast, there is still a lot of work to do (including client implementations and extensive testing). To prevent it from delaying withdrawals, [ACD#151](https://github.com/ethereum/pm/issues/675) decided to remove EIP-4844 from Shanghai upgrade ([Péter Szilágyi](https://twitter.com/peter_szilagyi) and [Dankrad Feist](https://twitter.com/dankrad) disagreed on this). EIP-4844 is the next critical improvement for Ethereum, and we all know about it. This is why the next upgrade (Cancun upgrade) after the Shanghai will be **centered on EIP-4844**. ### Other EIPs In addition to Withdrawals and EOF, Shanghai upgrade also deploys three independent EIPs, which are 👇 - **EIP-3651: Warm COINBASE** [This EIP](https://eips.ethereum.org/EIPS/eip-3651) complements [EIP-2929](https://eips.ethereum.org/EIPS/eip-2929) by adding a `COINBASE` address for the start of transaction execution. - **EIP-3855: PUSH0 instruction** [This EIP](https://eips.ethereum.org/EIPS/eip-3855) introduces a new instruction `PUSH0`, which is used to push the constant value `0` onto the stack. - **EIP-3860: Limit and meter initcode** [This EIP](https://eips.ethereum.org/EIPS/eip-3860) extends [EIP-170](https://eips.ethereum.org/EIPS/eip-170). It limits the maximum size of initcode to `49152` and adds `2` gas for each 32-byte chunk of initcode. ## The roadmap and timeline ### Timeline The Ethereum upgrade timeline determined in ACD#151 on December 8 is roughly like this👇 (*It should be reminded that this time may change dynamically*) - **January** Complete the client implementation and testing of EOF before January 5 (the next ACD meeting), perform shadow forks for Shanghai upgrade on January 12, and complete the EOF cross-client Interoperability before January 19 (the 153rd ACD meeting). - **February** More tests will be done in February to make sure EOF and withdrawals are stable enough. And deploy withdrawals on the public testnets (Sepolia, Goerli, etc.) - **March** Launch Shanghai Upgrade (Beacon Chain Withdrawals on the mainnet! 🎉) - **April** The focus shifts to the next Cancun upgrade (centered on EIP-4844), fully testing EIP-4844. Such as multiple mainnet shadow forks, and make EIP-4844 on the public testnets. - **May** Launch Cancun Upgrade (EIP-4844 on the mainet! 🎉) ![](https://hackmd.io/_uploads/Sy0Yj1UGh.png) ###### <Center>The timeline</Center> ### Shanghai Upgrade + Capella Upgrade This upgrade centers on Beacon Chain Withdrawals. To avoid any potential delay of withdrawals, EIP-4844 was removed from Shanghai (you can see the full Shanghai spec [here](https://github.com/ethereum/execution-specs/blob/master/network-upgrades/mainnet-upgrades/shanghai.md)). And EOF needs to follow a strict timeline, otherwise it will be removed. The two more important time points are **January 5, 2023** (ACD #152, EOF needs to complete client implementation and testing) and **January 19, 2023** (ACD #153, complete EOF cross-client interoperability). The Shanghai upgrade is expected to happen in **March** (consensus layer and execution layer are upgraded at the same time). If all goes well, we will see EOF and Withdrawals on mainnet soon! ### Next Cancun Upgrade Since EIP-4844 was removed from Shanghai, we made it the center of the next upgrade (you can see all the Cancun spec [here](https://github.com/ethereum/execution-specs/blob/master/network-upgrades/mainnet-upgrades/cancun.md)). It is expected that the implementation and testing of EIP-4844 will be completed in April 2023, and deployed on the public testnets. Then Cancun upgrade can be launched in May-June to deploy EIP-4844 to the mainnet! ## Conclusions Today is the last day of 2022, and we have seen many significant technological advances in this year. For example, the success of merge, the completion of EIP-4844 spec, the rise of rollups, the innovation of zkp, and the progress of zkevm. I am happy to witness this year. Also excited about these underlying improvements of Ethereum protocol. Next year, we'll have even more crucial upgrades. They are Shanghai + Capella (withdrawals and EOF), Cancun + Deneb (EIP-4844), and Prague + Electra (to be determined). Next year will continue to be a fantastic year, with a lot of work waiting to be done. We'll see more foundational ideas and research, so I think it's very appropriate to kick off 2023 with this article. Happy new year!
Last changed by  
 
Luozhu
517

Read more

Account Abstraction: challenges and solutions

Motivation This document is about a discussion between the Ethereum team and AA wallet teams that were initiated by Vitalik. The AA team highlighted several issues they were currently facing. I have collected the topics and content of our discussions for internal review and learning (especially for zkEVM rollup-related parts). Critical Issues Multichain implementation The design goal of multichain AA wallet is to achieve address consistency and state (e.g. signing key, settings) consistency across multichain. 1. Address consistency across multichain

5/6/2023
Article draft: What it's like to be a homeless

Gratitude to Chee, Kim, Chen Wen Kang, Jason, Haichen, Andy, Mason, Aiko, Chris, Anthony, Cathy, Vitalik, and every incredible person encountered on this journey! Over the past year, I've embarked on a journey across various countries for work-related reasons and to satisfy my innate curiosity. While some might refer to this lifestyle as that of a "digital nomad" or "world citizen," I prefer a more understated term - "homeless." This inspired the title of today's article, in which I will discuss my experiences living without a fixed abode. My travels took me to three continents and six countries, each exciting and enlightening adventure. I shared some of these journeys with friends, while others I undertook alone, constantly forging connections with locals. These unique experiences gave me fresh perspectives and allowed me to witness people and places I would never have encountered. These extraordinary moments broadened my horizons and revealed our world's boundless diversity and possibilities. I am eager to share these experiences in this article, which also marks the beginning of my next great adventure. Starting from Vietnam ETH Vietnam

4/15/2023
Outline: Ethereum's Consensus Protocol

What is Consensus Background The Byzantine Generals ProblemBackgroundBasic idea: abstract The background of consensus knowledge In a 1982 paper, Leslie Lamport What is it The army are divided into several generals Generals communicate only through messenger

4/11/2023
Article draft: Beacon Chain Withdrawal

Special thanks to Alex Stokes, Danny Ryan, and Vitalik Buterin for their invaluable assistance and insightful feedback during the review process.

4/7/2023
Read more from Luozhu
Published on HackMD