Vitalik on Ethereum's Possible Futures (VI): The Splurge

In Ethereum protocol design, about half of the content involves different types of EVM improvements, while the rest consists of various niche topics—this is what "The Splurge" is all about.

Original Title: 《Possible futures of the Ethereum protocol, part 6: The Splurge》

Author: Vitalik Buterin

Translation: zhouzhou, BlockBeats

The following is the original content (edited for easier reading and understanding):

Some things are hard to categorize under a single heading. In Ethereum protocol design, there are many "details" that are very important to Ethereum's success. In fact, about half of the content involves different types of EVM improvements, while the rest consists of various niche topics—this is what "The Splurge" is all about.

2023 Roadmap: The Splurge

The Splurge: Key Goals

• Make the EVM a high-performance and stable "final state"
• Introduce account abstraction into the protocol, allowing all users to enjoy more secure and convenient accounts
• Optimize transaction fee economics, improving scalability while reducing risk
• Explore advanced cryptography to significantly improve Ethereum in the long term

EVM Improvements

What problems does it solve?

The current EVM is difficult to statically analyze, making it hard to create efficient implementations, formally verify code, and further extend. In addition, the EVM is relatively inefficient and cannot implement many forms of advanced cryptography unless explicitly supported via precompiles.

What is it and how does it work?

The first step in the current EVM improvement roadmap is the EVM Object Format (EOF), which is planned for inclusion in the next hard fork. EOF is a series of EIPs that specify a new EVM code version with many unique features, most notably:

• Separation between code (executable but unreadable from the EVM) and data (readable but not executable)
• Prohibition of dynamic jumps, allowing only static jumps
• EVM code can no longer observe gas-related information
• Addition of a new explicit subroutine mechanism

Structure of EOF code

The Splurge: EVM Improvements (Continued)

Legacy contracts will continue to exist and can be created, although eventually legacy contracts may be phased out (or even forcibly converted to EOF code). New contracts will benefit from the efficiency improvements brought by EOF—first through slightly smaller bytecode thanks to the subroutine feature, and later through EOF-specific new features or reduced gas costs.

After the introduction of EOF, further upgrades become much easier. The most developed at present is the EVM Modular Arithmetic Extension (EVM-MAX). EVM-MAX creates a set of new operations specifically for modular arithmetic and places them in a new memory space inaccessible by other opcodes, making optimizations such as Montgomery multiplication possible.

A newer idea is to combine EVM-MAX with Single Instruction Multiple Data (SIMD) features. SIMD has been a concept in Ethereum for a long time, first proposed by Greg Colvin's EIP-616. SIMD can be used to accelerate many forms of cryptography, including hash functions, 32-bit STARKs, and lattice-based cryptography. The combination of EVM-MAX and SIMD makes these two performance-oriented extensions a natural pairing.

A rough design for a combined EIP would start with EIP-6690, then:

• Allow (i) any odd number or (ii) any power of 2 up to 2768 as the modulus
• For each EVM-MAX opcode (addition, subtraction, multiplication), add a version that no longer uses 3 immediates x, y, z, but instead uses 7 immediates: x_start, x_skip, y_start, y_skip, z_start, z_skip, count. In Python code, these opcodes would work like:

for i in range(count):

mem[z_start + z_skip * count] = op(

mem[x_start + x_skip * count],

mem[y_start + y_skip * count]

)

In actual implementation, this would be processed in parallel.

• Possibly add XOR, AND, OR, NOT, and SHIFT (including circular and non-circular), at least for power-of-2 moduli. Also add ISZERO (which pushes output to the EVM main stack), which would be powerful enough to implement elliptic curve cryptography, small field cryptography (such as Poseidon, Circle STARKs), traditional hash functions (such as SHA256, KECCAK, BLAKE), and lattice-based cryptography. Other EVM upgrades may also be implemented, but so far have received less attention.

Existing Research Links

• EOF: 
• EVM-MAX: 
• SIMD: 

Remaining Work and Trade-offs

