Vitalik: The Possible Future of the Ethereum Protocol—The Splurge

Author: Vitalik, founder of Ethereum; compiled by Deng Tong, Bitchain Vision

Note: This article is the sixth part of the series of articles recently published by Vitalik, founder of Ethereum,Possible futures of the Ethereum protocol, part 6: The Splurge”, see the fifth part”Vitalik: The Possible Future of the Ethereum Protocol—The Purge”, see the fourth part”Vitalik: The possible future of Ethereum The Verge”. See “Vitalik: Key objectives of the Ethereum The Scourge phase”, see the second part “Vitalik: How should the Ethereum protocol develop in the Surge stage”, see the first part”What else can be improved on Ethereum PoS”. The following is the full text of Part 6:

---

Special thanks to Justin Drake and Tim Beiko for their feedback and comments.

Some things are difficult to fall into a category.There are many “little things” in Ethereum protocol design that are very valuable to Ethereum’s success, but they are not suitable for being classified into a larger subcategory.In fact, about half of these end up being associated with various EVM improvements, while the rest consists of various niche themes.This is what “the Splurge” is for.

Splurge, 2023 Roadmap

The Splurge: Main objectives

• Bring EVM to a high performance and stable “final state”

• Introduce account abstraction into protocols so that all users can benefit from safer and more convenient accounts

• Optimize transaction fee economy, improve scalability, and reduce risks

• Explore advanced encryption technologies that can make Ethereum better in the long term

EVM improvements

What problems does it solve?

Today’s EVMs are difficult to perform static analysis, making it difficult to create efficient implementations, formal verification code, and further scale over time.Furthermore, it is very inefficient, making it difficult to implement multiple forms of advanced encryption unless they are explicitly supported by precompilation.

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 to be included in the next hard fork.EOF is a series of EIPs used to specify new versions of EVM code with many unique features, most notably:

• Separation between code (executable, but not read from EVM) and data (readable, but not executable).

• Dynamic jumps are prohibited, only static jumps are allowed.

• The EVM code can no longer observe gas-related information.

• Added a new explicit subroutine mechanism.

Structure of EOF code

Old-style contracts will continue to exist and can be created, although the old-style contracts may eventually be deprecated (and maybe even forcing them to convert to EOF code).New contracts will benefit from the efficiency gains brought by EOF – first, with subroutine functions, the bytecode will be slightly smaller, and then new EOF-specific functions, or EOF-specific gas costs will be reduced.

With the introduction of EOF, it became easier to introduce further upgrades.The most complete one at present is the EVM modular arithmetic extension (EVM-MAX).EVM-MAX creates a set of new operations designed for modular arithmetic and places them in a new memory space that is not accessible through other opcodes.This allows the use of optimizations, such as Montgomery multiplication.

A newer idea is to combine EVM-MAX with single instruction multi-data (SIMD) capabilities.SIMD has been an idea for Ethereum since Greg Colvin’s EIP-616.SIMD can be used to accelerate a variety of forms of encryption, including hash functions, 32-bit STARK, and dot matrix-based encryption.EVM-MAX and SIMD together form a pair of performance-oriented extensions of EVM.

The approximate design of the combined EIP starts with EIP-6690, and then:

• Allows (i) any odd number or (ii) any power of 2 (up to 2^768) as modulus

• For each EVMMAX opcode (add, sub, mul), add a version. This version does not use 3 immediate numbers x, y, and z, but uses 7 immediate numbers: x_start, x_skip, y_start, y_skip, z_start,z_skip, count.In Python code, these opcodes will perform operations equivalent to the following:

Unless in actual implementation, it will be processed in parallel.

• If possible, add XOR, AND, OR, NOT, and SHIFT (loop and acyclic) to at least 2 power modulo.Also added ISZERO (pushing the output to the EVM main stack).

This would be powerful enough to implement elliptic curve cryptography, small domain cryptography (e.g., Poseidon, circular STARK), traditional hash functions (e.g., SHA256, KECCAK, BLAKE), and dot matrix-based cryptography.

Other EVM upgrades may also be implemented, but so far they have received less attention.

What research are available?

EOF:https://evmobjectformat.org/

