6. Splurge — Everything else

Splurge includes all the upgrades that are important for Ethereum but don’t fit neatly into the previous categories

1. EVM- Object Format (EOF)

While Ethereum has had several upgrades in its history, the Ethereum Virtual Machine (EVM) has not changed much. EOF will be the first major upgrade of the EVM since Genesis.

EOF is a collection of 11 EIPs (Ethereum Improvement Proposals), many of which are interdependent, that aim to improve EVM efficiency and developer friendliness. It is scheduled to be included in the next Ethereum hard fork — Pectra (Prague+Electra).

Some of the improvements include:

Code and Data Separation: EVM contracts today have no structure or format. The code and data have no fixed location and can be anywhere in the contract. When executing, EVM must go through the contract byte-by-byte and do its best to implement it. This makes contracts expensive to execute and difficult to analyze. => EOF separates Code and Data.

Code Validation at Deploy time: Currently, a smart contract does not have to be validated when it is deployed. However, it must be validated every time it is executed. This has two disadvantages: (a) Issues like incomplete instructions or undefined opcodes are not identified until runtime, and (b) Execution is expensive as it must be validated every time it is executed. => With EOF, smart contracts have to be validated only once, and since this is done before runtime, issues can be detected earlier.

Removal of Dynamic Jumps: A contract's execution path can be static (pre-determined) or dynamic (based on conditions). => EOF will remove dynamic jumps as they’re difficult to analyze and make code upgrades more difficult.

Address EVM Painpoints: EOF broadly addresses long-standing issues of EVM, such as streamlining compiler development, providing new compiler optimizations, and improving the developer experience.

Pre-EOF contracts will continue to exist, and no mandatory upgrade is required. However, there will be an incentive to upgrade, as EOF contracts will benefit from smaller sizes and lower gas costs.

Post EOF, further upgrades like EVM-MAX (EVM Modular Arithmetic Extensions) and SIMD (Singular Instruction/ Multiple Data) become easier to introduce.

EOF has been criticized for introducing too much complexity to EVM. Unless the aim is to palm off this complexity to well-funded L2s, I believe that upgrading EVM should be a priority.

2. Account Abstraction

Today, there is only 1 way for a transaction to be verified — ECDSA signatures.

Multi-Party Computation (MPC): An alternative is to use MPC. This splits a key into multiple pieces that are stored in separate devices and generate the key cryptographically without actually revealing the pieces. This allows for the social recovery of private keys but doesn’t achieve other account abstraction goals.

EIP-7702: Then comes EIP-3074, which evolved to EIP-7702 and is likely to be implemented in the Pectra hard fork. This helps achieve more account abstraction goals, such as having multiple Ops in a single transaction, executing bundled transactions, enabling payment of gas fees in ERC20 tokens, and enabling someone other than the transaction initiator to pay gas fees.

Account Abstraction: But even EIP-7702 does not achieve all the account abstraction goals, which include switching to quantum-resistant cryptography, rotating out old keys that represent a security risk, and allowing privacy pools to work without relayers. These can only be solved by allowing transaction verification using EVM code.

Allowing transactions to be initiated by smart contracts is easy. What is difficult is allowing transactions to be initiated by smart contracts in a manner that is decentralized and protects against DOS attacks. Imagine there are 1000 transactions that depend on a value “S.” If an attacker can flip that value to something else, all transactions will fail and, in the process, clog the network.

**ERC-4337: **ERC-4337 is considered the best solution for protecting against DOS attacks. This divides transaction processing into 2 parts. First, all transactions are validated together, and then all validated transactions are executed together. I’ve described it in detail here.

Note that 4337 is an ERC (Ethereum Request for Comment) and not an EIP (Ethereum Improvement Protocol). EIPs make changes to the core Ethereum protocol while ERCs do not, and hence, they are easier to implement. When ERC-4337 went live, Ethereum developers were focused on “scaling” and didn’t have time for this. Today, there is a realization that it would be better if 4337 was enshrined within Ethereum.

3. EIP-1559 Improvements

EIP-1559 was introduced in 2021 to bring predictability to gas fees. Before EIP-1559, users had to guess how much gas fees they needed to pay to incentivize miners to include their transactions in their blocks. This was especially problematic during busy periods when users often ended up paying far more than was required.

EIP-1559 divided gas into 2 components — (a) base fee and (b) tip. The base fee is decided by the protocol and rises or falls at a predictable rate depending on how full the previous blocks were. A tip is an added incentive you pay at your discretion if you want the miner (now validator) to include your transaction in the earliest block possible.