Currently, EOF is planned for inclusion in the next hard fork. Although it is always possible to remove it at the last minute—features have been temporarily removed in previous hard forks—doing so would be very challenging. Removing EOF would mean that any future upgrades to the EVM would have to be done without EOF, which is possible but may be more difficult.

The main trade-off for the EVM is between L1 complexity and infrastructure complexity. EOF is a large amount of code that needs to be added to EVM implementations, and static code checks are relatively complex. However, in exchange, we can simplify high-level languages, simplify EVM implementations, and gain other benefits. It can be argued that a roadmap that prioritizes continuous improvement of Ethereum L1 should include and build on EOF.

An important task that needs to be done is to implement features similar to EVM-MAX plus SIMD and benchmark gas consumption for various cryptographic operations.

How does it interact with other parts of the roadmap?

L1 adjusting its EVM makes it easier for L2 to make corresponding adjustments as well. If the two do not synchronize, incompatibility may result, with negative consequences. In addition, EVM-MAX and SIMD can reduce the gas cost of many proving systems, making L2s more efficient. It also makes it easier to replace more precompiles with EVM code that can perform the same tasks, possibly without significantly affecting efficiency.

Account Abstraction

What problem does it solve?

Currently, transactions can only be validated in one way: ECDSA signatures. Originally, account abstraction aimed to go beyond this, allowing the account's validation logic to be arbitrary EVM code. This enables a range of applications:

• Switching to quantum-resistant cryptography
• Rotating old keys (widely considered a recommended security practice)
• Multi-signature wallets and social recovery wallets
• Using one key for low-value operations and another key (or set of keys) for high-value operations

Allowing privacy protocols to work without relayers, significantly reducing their complexity and eliminating a key central dependency

Since account abstraction was proposed in 2015, its goals have also expanded to include a large number of "convenience goals," such as allowing an account with no ETH but some ERC20 to pay gas with ERC20. The following is a summary chart of these goals:

MPC (Multi-Party Computation) is a technology that has existed for 40 years, used to split a key into multiple parts and store them on multiple devices, using cryptographic techniques to generate signatures without directly combining these key parts.

EIP-7702 is a proposal planned for introduction in the next hard fork. EIP-7702 is the result of growing recognition of the need to provide account abstraction convenience to benefit all users (including EOA users), aiming to improve the experience for all users in the short term and avoid splitting into two ecosystems.

This work began with EIP-3074 and eventually resulted in EIP-7702. EIP-7702 brings the "convenience features" of account abstraction to all users, including today's EOAs (externally owned accounts, i.e., accounts controlled by ECDSA signatures).

As can be seen from the chart, while some challenges (especially "convenience" challenges) can be solved with incremental technologies such as MPC or EIP-7702, the main security goals for which account abstraction proposals were originally made can only be achieved by going back and addressing the original issue: allowing smart contract code to control transaction validation. The reason this has not yet been achieved is that secure implementation is a challenge.

What is it and how does it work?

The core of account abstraction is simple: allow smart contracts to initiate transactions, not just EOAs. All the complexity comes from implementing this in a way that is friendly to maintaining a decentralized network and prevents denial-of-service attacks.

A typical key challenge is the multi-failure problem:

If the validation function of 1,000 accounts all depends on a single value S, and the current value of S makes all transactions in the mempool valid, then a single transaction flipping the value of S could invalidate all other transactions in the mempool. This allows an attacker to spam the mempool with junk transactions at very low cost, clogging network node resources.

After years of effort to expand functionality while limiting denial-of-service (DoS) risk, the solution to achieving "ideal account abstraction" was finally found: ERC-4337.

ERC-4337 works by splitting the processing of user operations into two stages: validation and execution. All validations are processed first, and all executions are processed afterward. In the mempool, a user operation is only accepted if its validation stage only involves its own account and does not read environment variables. This prevents multi-failure attacks. In addition, strict gas limits are enforced on the validation step.