EVM-MAX:https://eips.ethereum.org/EIPS/eip-6690

SIMD:https://eips.ethereum.org/EIPS/eip-616

What are the remaining things to do and what trade-offs are there?

Currently, the EOF plan is included in the next hard fork.While it is always possible to remove it – the feature in the previous hard fork was removed at the last minute – it would be an uphill battle to do so.Deleting EOF means that EOF will not be used in any future upgrades to EVM, which can be done, but may be more difficult.

The main tradeoffs for EVM are L1 complexity and infrastructure complexity.EOF is a lot of code added to the EVM implementation, and static code inspection is very complex.However, in exchange, we gain simplification of the high-level language, simplification of the EVM implementation, and other benefits.It can be said that the roadmap for prioritizing continuous improvements to Ethereum L1 will be included and built on EOF.

An important job is to implement something like EVM-MAX plus SIMD and benchmark how much gas is required for various encryption operations.

How does it interact with the rest of the roadmap?

L1 adjusts its EVM to make the L2 easier to make the same adjustments.One adjustment and the other adjustment will cause some incompatibility, which has its own disadvantages.In addition, EVM-MAX plus SIMD can reduce gas costs for many proof systems, resulting in more efficient L2.It also makes it easier to remove more precompilations by replacing them with EVM code that can perform the same tasks without having to have a big impact on efficiency.

Account abstraction

What problems does it solve?

Currently, transactions can only be verified in one way: ECDSA signatures.Initially, the account abstraction was designed to go beyond this and allowed the account’s verification logic to be arbitrary EVM code.This can achieve a range of applications:

• Switch to quantum resistant encryption technology;

• Rotating old keys (widely considered a recommended security practice);

• Multi-signature wallet and social recovery wallet;

• Sign low-value operations with one key and high-value operations with another key (or a set of keys);

• Allowing privacy protocols to work without repeaters greatly reduces its complexity and eliminates critical central dependencies.

Since the account abstraction began in 2015, the target has expanded to include a large number of “convenience goals” such as no ETH but some ERC20 accounts are able to pay gas with that ERC20.The summary of these goals is shown in the following table:

Here MPC is multi-party computing: a 40-year-old technology that splits the key into multiple parts, stores it on multiple devices, and generates signatures using encryption without directly combining the individual parts of the key..

EIP-7702 is an EIP planned to be introduced in the next hard fork.EIP-7702 is the result of increasing recognition of the need to provide account abstraction to all users, including EOA users, to improve everyone’s user experience in the short term and avoid splitting into two ecosystems.This work began with EIP-3074 and eventually peaked in EIP-7702.EIP-7702 “convenience function” that makes the account abstract available to all users, including EOA (externally owned accounts, that is, accounts controlled by the ECDSA signature).

From the chart we can see that while some challenges (especially the “convenience” challenge) can be solved by multi-party computing or progressive technologies such as EIP-7702, most of the security goals of the initial proposal for abstract accounts can only be turned backTo solve the initial problem: allow smart contract code to control transaction verification.The reason why this hasn’t been done so far is that implementing it safely is a challenge.

what is it?How does it work?

In essence, the account abstraction is simple: allowing transactions to be initiated through smart contracts (not just EOA).The whole complexity comes from doing this in a way that facilitates maintenance of decentralized networks and prevents denial of service attacks.

An illustrative example of a key challenge is the multiple invalidation problem:

If there are 1000 accounts validation functions all rely on a single value S and there are transactions valid according to the current value of S in the memory pool, a transaction that flips the S value may invalidate all other transactions in the memory pool.This allows an attacker to spam the memory pool at a very low cost, blocking the network node’s resources.

Over the years, efforts to expand capabilities while limiting DoS risks have led to agreement on solutions to achieve “ideal account abstraction”: ERC-4337.

The way ERC-4337 works is to divide the processing of user operations into two stages: verification and execution.All validations are processed first, and then all executions are processed.In the memory pool, user operations are accepted only when the verification phase of the user operation only touches its own account and does not read the environment variables.This prevents multiple invalid attacks.The verification step also enforces strict gas restrictions.

