Vitalik on the possible future of Ethereum (Part 6): The Splurge
In Ethereum protocol design, about half of the content involves different types of EVM improvements, and the rest is made up of various niche topics. This is what "prosperity" means.
Original title: "Possible futures of the Ethereum protocol, part 6: The Splurge"
Original author: @VitalikButerin
Original translation: zhouzhou, BlockBeats
The following is the original content (the original content has been reorganized for easier reading and understanding):
Some things are difficult to classify into a single category. In the design of the Ethereum protocol, there are many "details" that are very important to the success of Ethereum. In fact, about half of the content involves different types of EVM improvements, and the rest is made up of various niche topics. This is the meaning of "prosperity".
2023 Roadmap: Prosperity
Prosperity: Key Goals
Move the EVM to a performant and stable "final state"
Introduce account abstraction into the protocol, allowing all users to enjoy more secure and convenient accounts
Optimize transaction fee economics to increase scalability while reducing risk
Explore advanced cryptography to significantly improve Ethereum in the long term
In This Chapter
VDF (Verifiable Delay Function)
Obfuscation and One-Time Signatures: The Far Future of Cryptography
EVM Improvements
What Problem Is Solved?
The current EVM is difficult to statically analyze, which makes it difficult to create efficient implementations, formally verify code, and make further extensions. In addition, the EVM is inefficient and many forms of advanced cryptography are difficult to implement unless explicitly supported via precompilation.
What is it and how does it work?
The first step in the current EVM improvement roadmap is the EVM Object Format (EOF), planned for inclusion in the next hard fork. EOF is a series of EIPs that specify a new version of the EVM code with a number of unique characteristics, most notably: · Separation between code (executable, but not readable from the EVM) and data (readable, but not executable) · Dynamic jumps are prohibited, only static jumps are allowed · EVM code can no longer observe gas-related information · A new explicit subroutine mechanism has been added
Structure of EOF Code
BOOM: EVM Improvements (continued)
Old-style contracts will continue to exist and can be created, although they will likely be phased out (and perhaps even forced to convert to EOF code) eventually. New contracts will benefit from the efficiency gains brought by EOF - first in slightly smaller bytecode via the subroutine feature, and later in the form of new EOF-specific functionality or reduced gas costs.
Further upgrades have become easier after the introduction of EOF, with the most developed being the EVM Modular Arithmetic Extension (EVM-MAX). EVM-MAX creates a new set of operations specifically for modular arithmetic and places them in a new memory space that is not accessible via other opcodes, making it possible to use optimizations such as Montgomery multiplication.
A newer idea is to combine EVM-MAX with the Single Instruction Multiple Data (SIMD) feature, which has been around for a long time in Ethereum, 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, and 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, and 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 immediate values x, y, z, but 7 immediate values: x_start, x_skip, y_start, y_skip, z_start, z_skip, count. In Python code, these opcodes 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 a real implementation, this will be handled in parallel.
· Possibly add XOR, AND, OR, NOT, and SHIFT (both looping and non-looping), at least for modulos of powers of 2. Also add ISZERO (push output to the EVM main stack), which will be powerful enough to implement elliptic curve cryptography, small domain cryptography (like Poseidon, Circle STARKs), traditional hash functions (like SHA256, KECCAK, BLAKE), and lattice-based cryptography. Other EVM upgrades are also possible but have received less attention so far.
Existing Research Links
EOF: https://evmobjectformat.org/
EVM-MAX: https://eips.ethereum.org/EIPS/eip-6690
SIMD: https://eips.ethereum.org/EIPS/eip-616
Remaining Work and Tradeoffs
Currently, EOF is scheduled for inclusion in the next hard fork. While it is always possible to remove it at the last minute - features have been temporarily removed in previous hard forks, doing so would be challenging. Removing EOF would mean that any future upgrades to the EVM would need to be done without EOF, which is possible but likely to be more difficult.
The main trade-off of the EVM is L1 complexity vs. infrastructure complexity, EOF is a lot of code that needs to be added to the EVM implementation, and static code checking is relatively complex. However, in exchange, we can simplify the high-level language, simplify the EVM implementation, and other benefits. It can be said that the roadmap that prioritizes continued improvement of Ethereum L1 should include and build on EOF.
One important work to be done is to implement something like EVM-MAX plus SIMD and benchmark the gas consumption of various crypto operations.
How does it interact with other parts of the roadmap?
L1 adjusts its EVM so that L2 can adjust accordingly more easily, which may cause incompatibility and adverse effects if the two are not adjusted in sync. In addition, EVM-MAX and SIMD can reduce the gas cost of many proof systems, making L2 more efficient. It also makes it easier to replace more precompilations with EVM code that can perform the same task, probably without a huge performance hit.
Account Abstraction
What problem does it solve?
Currently, transactions can only be verified in one way: ECDSA signatures. Originally, account abstraction was intended to go beyond this, allowing the verification logic for an account to be arbitrary EVM code. This could enable a range of applications:
· Switch to quantum-resistant cryptography
· Rotate old keys (widely considered a recommended security practice)
· Multi-signature wallets and social recovery wallets
· Use one key for low-value operations and another key (or set of keys) for high-value operations
Allows privacy protocols to work without relays, significantly reducing their complexity and removing a key central point of dependency
Since the account abstraction was proposed in 2015, its goals have also expanded to include a large number of "convenience goals", such as an account that does not have ETH but has some ERC20s being able to pay for gas with ERC20s. Here is a summary chart of these goals:
MPC (Multi-Party Computation) is a 40-year-old technique for splitting keys into multiple parts and storing them on multiple devices, using cryptographic techniques to generate signatures without directly combining these key parts.
EIP-7702 is a proposal planned to be introduced in the next hard fork. EIP-7702 is the result of a growing awareness of providing account abstraction convenience to benefit all users (including EOA users), aiming to improve the experience of all users in the short term and avoid a split into two ecosystems.
The work started with EIP-3074 and eventually formed EIP-7702. EIP-7702 provides the "convenience features" of account abstraction to all users, including today's EOA (externally owned accounts, i.e. accounts controlled by ECDSA signatures).
As you can see from the chart, while some challenges (especially the "convenience" challenge) can be solved by incremental techniques like multi-party computation or EIP-7702, the main security goal of the original account abstraction proposal can only be achieved by backtracking and solving the original problem: allowing smart contract code to control transaction validation. The reason this has not been achieved to date is that it is challenging to implement securely.
What is it and how does it work?
Account abstraction is simple at its core: allowing smart contracts to initiate transactions, not just EOAs. The entire complexity comes from implementing this in a way that is friendly to maintaining a decentralized network and protecting against denial of service attacks.
A typical key challenge is the multiple invalidation problem:
If there are 1,000 accounts whose validation functions all depend on a single value S, and the current value of S makes all transactions in the memory pool valid, then a single transaction that flips the value of S may invalidate all other transactions in the memory pool. This allows attackers to send junk transactions to the memory pool at a very low cost, thereby clogging the resources of network nodes.
After years of efforts to expand functionality while limiting the risk of denial of service (DoS), a solution to achieve "ideal account abstraction" was finally obtained: ERC-4337.
ERC-4337 works by dividing the processing of user operations into two stages: verification and execution. All validations are processed first, all executions are processed afterwards. In the memory pool, user actions are accepted only if the validation phase only involves their own account and does not read environment variables. This prevents multiple invalidation 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 merging (Merge) and had no extra energy to handle other features. This is why ERC-4337 used objects called user actions instead of regular transactions. However, recently we realized that at least some of them need to be written into the protocol.
Two key reasons are as follows:
1. The inherent inefficiency of EntryPoint as a contract: each bundle has a fixed overhead of about 100,000 gas, and thousands of additional gas per user operation.
2. The necessity to ensure Ethereum properties: the inclusion guarantee created by the inclusion list needs to be transferred to the account abstraction user.
In addition, ERC-4337 also extends two functions:
· Paymasters: A function that allows one account to pay fees on behalf of another account, which violates the rule that only the sender account itself can be accessed during the verification phase, so special processing is introduced to ensure the security of the payment agent mechanism.
· Aggregators: Functions that support signature aggregation, such as BLS aggregation or SNARK-based aggregation. This is necessary to achieve the highest data efficiency on Rollup.
Links to Existing Research
Talk on the History of Account Abstraction: 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 aggregation function): EIP-7562 (Account Abstraction Written into the Protocol): https://eips.ethereum.org/EIPS/eip-7562
EIP-7701 (write protocol account abstraction based on EOF): https://eips.ethereum.org/EIPS/eip-7701
Remaining work and trade-offs
The main issue that needs to be addressed is how to fully introduce account abstraction into the protocol. The most popular write protocol account abstraction EIP is EIP-7701, which implements account abstraction on top of EOF. An account can have a separate code section for verification. If the account sets the code section, the code will be executed in the verification step of transactions from the account.
What’s fascinating about this approach is that it clearly demonstrates two equivalent perspectives on local account abstraction:
1. Making EIP-4337 part of the protocol
2. A new type of EOA where the signing algorithm is EVM code execution
If we start with tight bounds on the complexity of the code that can be executed during verification—no access to external state allowed, and even the initial gas limit is set so low that it is ineffective for quantum resistance or privacy-preserving applications—then the security of this approach is pretty clear: just replace ECDSA verification with EVM code execution that takes similar time.
However, over time we will need to relax these bounds, as allowing privacy-preserving applications to work without relays and quantum resistance are both very important. To do this, we need to find ways to more flexibly address denial of service (DoS) risks without requiring extremely minimalistic verification steps.
The main trade-off seems to be "write a solution quickly that satisfies fewer people" vs. "wait longer for a potentially more ideal solution", and the ideal approach may be some kind of hybrid. One hybrid approach would be to write some use cases faster and leave more time to explore other use cases. Another approach would be to deploy a more ambitious version of the account abstraction on L2 first. However, the challenge is that L2 teams need to be confident that the proposal will work before they are willing to implement it, especially to ensure that L1 and/or other L2s can adopt compatible solutions in the future.
Another application we also need to consider explicitly 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 efficiently may require L2 to support opcodes such as L1SLOAD or REMOTESTATICCALL, but this will also require the account abstraction implementation on L2 to support these operations.
How does it interact with the rest of the roadmap?
Inclusion lists need to support account abstraction transactions, and in practice the requirements for inclusion lists are actually very similar to those for decentralized memory pools, although with slightly more flexibility for inclusion lists. Additionally, account abstraction implementations should be coordinated between L1 and L2 as much as possible. If in the future we expect most users to use key storage Rollup, account abstraction design should be based on this.
EIP-1559 Improvements
What problem does it solve?
EIP-1559 was activated on Ethereum in 2021 and significantly improved average block inclusion time.
Waiting time
However, the current EIP-1559 implementation is not perfect in several aspects:
1. The formula is slightly flawed: it doesn’t target 50% of blocks, but rather about 50-53% full, depending on the variance (this has to do with what mathematicians call the “arithmetic-geometric mean inequality”).
2. It doesn’t adjust quickly enough in extreme cases.
The later formula for blobs (EIP-4844) is specifically designed to address the first problem, and is also cleaner overall. However, neither EIP-1559 itself nor EIP-4844 attempts to address the second problem. As a result, the status quo is a messy middle ground involving two different mechanisms, and there is an argument that both need to be improved over time.
In addition, there are other weaknesses in Ethereum resource pricing that are unrelated to EIP-1559, but can be addressed by adjustments to EIP-1559. One of the main issues is the difference between the average and worst cases: resource prices in Ethereum must be set to handle the worst case, where the entire gas consumption of a block takes up a resource, but the actual average usage is much lower than this, leading to inefficiencies.
What is Multi-dimensional Gas and how does it work?
The solution to these inefficiencies is Multi-dimensional Gas: set 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 packaging a block with multiple resource constraints is a complex multi-dimensional knapsack problem. With EIP-1559, most blocks will never reach full capacity on any resource, so a simple algorithm like "accept any transaction that pays enough" will suffice.
Currently we have multi-dimensional gas for execution and data blocks; in principle, we can extend this to more dimensions: such as calldata (transaction data), state read/write, and state size expansion.
Links to existing research
EIP-1559 FAQ: EIP-1559 FAQ
Empirical analysis of EIP-1559: Empirical analysis
Proposal to improve this: EIP-7706: EIP-7706
EIP-7623: EIP-7623
Multidimensional Gas: Multidimensional gas
What is the remaining work and trade-offs?
There are two main trade-offs for multidimensional gas:
1. Increased protocol complexity: Introducing multidimensional gas will make the protocol more complex.
2. Increased complexity of the optimal algorithm required to fill blocks: The optimal algorithm to bring blocks to capacity will also become complex.
The protocol complexity is relatively small for calldata, but it increases for those gas dimensions that are 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. And currently, the only way they can set limits is single-dimensional.
A simple solution is to make multi-dimensional Gas only available inside EOF, because EOF does not allow contracts to set gas limits when calling other contracts. Non-EOF contracts need to pay for all types of Gas when performing storage operations (for example, if SLOAD takes up 0.03% of the block storage access gas limit, then non-EOF users will also be charged 0.03% of the execution gas limit fee).
More research into multi-dimensional Gas will help understand these trade-offs and find an ideal balance.
How does it interact with other parts of the roadmap?
Successful implementation of multi-dimensional Gas could significantly reduce some of the “worst case” resource usage, reducing the pressure to optimize performance to support requirements such as binary trees underlying STARKed hashes. 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 simpler to implement more extreme versions of multidimensional gas, due to its unobservable nature.
Verifiable Delay Functions (VDFs)
What problem does it solve?
Currently, Ethereum uses RANDAO-based randomness to select proposers, and RANDAO's randomness works by requiring each proposer to reveal a secret they committed to in advance, and mixing each revealed secret into the randomness.
Each proposer therefore has "1 bit of control": they can change the randomness by not showing up (with a cost). This approach is reasonable for finding proposers, because it's very rare that you give up one opportunity to get two new proposals. But it's not ideal for on-chain applications that need randomness. 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 sped up by parallelization. A simple example is repeated hashing: for i in range(10**9): x = hash(x). The output, whose correctness is proven using a SNARK, can be used as a random value.
The idea is that the input is chosen based on information available at time T, while the output is not yet known at time T: the output is only available at some point after T, after someone has fully run the computation. Because anyone can run the computation, there is no possibility of withholding the result, and therefore no ability to manipulate the result.
The main risk of a verifiable delay function is accidental optimization: someone finds a way to run the function faster than expected, and thus manipulates the information they reveal at time T.
Accidental optimization can happen in two ways:
1. Hardware acceleration: someone builds an ASIC that runs the computation loop faster than existing hardware.
2. Accidental Parallelization: Someone finds a way to run a function faster by parallelizing it, even if doing so requires 100x the resources.
The task of creating a successful VDF is to avoid both of these problems while keeping the efficiency practical (e.g., one problem with hash-based approaches is that SNARK-ing hashes in real time requires heavy hardware). Hardware acceleration is usually solved by a public interest actor creating and distributing a near-optimal VDF ASIC on their own.
Links to Existing Research
VDF Research Website: vdfresearch.org
Thinking on attacks on VDFs in Ethereum, 2018: Thinking on attacks
Attacks against the proposed VDF MinRoot: Attacks against MinRoot
What is the remaining work and trade-offs?
Currently, no single VDF construction fully satisfies all of the requirements of Ethereum researchers. More work is needed to find such a function. If found, the main trade-off is whether to include it: a simple trade-off between functionality and protocol complexity and security risk.
If we believe a VDF is secure, but it turns out it is not, then depending on how it is implemented, the security will degenerate to the RANDAO assumption (1 bit of control per attacker) or slightly worse. Therefore, even if the VDF fails, it will not break the protocol, but it will break applications or any new protocol features that strongly depend on it.
How does it interact with the rest of the roadmap?
VDFs are a relatively self-contained component of the Ethereum protocol, and in addition to increasing the security of proposer selection, they have applications in (i) on-chain applications that rely on randomness and (ii) cryptographic mempools, although making cryptographic mempools based on VDFs still requires additional cryptographic discoveries that have not yet happened.
An important point to remember is that given the uncertainty in the hardware, there will be some "headroom" between when the VDF output is produced and when it is needed. This means that the information will be available several blocks earlier. This can be an acceptable cost, but should be considered in single-slot finalization or committee selection designs.
Obfuscation and One-Time 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 noted 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 want is a transparent virtual computer whose data and computations cannot be shut down, censored, or tampered with, and privacy is not a goal, then blockchains can achieve this goal, albeit with limited scalability.
If privacy is the goal, then until recently we’ve only been able to develop a few specific protocols for specific applications: digital signatures for basic authentication, ring signatures and linkable ring signatures for raw anonymity, identity-based cryptography for more convenient cryptography under certain assumptions about trusted issuers, blind signatures for Charm-style electronic cash, and so on. This approach requires a lot of work for each new application.
In the 2010s, we got our first glimpse of a different and more powerful approach, one based on programmable cryptography. Rather than 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 claims about data they hold, and the proofs are (i) easily verifiable, and (ii) do not reveal any data other than the claims themselves. This is a huge step forward in both privacy and scalability, and I liken it to the impact of transformers in artificial intelligence. Thousands of man-years of application-specific work were suddenly replaced by this general solution that could handle an unexpectedly wide range of problems.
However, ZK-SNARKs are only the first of three similar extremely powerful general primitives. These protocols are so powerful that when I think about them, they remind me of a set of extremely powerful cards in Yu-Gi-Oh! — the card game and TV show I played as a kid: the Egyptian God Cards.
The Egyptian God Cards are three extremely powerful cards whose legend has it that the process of creating them can be fatal, and whose power is such that their use is forbidden in duels. Similarly, in cryptography, we also have this set of three Egyptian God protocols:
What are ZK-SNARKs and how do they work?
ZK-SNARKs is one of the three protocols we already have, with a high level of maturity. Over the past five years, the dramatic improvements in prover speed and developer friendliness have made ZK-SNARKs a cornerstone of Ethereum's scalability and privacy strategy. But ZK-SNARKs have an important limitation: you need to know the data to prove it. Each state in a ZK-SNARK application must have a unique "owner" who must be present to approve reads or writes to that state.
The second protocol that does not have this limitation is fully homomorphic encryption (FHE), which allows you to perform any computation on encrypted data without ever seeing the data. This allows you to perform computations on the user's data, in the interests of the user, while keeping the data and the algorithm private.
It also enables you to scale voting systems like MACI to get almost perfect security and privacy guarantees. FHE was long considered too inefficient for practical use, but now it’s finally efficient enough to start seeing real-world applications.
Cursive is an application that leverages two-party computation and fully homomorphic encryption (FHE) for privacy-preserving common interest discovery.
However, FHE also has its limitations: any technology based on FHE still requires someone to hold the decryption key. This can be an M-of-N distributed setup, and you can even add a second layer of protection using trusted execution environments (TEEs), but it’s still a limitation.
Next up is the third protocol, which is even more powerful than the first two combined: indistinguishability obfuscation. While the technology is still far from mature, as of 2020 we have theoretically valid protocols based on standard security assumptions, and have recently started to work on implementations.
Indistinguishable obfuscation allows you to create a "cryptographic program" that performs arbitrary computations while hiding all the internal details of the program. As a simple example, you can put your 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 this program to sign any prime number, but they won't be able to extract the key. However, its capabilities go far beyond this: combined with hashing, it can be used to implement any other cryptographic primitives, and more.
The only thing that indistinguishable obfuscation programs cannot do is prevent themselves from being copied. However, for this, there is a more powerful technology waiting in the foreground, although it relies 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 needs to be guaranteed by the blockchain is censorship resistance. These techniques can not only make Ethereum itself more secure, but also enable more powerful applications to be built on it.
To better understand how these primitives add additional 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 for ourselves by requiring designs that can handle arbitrary voting protocols: quadratic voting, pairwise restricted quadratic funding, cluster-matched quadratic funding, and so on. In other words, we want the "counting" step to be an arbitrary procedure.
First, assume that 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 counting rules and eligibility rules) and censorship resistance (people cannot be stopped from voting). But we don't have privacy.
Then we add ZK-SNARKs, and now we have privacy: every 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 a decryption key of a central server. The central server is responsible for the vote counting process, including removing duplicate votes, and publishing the ZK-SNARK proof results. This preserves the previous guarantees (even if the server cheats!), but if the server is honest, it also adds a guarantee of resistance to coercion: users cannot prove how they voted, even if they wanted to. This is because while users can prove their vote, they cannot prove that they did not vote to cancel that vote. This prevents bribery and other attacks.
We run the vote count in FHE and then do an N/2-of-N threshold decryption calculation. This brings the resistance to coercion guarantee to N/2-of-N instead of 1-of-1.
We obfuscate the vote count and design the obfuscation program so that it can only output results if authorized, either by proof of blockchain consensus, some kind of proof of work, or a combination of both. This makes the resistance to coercion almost perfect: in the case of blockchain consensus, 51% of validators collude to break it; in the proof of work case, even if everyone colludes, it will be extremely expensive to recount the votes with a different subset of voters to try to extract a single voter. We can even have the program make small random adjustments to the final vote count to make it even harder to extract the behavior of individual voters.
We added one-time signatures, a primitive that relies on quantum computing and allows signatures to be used only once for a specific type of information. This makes the anti-coercion guarantee truly perfect.
Indistinguishable obfuscation also supports other powerful applications. For example:
1. Decentralized Autonomous Organizations (DAOs), on-chain auctions, and other applications with arbitrary internal secret states.
2. A truly universal trusted setup: someone can create an obfuscated program that contains 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 program3 into itself, combining the program's pre-key and their own key, thereby extending the setup. This can be used to generate a 1-of-N trusted setup for any protocol.
3. Verification of ZK-SNARKs requires only one signature: Implementing this is pretty straightforward: set up a trusted environment and have someone create an obfuscator that will only sign messages with a key if a valid ZK-SNARK is present.
4. Encrypted mempools: It becomes trivial to encrypt transactions so that they can only be decrypted if some future on-chain event occurs. This can even include successfully executed verifiable delay functions (VDFs).
With one-time signatures, we can make blockchains immune to 51% attacks with finality reversal, though censorship attacks are still possible. Primitives like one-time signatures make quantum money possible, solving the double-spending problem without a blockchain, though many more complex applications still require a chain.
If these primitives can be made efficient enough, then most of the world's applications can be decentralized. The main bottleneck will be verifying the correctness of the implementation.
Here are some links to existing research:
1. Indistinguishability Obfuscation Protocol (2021): Indistinguishability Obfuscation
2. How Obfuscation Can Help Ethereum: How Obfuscation Can Help Ethereum
3. First Known Construction of One-Shot Signatures: First Known Construction of One-Shot Signatures
4. Attempted Implementation of Obfuscation (1): Attempted Implementation of Obfuscation (1)
5. Attempted Implementation of Obfuscation (2): Attempted Implementation of Obfuscation (2)
What more work is there to do, and what are the trade-offs?
There is still a lot of work to be done, indistinguishable obfuscation is still very immature, and candidate constructions run as slow as (if not more) to be useful in applications. Indistinguishable obfuscation is famous for being "theoretically" polynomial time, but in practice its running time can be longer than the lifetime of the universe. Recent protocols have alleviated this running time, but the overhead is still too high for routine use: one implementer estimates a running time of a year.
Quantum computers don't even exist yet: all the constructions you see on the Internet are either prototypes that can't do more than 4-bit operations, or they are not substantial quantum computers at all, and while they may have quantum parts, they can't run meaningful calculations like Shor's algorithm or Grover's algorithm. There are recent signs that "real" quantum computers are not far away. However, even if "real" quantum computers appear soon, it may be decades before ordinary people can use quantum computers on their laptops or phones, until the day when powerful institutions can break elliptic curve cryptography.
For indistinguishable obfuscation, a key trade-off lies in security assumptions, and there are more aggressive designs that use special assumptions. These designs often have more realistic running times, but the special assumptions can sometimes end up being broken. Over time, we may understand lattices better and come up with assumptions that are less prone to breaking. However, this path is more risky. A more conservative approach would be to stick with protocols whose security provably reduces to "standard" assumptions, but this may mean it takes longer to get protocols that run fast enough.
How does it interact with the rest of the roadmap?
Extremely powerful cryptography could completely change the game, for example:
1. If we get ZK-SNARKs to be as easy to verify as signing, then we may not need any aggregation protocols anymore; we can do verification directly on-chain.
2. One-time signatures could mean more secure proof-of-stake protocols.
3. Many complex privacy protocols could potentially be replaced with just a privacy-preserving Ethereum Virtual Machine (EVM).
4. Encrypted mempools become easier to implement.
Initially, the benefits will be at the application layer, as Ethereum’s L1 inherently needs to be conservative in its security assumptions. However, application layer usage alone could be disruptive, as was the advent of ZK-SNARKs.
Disclaimer: The content of this article solely reflects the author's opinion and does not represent the platform in any capacity. This article is not intended to serve as a reference for making investment decisions.
You may also like
BTC breaks through $94,000
The ZKasino project borrowed 12.38 million DAI from Aave again in the past 2 hours to go long on ETH
MicroStrategy founder reiterates he will not sell BTC
Bitcoin Frontier Fund to Invest in Teams Building on sBTC
Trending news
MoreCrypto prices
More