ERC-4337 was designed as an additional protocol standard (ERC) because at the time, Ethereum client developers were focused on the Merge and had no extra bandwidth to handle other features. This is why ERC-4337 uses objects called user operations instead of regular transactions. However, we have recently realized the need to write at least part of this into the protocol.

There are two key reasons:

1. The inherent inefficiency of EntryPoint as a contract: each bundle has a fixed overhead of about 100,000 gas, plus several thousand gas per user operation.
2. The need to ensure Ethereum properties: such as the inclusion guarantees created by inclusion lists, which need to be transferred to account abstraction users.

In addition, ERC-4337 extends two features:

• Paymasters: the ability for one account to pay fees on behalf of another, which violates the rule that the validation stage can only access the sender's own account, so special handling is introduced to ensure the security of the paymaster mechanism.
• Aggregators: support for signature aggregation, such as BLS aggregation or SNARK-based aggregation. This is necessary for achieving maximum data efficiency on rollups.

Existing Research Links

• Talk on the history of account abstraction:
• ERC-4337:
• EIP-7702:
• BLSWallet code (using aggregation features):
• EIP-7562 (protocol-level account abstraction):
• EIP-7701 (EOF-based protocol-level account abstraction):

Remaining Work and Trade-offs

The main issue to be solved now is how to fully bring account abstraction into the protocol. The recently popular protocol-level account abstraction EIP is EIP-7701, which implements account abstraction on top of EOF. An account can have a separate code section for validation, and if the account sets this code section, it will be executed during the validation step of transactions from that account.

The charm of this approach is that it clearly shows two equivalent perspectives of native account abstraction:

1. Making EIP-4337 part of the protocol
2. A new EOA type where the signature algorithm is EVM code execution

If we start by setting strict limits on the complexity of code executable during validation—not allowing access to external state, and even setting gas limits so low at first that quantum resistance or privacy-preserving applications are not viable—then the security of this approach is very clear: it simply replaces ECDSA verification with EVM code execution that takes similar time.

However, over time, we need to relax these boundaries, because allowing privacy-preserving applications to work without relayers and quantum resistance are both very important. To do this, we need to find more flexible ways to address DoS risk, without requiring the validation step to be extremely minimal.

The main trade-off seems to be "quickly write a solution that satisfies fewer people" versus "wait longer, possibly get a more ideal solution." The ideal approach may be some kind of hybrid. One hybrid approach is to quickly write some use cases and leave more time to explore others. Another is to first deploy a more ambitious version of account abstraction on L2. However, the challenge here is that L2 teams need to be confident in the proposal's adoption to be willing to implement it, especially to ensure that L1 and/or other L2s can adopt compatible solutions in the future.

Another application we need to explicitly consider is key storage accounts, which store account-related state on L1 or a dedicated L2, but can be used on L1 and any compatible L2. Doing this effectively may require L2s to support opcodes such as L1SLOAD or REMOTESTATICCALL, but this also requires the account abstraction implementation on L2 to support these operations.

How does it interact with other parts of the roadmap?

Inclusion lists need to support account abstraction transactions. In practice, the requirements for inclusion lists and decentralized mempools are actually very similar, although inclusion lists are a bit more flexible. In addition, account abstraction implementations should coordinate as much as possible between L1 and L2. If in the future we expect most users to use key storage rollups, account abstraction design should be based on this.

EIP-1559 Improvements

What problem does it solve?

EIP-1559 was activated on Ethereum in 2021, significantly improving average block inclusion times.

Wait times

However, the current implementation of EIP-1559 is imperfect in several ways:

1. The formula is slightly flawed: it does not target 50% full blocks, but about 50-53%, depending on variance (related to what mathematicians call the "arithmetic-geometric mean inequality").
2. It does not adjust quickly enough in extreme cases.

The formula later used for blobs (EIP-4844) was specifically designed to solve the first problem and is also simpler overall. However, neither EIP-1559 itself nor EIP-4844 attempts to solve the second problem. As a result, the current state is a messy intermediate one, involving two different mechanisms, and there is a view that over time, both need improvement.