ERC-4337 was designed as an out-of-protocol standard (ERC) because Ethereum client developers focused on merging at the time and had no extra capacity to handle other functions.This is why ERC-4337 uses its own objects (called user operations) instead of regular transactions.However, we have recently realized the need to include at least part of this into the agreement.Two main reasons are:

• EntryPoint is inherently inefficient as a contract: fixed ~100k gas overhead per package and thousands of additional charges per user operation;

• It is necessary to ensure that Ethereum properties (such as inclusion guarantees created by inclusion lists) continue to the account abstract user.

In addition, ERC-4337 also extends two functions:

• Payer: The feature that allows one account to pay fees on behalf of another account.This violates the rule that only accesses the sender’s account itself during the verification phase, so special processing is introduced to allow the payer mechanism and ensure it is secure.

• Aggregator: Supports signature aggregation features such as BLS aggregation or SNARK-based aggregation.This is necessary to achieve the highest data efficiency on summary.

What research are available?

Account abstract history introduction:https://www.youtube.com/watch?v=iLf8qpOmxQc

ERC-4337:https://eips.ethereum.org/EIPS/eip-4337

EIP-7702:https://eips.ethereum.org/EIPS/eip-7702

BLSWallet code (using the aggregation function):https://github.com/getwax/bls-wallet

EIP-7562 (Embed Account Abstract):https://eips.ethereum.org/EIPS/eip-7562

EIP-7701 (EOF-based Embed AA):https://eips.ethereum.org/EIPS/eip-7701

What are the remaining things to do and what trade-offs are there?

The main remaining question is how to fully incorporate the account abstraction into the agreement.The most popular account abstraction EIP is EIP-7701, which implements account abstraction on top of EOF.An account can have a separate code section for verification, and if the account has set the code section, the code will be executed in the verification step of the transaction of the account.

EOF code structure for EIP-7701 account

What’s fascinating about this approach is that it clearly shows two equivalent ways to view native account abstractions:

• EIP-4337, but as part of the protocol

• A new type of EOA where the signature algorithm is EVM code execution

If we first strictly limit the complexity of the code executable during verification – not allowing external state access, or even setting the gas limit too low at the beginning to be used for quantum-resistant or privacy-protected applications – then thisThe security of the method is very obvious: it simply replaces ECDSA verification with EVM code execution that requires similar time.However, over time, we need to relax these restrictions, as allowing privacy-protecting applications to work without repeaters and to resist quantum.To do this, we really need to find ways to solve DoS risks in a more flexible way without the need for extremely simple verification steps.

The main trade-off seems to be “taking something that fewer people are satisfied with as soon as possible” rather than “waiting longer and maybe getting a more ideal solution”.The ideal approach might be some kind of mixed approach.One hybrid approach is to take some use cases as a guide faster and leave more time to address others.Another approach is to first deploy a more ambitious abstract version of the account on L2.However, this has the challenge that for an L2 team willing to work hard to adopt the proposal, they need to be sure that L1 and/or other L2 will adopt something compatible later.

Another application we need to consider explicitly is the keystore account, which stores the state associated with the account on L1 or dedicated L2, but can be used on L1 and any compatible L2.Doing this effectively may require L2 to support opcodes such as L1SLOAD or REMOTESTATICCALL, although it also requires an account abstract implementation on L2 to support it.

How does it interact with the rest of the roadmap?

Included lists require support for account abstract transactions.In fact, the requirements for including lists are ultimately very similar to those for decentralized memory pools, although the flexibility of including lists is slightly higher.Furthermore, ideally, account abstract implementations should be coordinated on L1 and L2 as much as possible.If in the future we expect most users to use keystore summary, then the account abstraction design should take this into account.

EIP-1559 Improvements

What problems does it solve?

EIP-1559 was launched on Ethereum in 2021 and significantly improved the average block inclusion time.

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

• The formula is slightly flawed: instead of targeting 50% of the blocks, it targets ~50-53% of the full blocks based on the variance (this is related to what mathematicians call the “AM-GM inequality”);

• It doesn’t adjust fast enough in extreme conditions.

The formula later used for blobs (EIP-4844) was clearly designed to solve the first problem and was generally more concise.Neither EIP-1559 nor EIP-4844 attempted to resolve the second issue.Therefore, the status quo is a confusing state of half-way abandonment involving two different mechanisms, and even one is that both need improvement over time.