While EIP-1559 has achieved its target of bringing more predictability to gas fees and improving block inclusion time, it would benefit from some improvements. One is bringing Multidimensional Gas.

Multidimensional gas

Currently, all resources are priced in terms of “gas.” Gas is the computational effort needed to process a transaction or block. The target and max size of each block are 15 million gas and 30 million gas, respectively.

This mechanism, while simple, leads to inefficient block creation as it fails to factor in the fact that not all gas usage is the same. Gas is consumed by (a) data, (b) computation, ( c) storage reads and writes, (d) proof generation, etc, and each of these has safety limits. Therefore, additional constraints should be applied to blocks.

There’s already a limit on blobs. Blocks have a max and target of 6 and 3 blobs, respectively. A blob can have a max size of 125KB. Limits are being considered for calldata; storage reads/writes, and state size growth. In this post, Vitalik provides the thinking behind a blob limit of 6 and a potential storage access limit of 2,000 reads.

Bringing in multidimensional gas, however, will add complexity to the protocol. Users having to factor in the gas-usage breakdown can be abstracted by wallets. The bigger problem is that smart contracts call on other smart contracts and set gas limits that would have to factor in all sub-limits. The solution being considered is to allow multidimensional gas only inside EOF, as EOF does not allow smart contracts to set limits on calls to other smart contracts.

4. Verifiable Delay Function (VDF)

Ethereum doesn’t yet have an ideal Verifiable Delay Function. It currently uses RANDAO-based randomness, which is okay for proposer selection but not for on-chain apps that need randomness.

The way VDFs work is that an input is provided at time T. After executing some operations on that input that require a minimum guaranteed computation time, an output is found. They’re difficult to compute and easy to verify. They help with randomness because the output of the VDF can be used as input to decide who will be the next block proposer or who will win an on-chain lottery.

The challenge is that once a function is selected as the ideal VDF, what if someone finds a way to calculate the output faster than others through, say, parallelization or improved hardware? They could use this to their advantage.

5. Obfuscation of One-Shot Signatures

If privacy is not a concern, blockchains have successfully functioned as trustless third parties. However, achieving trustlessness without sacrificing privacy remains a problem.

The first major step towards a solution was ZK-SNARKS. This makes it possible for you to prove that your claim is true without revealing any data except for the claim and in a manner that can be easily verified. The problem with ZK-SNARKS, though, is that you need to know the data to create a proof.

An improvement came in the form of Fully Homomorphic Encryption (FHE). This allows you to create proofs without knowing the data. The problem with this is that it needs someone to hold a decryption key. The decryption key can be held by a single entity (in which case you need to trust that entity) or distributed among a group (in which case you need to trust that a threshold number within that group is honest).

A yet more advanced solution is **Indistinguishability Obfuscation**. Here, a program is transformed into a version that is functionally the same but hard to understand or reverse engineer. It allows you to take a hidden input and run it through what is essentially an encrypted program. Neither the input nor the program is revealed. One weakness, though, is that the obfuscated program can be copied.

With Quantum One-Shot Signatures, even this problem is solved, and true trustlessness is achieved. However, this will become a reality in the future when quantum computers are readily available.

Let’s examine how each of these helps in the use case of “voting”

• We start by putting votes on a public blockchain. This ensures that no one can be stopped from voting (censorship resistance) and that the voting outcome is correct (verifiability). However, how every participant has voted is clearly visible (no privacy)
• If we add ZK-SNARKs, the votes become anonymous while ensuring that only authorized entities vote. However, the risk of coercion remains, i.e., a person can be forced to vote a certain way.
• Now, if we add Fully Homomorphic Encryption with an honest central server, a person can prove that they voted a certain way, but they cannot prove that they didn’t cast another vote, canceling the previous vote. Thus, there is no point in coercing them to vote in a certain way.
• If we want to avoid trusting a single central server, we can distribute trust among “n” entities and enforce a threshold decryption to decrypt it.
• Next, we obfuscate the tallying program that can publish the outcome if authorized by, say, a blockchain consensus mechanism. You’d need 51% of validators to collude to break the trust.
• Finally, if we add quantum one-time signatures, coercion resistance is perfect.

The full series available in below links:

Future of Ethereum

1. Merge — Improving on Proof-of-Stake

2. Surge — How will Ethereum scale?

3. Scourge — Stop centralization

4. Verge — Verification should be so easy; your smartwatch should be able to do it

5. Purge — Reduce history, state, and features

6. Splurge — Everything else