Ethereum co-founder Vitalik Buterin believes that the blockchain's long-term resilience and scalability hinge on making it simple, like Bitcoin

Ethereum co-founder Vitalik Buterin envisions an instance of Ethereum's consensus layer code and a portion of the execution layer code. Together, they span less than 1,000 lines of code, aiming to make it simple enough for a high-school student to comprehend. In contrast, the code for a single large Unix program can exceed 1 million lines.

Simplicity is often underestimated in programming. It renders programs more accessible, reduces the cost of creating new infrastructure and maintaining existing infrastructure, and minimizes the risk of bugs.

Recently, Ethereum has been making good progress in becoming more robust, thanks to the integration of proof-of-stake (PoS) and Zero-Knowledge Succinct Non-Interactive Argument of Knowledge (zk-SNARK). However, we haven't yet sufficiently prioritized simplicity of design, which has led to additional costs.

Historically, Ethereum has often neglected this aspect (sometimes due to my own decisions), contributing to excessive development expenditure, various security risks, and a relative lack of interoperability with external R&D culture, often in pursuit of benefits that have proven illusory.

I believe that over the next 3-5 years, we can and should make significant progress in this direction. We can aim to make Ethereum 5 years from now have consensus-critical code that is close to as simple as Bitcoin, which is something that many people have set as a goal for a long time.

One of the best things about Bitcoin is how beautifully simple the protocol is. A smart high-school student can read the protocol and understand the main concepts and architecture of the protocol.

We want to be able to say the same about Ethereum. I think we can get close.

3-slot finality will allow us to eliminate concepts like slots, epochs, and sync committees from the common view. A basic implementation of 3-slot finality can be done in about 200 lines of code, which is simpler than the 1,008 lines of code for the main Harvest aggregator contract.

We will also have fewer active validators at a time, which will make it safer to use simpler implementations of the fork choice rule.

We will use STARK-based aggregation protocols for efficient validator slashing aggregation, and anyone can be an aggregator. The complexity of the aggregation cryptography itself is significant, but it is at least highly encapsulated complexity, which has much lower systemic risk toward the protocol.

This will likely enable a simpler and more robust P2P architecture. We can also rethink and simplify several facets, such as validator entry and exit, inactivity leak, and more, both by reducing line-of-code (LoC) count and by creating more legible guarantees.

The consensus layer is relatively disconnected from Ethereum Virtual Machine (EVM) executions, providing relatively wide latitude for us to make improvements.

We can also make the execution layer simpler. Last month, I proposed replacing EVM contract language with RISC-V to boost efficiency by up to 100x.

The adoption of RISC-V will also increase simplicity, as the RISC-V spec is absurdly simple compared to the EVM. Of course, we need to ensure that we preserve backwards compatibility for existing applications.

The first thing that is important to understand is: there isn’t one single way to delineate what is the “Ethereum codebase” (even within a single client).

The goal is to minimize the green area, by moving code to the yellow area, which indicates code that is very valuable for understanding and interpreting the chain today, or for optimal block building, but is not part of consensus.

We can think of this process as how Apple achieves long-term backwards compatibility through translation layers.

Importantly, the orange and yellow areas are encapsulated complexity; anyone looking to understand the protocol can skip them, implementations of Ethereum are free to skip them, and any bugs in those areas do not pose consensus risks.

This means that code complexity in the orange and yellow areas has far fewer downsides compared to code complexity in the green area.

To reduce the green area, we can take the following steps:

Phase 1: New precompiles will be written in RISC-V.

Phase 2: Developers will have the option to write contracts in RISC-V.

Phase 3: All precompiles will be replaced with RISC-V implementations through a hard fork.

Phase 4: We will implement an EVM interpreter in RISC-V and push it onchain as a smart contract.

This way, Ethereum consensus will natively understand only RISC-V.

We can also share one standard across different parts of the stack.

For instance, we can use a single erasure code for data availability sampling, P2P broadcasting, and distributed history storage. This will minimize the total lines of code, increase efficiency, and ensure verifiability.

Similarly, we can have one shared serialization format across the three