In addition, Ethereum resource pricing has other weaknesses that are not related to EIP-1559, but can be solved by adjusting EIP-1559.One major problem is the difference between the average and the worst-case scenario: the resource price in Ethereum must be set to be able to handle the worst-case scenario, i.e. the entire gas of a block consumes a resource, but the average usage is much lowerIn this way, inefficiency is caused.

what is it?How does it work?

The solution to these inefficiency problems is multidimensional gas: set different prices and restrictions on different resources.This concept is technically independent of EIP-1559, but EIP-1559 makes it easier: without EIP-1559, optimum packaging of blocks with multiple resource constraints is a complex multi-dimensional backpacking problem.With EIP-1559, most blocks are not fully loaded on any resource, so a simple algorithm of “accepting anything that pays enough” is enough.

We have multidimensional gas for execution and blobs today; in principle, we can add it to more dimensions: call data, state read/write, and state size extension.

EIP-7706 introduces a new gas dimension to the call data.At the same time, it also solves the mathematical flaws of EIP-1559 by simplifying the multidimensional gas mechanism by making all three types of gases belong to a (EIP-4844-style) framework.

EIP-7623 is a more accurate solution to the average and worst-case resource problems, which more strictly limits the maximum call data without introducing completely new dimensions.

A further direction is to solve the update rate problem and find a faster basic fee calculation algorithm while retaining the key invariants introduced by the EIP-4844 mechanism (i.e., the average usage is completely close to the target in the long run).

What research are available?

EIP-1559 FAQ:https://notes.ethereum.org/@vbuterin/eip-1559-faq

EIP-1559 Empirical Analysis:https://dl.acm.org/doi/10.1145/3548606.3559341

Recommended improvements to allow quick adjustments:https://kclpure.kcl.ac.uk/ws/portalfiles/portal/180741021/Transaction_Fees_on_a_Honeymoon_Ethereums_EIP_1559_One_Month_Later.pdf

EIP-4844 FAQ, section on the basic fee mechanism:https://notes.ethereum.org/@vbuterin/proto_danksharding_faq#How-does-the-exponential-EIP-1559-blob-fee-adjustment-mechanism-work

EIP-7706:https://eips.ethereum.org/EIPS/eip-7706

EIP-7623:https://eips.ethereum.org/EIPS/eip-7623

Multidimensional Gas:https://vitalik.eth.limo/general/2024/05/09/multidim.html

What are the remaining things to do and what trade-offs are there?

There are two main trade-offs for multidimensional gas:

• It increases the complexity of the protocol

• It increases the complexity of the best algorithm required to fill blocks to capacity

Protocol complexity is a relatively small problem for calldata, but a larger problem for gas dimensions “inside the EVM” (such as storage read and write).The problem is that it is not just the user setting gas limits: contracts also set restrictions when calling other contracts.And now, the only way they set restrictions is one-dimensional.

An easy way to eliminate this problem is to make multidimensional gas available only inside EOF, because EOF does not allow contracts to set gas limits when calling other contracts.Non-EOF contracts must pay all types of gas fees when performing storage operations (for example, if SLOAD spends 0.03% of the block storage access gas limit, non-EOF users will also be charged 0.03% of the gas limit for execution)

Doing more research on multidimensional gas will help to understand tradeoffs and find the ideal balance.

How does it interact with the rest of the roadmap?

Successful implementation of multidimensional Gas can greatly reduce the use of some “worst-case” resources, thereby reducing the pressure to optimize performance to support binary trees based on STARKed hash, for example.Setting a hard target for state size growth will make it easier for client developers to plan and estimate their future needs.

As mentioned above, because EOF is Gas unobservable, more extreme multidimensional versions of Gas are easier to implement.

Verified Delay Function (VDF)

What problems does it solve?

Today, Ethereum uses RANDAO-based randomness to select proposers.The working principle of RANDAO-based randomness is to require each proposer to reveal the secrets they promised in advance and to mix each disclosed secret into the randomness.Therefore, each proposer has a “1-bit manipulation right”: they can change the randomness by not showing up (at a price).This is reasonable for the proposer, as few people can give themselves two new proposal opportunities by giving up one.But for on-chain applications that require randomness, this is not possible.Ideally, we would find a stronger source of randomness.