In addition, there are other weaknesses in Ethereum resource pricing unrelated to EIP-1559, but which can be addressed by adjusting EIP-1559. One major issue is the difference between average and worst-case scenarios: resource prices in Ethereum must be set to handle the worst case, i.e., a block's entire gas consumption using up one resource, but actual average usage is much lower, resulting in inefficiency.

What is multidimensional gas and how does it work?

The solution to these inefficiency problems is multidimensional gas: setting different prices and limits for different resources. This concept is technically independent of EIP-1559, but the existence of EIP-1559 makes it easier to implement. Without EIP-1559, optimally packing a block with multiple resource constraints is a complex multidimensional knapsack problem. With EIP-1559, most blocks are not full on any resource, so a simple algorithm like "accept any transaction that pays enough" is sufficient.

We already have multidimensional gas for execution and data blobs; in principle, we can extend it to more dimensions: such as calldata (transaction data), state reads/writes, and state size growth.

EIP-7706 introduces a new gas dimension specifically for calldata. At the same time, it simplifies the multidimensional gas mechanism by unifying three types of gas into one (EIP-4844-style) framework, thus also solving the mathematical flaw of EIP-1559. EIP-7623 is a more precise solution, targeting the average vs. worst-case resource issue by more strictly limiting maximum calldata without introducing a whole new dimension.

A further research direction is to solve the update rate problem, finding a faster base fee calculation algorithm while preserving the key invariants introduced by the EIP-4844 mechanism (i.e., in the long run, average usage is exactly close to the target value).

Existing Research Links

• EIP-1559 FAQ: 
• Empirical analysis of EIP-1559: 
• Improvement proposals allowing rapid adjustment: 
• Section on base fee mechanism in EIP-4844 FAQ: 
• EIP-7706: 
• EIP-7623: 
• Multidimensional gas: 

What remaining work and trade-offs are there?

The main trade-offs of multidimensional gas are twofold:

1. Increased protocol complexity: introducing multidimensional gas makes the protocol more complex.
2. Increased complexity of optimal algorithms for filling blocks: the best algorithm for filling blocks to capacity also becomes more complex.

Protocol complexity is relatively small for calldata, but increases for gas dimensions internal to the EVM (such as storage reads and writes). The problem is that not only do users set gas limits, but contracts also set limits when calling other contracts. Currently, they can only set single-dimensional limits.