what is it?How does it work?

A verifiable delay function is a function that can only be calculated in order and cannot be accelerated by parallelization.A simple example is repeating hash: calculate i:x = hash(x) in range (10**9).The output is proven by SNARK correctness and can be used as a random value.The idea is that the input is selected based on the information available at time T, while the output is not clear at time T: it will only be available at some time after T after someone has fully run the calculation.Because anyone can run the calculation, it is impossible to hide the results and therefore has no ability to manipulate the results.

The main risk of verifiable delay function is unexpected optimization: someone figured out how to run the function at a much faster rate than expected, allowing them to manipulate the information they reveal at time T based on future output.Unexpected optimization can occur in two ways:

• Hardware acceleration: Someone has made an ASIC whose computational loop runs much faster than existing hardware.

• Unexpected parallelization: Someone has found a way to run the function faster through parallelization, even if it takes more than 100 times the resource.

The task of creating a successful VDF is to avoid both issues while remaining efficient and practical (for example, one problem with hash-based approaches is that real-time SNARK proves to be hardware-required).Hardware acceleration is often solved by allowing public interest actors to create and distribute reasonably close to the optimal ASICs for VDFs themselves.

What research are available?

vdfresearch.org:https://vdfresearch.org/

Thoughts on attacks on VDFs used in Ethereum in 2018:https://ethresear.ch/t/verifiable-delay-functions-and-attacks/2365

Attack on MinRoot (a proposed VDF):https://inria.hal.science/hal-04320126/file/minrootanalysis2023.pdf

What are the remaining things to do and what trade-offs are there?

At present, there is no VDF structure that fully meets all the needs of Ethereum researchers.More work is needed to find such features.If we have it, the main tradeoff is just whether it is included: a simple tradeoff between functionality and protocol complexity and security risks.If we think VDF is safe, but ultimately unsafe, security will be downgraded to the RANDAO hypothesis (1 bit manipulation per attacker) or worse.So even if VDF is broken, it will break the protocol, but it will break the application or any new protocol features that heavily relies on it.

How does it interact with the rest of the roadmap?

VDF is a relatively independent component of the Ethereum protocol, but in addition to improving the security of the proposer’s choice, it can also be used for (i) on-chain applications that rely on randomness, as well as potentially (ii) encrypted memory pools., although VDF-based production of encrypted memory pools still relies on other encryption discoveries that have not yet occurred.

One thing to remember is that given the hardware uncertainty, there will be some “gap” between generating VDF output and requiring output.This means that the information will be available before several blocks.This may be an acceptable cost, but should be considered in single slot finality or committee selection design, etc.

Confusion and one-time signature: the future of cryptography

What problems does it solve?

One of Nick Saab’s most famous posts was a 1997 article about “God’s Agreement.”In this article, he notes that multi-party applications often rely on “trusted third parties” to manage interactions.In his opinion, the role of cryptography is to create a simulated trusted third party to do the same job without actually requiring trust in any particular participant.

“Mathematically Trusted Protocol”, chart drawn by Nick Szabo

So far, we can only partially approach this ideal.If all we need is a transparent virtual computer where data and computing cannot be shut down, censored or tampered with, but privacy is not the goal, then blockchain can do this, albeit with limited scalability.If privacy is a goal, until recently we could only develop some specific protocols for specific applications: digital signatures for basic authentication, ring signatures for original anonymous forms and linkable ring signatures, identity-based encryption(Implement more convenient encryption under specific assumptions for trusted issuers), blind signatures for Chaumian electronic cash, and so on.This approach requires a lot of work to do for each new application.

In the 2010s, we saw for the first time a different and more powerful approach based on programmable encryption.Instead of creating a new protocol for each new application, we can add encryption guarantees to any program using powerful new protocols (especially ZK-SNARK).ZK-SNARK allows users to prove any statement of the data they hold by: Prove (i) easy to verify, and (ii) no data other than the statement itself is disclosed.This is a huge advance for privacy and scalability, and I liken it to the transformer effect in artificial intelligence.Thousands of people have a year of specific application work suddenly replaced by a universal solution that you can solve a surprisingly wide range of problems with just plug in.

But ZK-SNARK is just the first of three similarly extremely powerful universal primitives.These protocols are so powerful that when I think of them they remind me of an extremely powerful set of cards in Yu-Gi-Oh, a card game and TV show that I played as a kid oftenAnd see: Egyptian God Card.Egyptian God Cards are three extremely powerful cards, and according to legend, making them can be fatal and so powerful that they are not allowed to be used in duels.Similarly, in cryptography, we have three Egyptian God protocols:

what is it?How does it work?

ZK-SNARK is one of three protocols we already have and has reached a high level of maturity.Over the past five years, ZK-SNARK has made huge progress in proving speed and developer friendliness and has become the cornerstone of Ethereum’s scalability and privacy policies.But ZK-SNARK has one important limitation: you need to know the data to prove it.Each state in the ZK-SNARK application must have an “owner” that must be present to approve any reads or writes to it.

The second protocol does not have this limitation, namely, Fully Homomorphic Encryption (FHE).FHE allows you to perform any calculations on encrypted data without viewing it.This allows you to perform calculations on user data to benefit users while keeping the data and algorithms private.It also allows you to expand voting systems like MACI for near-perfect security and privacy guarantees.FHE has long been considered too inefficient to be practical, but now it has finally become efficient enough that we are starting to see applications.

Cursive is an app that uses both computing and FHE for privacy discovery for common interests.

But FHE also has its limitations: any FHE-based technology still requires someone to hold the decryption key.This may be an M-of-N distributed setup, you can even add a layer 2 defense using TEE, but that’s still a limitation.

This gives us a third protocol, which is more powerful than the other two protocols combined: indistinguishable confusion.While it is far from mature, as of 2020, we have developed theoretically effective protocols based on standard security assumptions and recently started implementing work.Indistinguishable obfuscation allows you to create an “encrypted program” that performs arbitrary calculations, so that all internal details of the program are hidden.To give a simple example, you can put the private key into an obfuscated program that only allows you to use it to sign prime numbers and distribute the program to others.They can use the program to sign any prime numbers, but they cannot retrieve the key.But it does much more than that: it can be used with hash, and it can be used to implement any other encryption primitive, and even more.

The only thing an obfuscated program cannot do is prevent itself from being copied.But for this, there is something more powerful about to come, although it depends on everyone having a quantum computer: a quantum one-time signature.

Using obfuscation and one-time signatures, we can build almost perfect, trustless third parties.The only thing we can’t do with encryption technology is what we still need blockchain to do, which is to ensure censorship resistance.These technologies not only allow us to make Ethereum itself more secure, but also build more powerful applications on top of Ethereum.

To understand how each of these primitives adds additional functionality, let’s look at a key example: voting.Voting is a fascinating question because it has many tricky security attributes that need to be met, including very strong verifiability and privacy.While voting protocols with strong security have been around for decades, let’s make the problem harder by saying we want a design that can handle arbitrary voting protocols: secondary voting, paired bounded secondary financing, cluster matching secondary financing, etc.That is, we want the “count counting” step to be an arbitrary procedure.

• First, let’s say we put the vote publicly on the blockchain.This provides us with public verifiability (anyone can verify that the final result is correct, including vote counting rules and eligibility rules) and censorship resistance (which can’t stop people from voting).But we have no privacy.

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

• Now, we add the MACI mechanism.The vote is encrypted to the decryption key of the central server.The central server needs to run the vote counting process, including discarding the duplicate votes and publishing ZK-SNARK that proves the answer.This retains the previous guarantee (even if the server cheats!), but if the server is honest it adds a mandatory resistance guarantee: the user cannot prove how they voted, even if they want to.This is because, while users can prove what they voted, they cannot prove that they did not make another vote to cancel the vote.This prevents bribery and other attacks.

• We run the counting internally in FHE and then decrypt it by performing N/2-of-N threshold decryption calculations.This makes the mandatory resistance guaranteed to be N/2-of-N, not 1-of-1.