A simple solution is to make multidimensional gas available only inside EOF, since EOF does not allow contracts to set gas limits when calling other contracts. Non-EOF contracts would need to pay for all types of gas when performing storage operations (for example, if SLOAD uses 0.03% of the block's storage access gas limit, then non-EOF users would also be charged 0.03% of the execution gas limit).

More research on multidimensional gas will help understand these trade-offs and find the ideal balance.

How does it interact with other parts of the roadmap?

Successfully implementing multidimensional gas can greatly reduce certain "worst-case" resource usage, reducing the pressure to optimize performance to support, for example, STARKed hash-based binary trees. Setting a clear target for state size growth will make it easier for client developers to plan and estimate requirements in the future.

As mentioned earlier, the existence of EOF makes it much easier to implement more extreme versions of multidimensional gas, thanks to its gas-unobservable property.

Verifiable Delay Functions (VDFs)

What problem does it solve?

Currently, Ethereum uses RANDAO-based randomness to select proposers. RANDAO randomness works by requiring each proposer to reveal a secret they committed to in advance, and each revealed secret is mixed into the randomness.

Each proposer therefore has "1 bit of manipulation power": they can change the randomness by not showing up (at a cost). This is reasonable for proposer selection, since giving up one opportunity to gain two new ones is rare. But for on-chain applications that need randomness, this is not ideal. Ideally, we should find a more robust source of randomness.

What is a VDF and how does it work?

A verifiable delay function is a function that can only be computed sequentially and cannot be accelerated by parallelization. A simple example is repeated hashing: for i in range(10**9): x = hash(x). Output the result, use a SNARK to prove its correctness, and it can be used as a random value.

The idea is to select the input based on information available at time T, but at time T the output is still unknown: the output will only be available at some point after T when someone has fully run the computation. Since anyone can run the computation, there is no possibility of withholding the result, and thus no ability to manipulate it.

The main risk of verifiable delay functions is unexpected optimization: someone finds a way to run the function faster than expected, thus manipulating the information they reveal at time T.

Unexpected optimization can happen in two ways:

1. Hardware acceleration: someone builds an ASIC that runs the computation loop faster than existing hardware.
2. Unexpected parallelization: someone finds a way to parallelize the function for faster speed, even if it takes 100 times more resources.

The task of creating a successful VDF is to avoid both problems while remaining practically efficient (for example, a hash-based approach has the issue that proving hashes in real time with SNARKs requires heavy hardware). Hardware acceleration is usually addressed by a public-interest participant creating and distributing near-optimal VDF ASICs themselves.

Existing Research Links

• VDF research website: 
• Thoughts on attacks on VDFs in Ethereum, 2018: 
• Attacks on the proposed VDF MinRoot: 

What remaining work and trade-offs are there?

Currently, there is no VDF construction that fully meets Ethereum researchers' requirements in all respects. More work is needed to find such a function. If found, the main trade-off is simply whether to include it: a trade-off between functionality and protocol complexity and security risk.

If we believe a VDF is secure but it turns out not to be, then depending on how it is implemented, security will degrade to the RANDAO assumption (1 bit of manipulation power per attacker) or slightly worse. Thus, even if the VDF fails, it will not break the protocol, but it will break applications or new protocol features that strongly depend on it.

How does it interact with other parts of the roadmap?

VDF is a relatively self-contained component in the Ethereum protocol. In addition to increasing the security of proposer selection, it also has applications in (i) on-chain applications that rely on randomness and (ii) cryptographic mempools, although making cryptographic mempools based on VDFs still depends on additional cryptographic discoveries that have not yet occurred.

One point to remember is that, given hardware uncertainty, there will be some "slack" between VDF output generation and need. This means information will be available a few blocks in advance. This can be an acceptable cost, but should be considered in single-slot finality or committee selection designs.

Obfuscation and One-Shot Signatures: The Distant Future of Cryptography

What problem does it solve?

One of Nick Szabo's most famous articles is his 1997 paper on the "God Protocol." In this paper, he pointed out that many multi-party applications rely on a "trusted third party" to manage interactions. In his view, the role of cryptography is to create a simulated trusted third party that does the same job, without actually requiring trust in any particular participant.

So far, we have only partially achieved this ideal. If all we need is a transparent virtual computer whose data and computation cannot be shut down, censored, or tampered with, and privacy is not a goal, then blockchains can achieve this, albeit with limited scalability.

If privacy is the goal, then until recently, we could only develop concrete protocols for specific applications: digital signatures for basic authentication, ring signatures and linkable ring signatures for primitive anonymity, identity-based encryption for more convenient encryption under certain trusted issuer assumptions, and blind signatures for Chaumian e-cash, etc. This approach requires a lot of work for each new application.

In the 2010s, we first glimpsed a different and more powerful approach, based on programmable cryptography. Instead of creating a new protocol for each new application, we can use powerful new protocols—specifically ZK-SNARKs—to add cryptographic guarantees to arbitrary programs.

ZK-SNARKs allow users to prove arbitrary statements about data they hold, and the proofs (i) are easy to verify, and (ii) reveal nothing except the statement itself. This is a huge advance for both privacy and scalability, and I compare it to the impact of transformers in AI. Thousands of person-years of application-specific work are suddenly replaced by this general solution, which can handle an unexpectedly wide range of problems.

However, ZK-SNARKs are just the first of three extremely powerful general primitives of this kind. These protocols are so powerful that when I think of them, they remind me of a set of very powerful cards in Yu-Gi-Oh!—a card game and TV show I played as a child: the Egyptian God Cards.

The Egyptian God Cards are three extremely powerful cards, and legend has it that the process of making them could be deadly, and their power is such that they are banned from duels. Similarly, in cryptography, we have this set of three Egyptian God protocols:

What are ZK-SNARKs and how do they work?

ZK-SNARKs are one of the three protocols we already have, and are relatively mature. In the past five years, dramatic improvements in prover speed and developer friendliness have made ZK-SNARKs the cornerstone of Ethereum's scalability and privacy strategy. But ZK-SNARKs have an important limitation: you need to know the data to prove it. The state in every ZK-SNARK application must have a unique "owner" who must be present to approve reads or writes to that state.

The second protocol, which does not have this limitation, is Fully Homomorphic Encryption (FHE). FHE allows you to perform any computation on encrypted data without looking at the data. This enables you to compute on users' data for their benefit while keeping both the data and the algorithm private.

It also allows you to extend voting systems like MACI to achieve nearly perfect security and privacy guarantees. For a long time, FHE was considered too inefficient for practical use, but now it has finally become efficient enough for real applications to emerge.

Cursive is an application that uses two-party computation and FHE for privacy-preserving common interest discovery.

However, FHE also has its limitations: any FHE-based technology still requires someone to hold the decryption key. This can be an M-of-N distributed setup, and you can even use Trusted Execution Environments (TEEs) for a second layer of protection, but this is still a limitation.

Next is the third protocol, which is even more powerful than the combination of the first two: indistinguishability obfuscation. Although this technology is still far from mature, as of 2020 we have theoretically valid protocols based on standard security assumptions, and recently work has begun on implementation.

Indistinguishability obfuscation allows you to create an "encrypted program" that performs arbitrary computation while hiding all internal details of the program. For example, you could put a private key into an obfuscated program that only allows you to use it to sign prime numbers, and distribute this program to others. They can use the program to sign any prime, but cannot extract the key. But its capabilities go far beyond this: combined with hashing, it can be used to implement any other cryptographic primitive, and more.

The only thing an obfuscated program cannot do is prevent itself from being copied. However, for this, even more powerful technology awaits in the future, although it depends on everyone having a quantum computer: quantum one-shot signatures.

By combining obfuscation and one-shot signatures, we can build an almost perfect trustless third party. The only goal that cannot be achieved by cryptography alone, and still requires blockchains, is censorship resistance. These technologies can not only make Ethereum itself more secure, but also enable more powerful applications to be built on top of it.

To better understand how these primitives add extra capabilities, let's use voting as a key example. Voting is an interesting problem because it needs to satisfy many complex security properties, including very strong verifiability and privacy. While voting protocols with strong security properties have existed for decades, we can make it harder by requiring the design to handle arbitrary voting protocols: such as quadratic voting, pairwise-limited quadratic funding, cluster-matched quadratic funding, etc. In other words, we want the "tallying" step to be an arbitrary program.

First, suppose we put the voting results publicly on the blockchain. This gives us public verifiability (anyone can verify that the final result is correct, including the tallying and eligibility rules) and censorship resistance (no one can stop people from voting). But we have no privacy.

Next, we add ZK-SNARKs. Now, we have privacy: each vote is anonymous, while ensuring that only authorized voters can vote and each voter can only vote once.

Next, we introduce the MACI mechanism, where votes are encrypted to the decryption key of a central server. The central server is responsible for the tallying process, including removing duplicate votes, and publishes a ZK-SNARK proof of the result. This preserves previous guarantees (even if the server cheats!), but if the server is honest, it also adds a coercion-resistance guarantee: users cannot prove how they voted, even if they want to. This is because while users can prove they voted, they cannot prove they did not vote to cancel out that vote. This prevents bribery and other attacks.

We run the tally in FHE, then do an N/2-of-N threshold decryption. This raises the coercion-resistance guarantee to N/2-of-N, instead of 1-of-1.

We obfuscate the tallying program and design the obfuscated program so that it can only output results when authorized, where authorization can be proof of blockchain consensus, some kind of proof of work, or a combination. This makes the coercion-resistance guarantee almost perfect: in the blockchain consensus case, 51% of validators would have to collude to break it; in the proof-of-work case, even if everyone colludes, re-tallying with different voter subsets to try to extract individual voter behavior would be extremely expensive. We can even have the program make small random adjustments to the final tally to further increase the difficulty of extracting individual voter behavior.

We add one-shot signatures, a quantum-computing-dependent primitive that allows a signature to be used only once for a specific type of information. This makes the coercion-resistance guarantee truly perfect.

Indistinguishability obfuscation also supports other powerful applications. For example:

1. DAOs, on-chain auctions, and other applications with arbitrary internal secret state.
2. True universal trusted setup: someone can create an obfuscated program containing a key and run any program and provide the output, putting hash(key, program) as input into the program. Given such a program, anyone can put program 3 into itself, combine the program's pre-key and their own key, and extend the setup. This can be used to generate 1-of-N trusted setup for any protocol.
3. ZK-SNARK verification with only one signature: this is very simple to implement—set up a trusted environment, let someone create an obfuscated program that only signs messages with the key if the ZK-SNARK is valid.
4. Encrypted mempools: encrypted transactions become very easy, so that transactions can only be decrypted when a future on-chain event occurs. This can even include a successfully executed VDF.

With one-shot signatures, we can make blockchains immune to 51% attacks that revert finality, although censorship attacks are still possible. Primitives similar to one-shot signatures make quantum money possible, solving the double-spending problem without blockchains, although many more complex applications still require chains.

If these primitives become efficient enough, most applications in the world could be decentralized. The main bottleneck will be verifying the correctness of implementations.

Here are some existing research links:

• Indistinguishability obfuscation protocol (2021): 
• How obfuscation helps Ethereum: 
• The first known one-shot signature construction: 
• Attempted implementation of obfuscation (1): 
• Attempted implementation of obfuscation (2): 

What work remains to be done, and what are the trade-offs?

There is still a lot of work to do. Indistinguishability obfuscation is still very immature, and candidate constructions run incredibly slowly (if at all), making them unusable in applications. Indistinguishability obfuscation is known for being "theoretically" polynomial time, but in practice, its running time may be longer than the lifetime of the universe. Recent protocols have alleviated the running time somewhat, but the overhead is still too high for routine use: one implementer expects a running time of one year.

Quantum computers do not even exist yet: all the constructions you see on the internet are either prototypes that cannot do more than 4-bit operations, or are not real quantum computers at all. While they may have quantum parts, they cannot run meaningful computations such as Shor's algorithm or Grover's algorithm. There are recent signs that "real" quantum computers are not far off. However, even if "real" quantum computers appear soon, it may still be decades before ordinary people can use quantum computers on their laptops or phones, before powerful institutions can break elliptic curve cryptography.

For indistinguishability obfuscation, a key trade-off is the security assumption, and there are more aggressive designs using special assumptions. These designs usually have more realistic running times, but the special assumptions sometimes end up being broken. Over time, we may better understand lattices and propose assumptions that are harder to break. However, this path is riskier. The more conservative approach is to stick to protocols whose security can be provably reduced to "standard" assumptions, but this may mean it takes longer to get protocols that run fast enough.

How does it interact with other parts of the roadmap?

Extremely powerful cryptography could be a game changer, for example:

1. If we get ZK-SNARK verification as simple as signatures, we may no longer need any aggregation protocols; we can verify directly on-chain.
2. One-shot signatures could mean more secure proof-of-stake protocols.
3. Many complex privacy protocols could be replaced by a single privacy-preserving Ethereum Virtual Machine (EVM).
4. Encrypted mempools become easier to implement.

Initially, the benefits will appear at the application layer, since Ethereum's L1 essentially needs to remain conservative in its security assumptions. However, even just application-layer use could be disruptive, just as the emergence of ZK-SNARKs was.