• We obfuscate the counting process and design the obfuscation process so that it can give output only if licensed, whether it is proof of blockchain consensus, or through a certain amount of proof of work, or bothBoth.This makes the mandatory resistance guaranteed almost perfect: in the case of blockchain consensus, you need 51% of validators to collude it, while in the case of proof of work, even if everyone colludes, rerun with a different subsetThe vote counting of voters in an attempt to extract individual voters will also be very expensive.We can even have the program adjust the final result slightly randomly, making it more difficult to extract individual voters’ behavior.

• We added a one-time signature, a primitive that relies on quantum computing, allowing signatures to be used only to sign a message of some type at once.This makes the anti-depression guaranteed true perfection.

Indiscriminatory obfuscation can also enable other powerful applications.For example:

• DAO, on-chain auctions and other applications with any internal secret status.

• Trusted Settings that are truly universal: Someone can create a fuzzy program with a key, and can run any program and provide output, putting hash(key, program) into the program as input.Given such a program, anyone can put the program into itself, combine the program’s existing key with their own, and extend the settings in the process.This can be used to generate a 1-of-N trusted setting for any protocol.

• ZK-SNARKs, its verification is only signature.Implementing this is simple: There is a trusted setup where someone creates a fuzzy program that will only sign the message with the key if it is a valid ZK-SNARK.

• Encrypted memory pool.Crypto transactions have become so easy that they will only be decrypted if certain on-chain events occur in the future.This may even include successful execution of VDFs.

With one-time signatures, we can protect the blockchain from 51% final reversal attacks, although censorship attacks may still exist.Primitives similar to one-time signatures can implement quantum currencies and solve the dual payment problem without blockchain, although many more complex applications still require blockchain.

If these primitives are efficient enough, most applications in the world can be decentralized.The main bottleneck lies in verifying the correctness of the implementation.

What research are available?

The 2021 Indiscriminatory Obfuscation Agreement:https://eprint.iacr.org/2021/1334.pdf

Confusion How to Help Ethereum:https://ethresear.ch/t/how-obfuscation-can-help-ethereum/7380

The first known one-time signature construct:https://eprint.iacr.org/2020/107.pdf

Obfuscated attempts to implement (1):https://mediatum.ub.tum.de/doc/1246288/1246288.pdf

Obfuscated attempts to implement (2):https://github.com/SoraSuegami/iOMaker/tree/main

What are the remaining things to do and what trade-offs are there?

There are still many things to do.Indiscriminatory confusion is very immature, and candidate constructs are millions of times slower (or even more) than applications.Indiscriminatory confusion is known for the running time of polynomial time “in theory”, but it takes longer to run in practice than the lifespan of the universe.Newer protocols make runtimes less extreme, but the overhead is still too high for regular use: one implementer expects runtime to be one year.

Quantum computers don’t even exist: All the constructions you may read on the internet today are either prototypes that can’t perform any computations larger than 4 bits, or they aren’t really quantum computers, and while they may contain quantum parts, they can’t run reallyComputation of meaning, such as Shor algorithm or Grover algorithm.Recently, there are signs that “real” quantum computers are no longer that far away.However, even if “real” quantum computers come out soon, the days when ordinary people have quantum computers on their laptops or phones may be decades later than powerful institutions obtaining quantum computers that can crack elliptic curve codes.

A key trade-off for indiscriminatory confusion is the security assumption.There are more radical designs that use strange assumptions.These usually have more realistic run times, but strange assumptions are sometimes broken.Over time, we may eventually have enough knowledge of the yard to make assumptions that will not be broken.However, this road is more dangerous.A more conservative approach is to stick to protocols where security can be proven as “standard” assumptions, but this may mean it will take us longer to get a protocol that runs fast enough.

How does it interact with the rest of the roadmap?

Extremely powerful encryption technology could be a game-changer.For example:

• If we get ZK-SNARK which is as easy to verify as a signature, we may not need any aggregation protocol; we can verify it directly on the chain.

• One-time signatures may mean a safer proof of stake agreement.

• Many complex privacy protocols can be replaced by “only” privacy-protected EVMs.

• Encrypted memory pools become easier to implement.

First, the benefits will occur at the application layer, because Ethereum L1 essentially needs to be conservative on security assumptions.However, even using the application layer alone can be a game-changer, just like the advent of ZK-SNARK.