Twelve Questions to Vitalik: Strongly supports more decentralized stablecoins, EIP-4844 and Rollup can temporarily solve the scalability issue

Source: Reddit

Compiled by: Kyle, DeFi Path

On January 11, members of the Ethereum Foundation (EF) research team held their ninth AMA on Reddit. This was also the first AMA of 2023. Ethereum founder Vitalik Buterin, EF researchers Danny Ryan, Dankrad Feist, Justin Drake, Domothy, and others participated online to answer questions from community members. This article excerpts Vitalik's responses to community inquiries.

1. Is canceling sharding and sticking to implementing only EIP-4844 essentially a simple and efficient data availability tool?

Vitalik: In the short term, I believe that the rollout of EIP-4844 and the first phase of rollups will be sufficient for us to "temporarily solve" the scalability issue, allowing us to take a breather and focus on other (L1 and ecosystem) challenges. However, in the long run, I do think we will eventually need actual danksharding.

Mathematically, it calculates as follows:

Currently, on L1, Ethereum can support transfers of 15000000 / 12 / 21000 = 59.5 ETH or about 15000000 / 12 / 50000 = 25.0 ERC20 tokens per second.

With the initial EIP-4844 parameters and basic compression for rollups, ERC20 transfers could reach 262144 / 12 / 154 = 141 TPS.

If we expand EIP-4844 over time to more aggressive parameters, targeting a block size of 1 MB, it would increase to 567 TPS.

If rollups add optimal compression (with each ERC20 transfer size being 23 bytes), it could reach up to 3799 TPS.

This has been sufficient for quite a while: if there are 100 million users and each user makes one transaction per day on average, we only need to reach 1157 TPS, so the capacity given above even provides us some breathing room to sacrifice scalability for improvements in privacy, etc. However, if we want to reach a higher level of usage for ordinary consumers, we will need to increase capacity by 1-2 orders of magnitude.

One noteworthy point is that "using DAS vs. not using DAS" is a spectrum rather than binary. For example, having a relatively large proportion of nodes directly downloading and some enthusiasts doing DAS is a perfectly reasonable architecture. This hybrid architecture could even make the P2P network more stable and reduce the worst risks associated with DAS failures while still being user-friendly.

The temporary focus on rollups and EIP-4844 is beneficial as it can be forward-compatible with various possible futures.

2. After enabling staking withdrawals and launching EIP-4844, what parts of the roadmap do you hope Ethereum developers will continue to focus on?

Vitalik: Wallet security (especially through account abstraction introduced by ERC-4337) and privacy (ZK privacy solutions and stealth addresses) are two major non-scaling related issues that I think are important.

Additionally, I hope to see strong pushes towards reducing the costs of the verification chain (this is a "fringe" topic). In the short term, this can be achieved through stateless clients/verkle trees, which can enable instant basic synchronization and eliminate the need for a large amount of disk storage to verify the chain. In the long run, we can eliminate computational costs and reduce data costs through ZK-SNARK verification of the entire protocol and data availability sampling (DAS).

3. Some significant changes we've seen in the roadmap over the years have been driven by unforeseen external factors. For example, the invention of rollups made the execution sharding plan redundant, and the emergence of MEV optimization as an industry led Ethereum to abandon the idea of allowing anyone to easily build competitive blocks, instead embracing things like PBS. Is a rigid protocol secure, or will the world continue to throw curveballs at it, necessitating changes?

Vitalik: The two main pressures driving the redesign of a "reactive" protocol/roadmap are:

• New types of attacks and changes in the incentive environment (e.g., MEV)
• New functionalities provided by more centralized solutions or other chains or other things that Ethereum must adapt to in some way to provide "competition"

I personally hope that (1) will decrease over time. The essence of every ecosystem I know is that the discovery rate of new attacks declines. Perhaps the best rebuttal to this optimism is that pure technology (e.g., hash functions) is correct, but social systems are not (e.g., democracy, which needs to work hard to adapt to today's social media, tomorrow's AI, bio-enhancements, or uploading humans after several generations…).

One way to consider this rebuttal is that if we want the stability of blockchains to resemble the first rather than the second, the simplicity of the attributes they provide needs to resemble the first rather than the second. A concrete example might be the idea that Ethereum should provide oracles (e.g., prices) within the protocol. Make it a simple, dumb thing that everyone can easily understand and agree on its use: accept transactions from anyone who pays a fee, include them on-chain indiscriminately, and execute them according to the EVM.

4. Given that zkEVM seems to be the endgame, how should we consider modifications to the EVM?

Vitalik: Generally speaking, we should absolutely be more cautious about making changes to the EVM. I actually do not believe that the Ethereum ecosystem will incur particularly high costs due to "having an inefficient VM": the only place where EVM computation becomes a problem is in EVM-internal encryption, and for that case, we can always precompile specific forms of computation that are common and worth it to use.

We have already completed pairing and other elliptic curve operations. Therefore, in my view, "not changing the EVM literally anymore" is an underestimated path (I personally do not advocate for this path, but I do think that if we take this path, the outcome won't be that bad).

However, if we do change the EVM, I personally strongly advocate for how we do it and strive to reduce the overall complexity of the EVM over time. For example, as we create new versions, requiring the EVM implementation to become increasingly complex over time is unacceptable to me.

This is the inspiration behind the EOF changes I proposed, which would make upgrading existing on-chain code easier when creating new versions of code. Additionally, any new EVM features (especially precompiles) should be carefully designed with consideration of the costs of ZK-SNARK implementations.

One completely different route we could take is to eventually transition from the EVM to some ZK-friendly EVM, like Cairo. The existing EVM code would be replaced by execution from an EVM interpreter written in Cairo. However, at this point, this is all quite long-term speculation.

I think the most important thing right now is to avoid taking any irreversible steps that lock us into long-term complexities we might regret later. Trying to switch to little-endian byte order was a disaster, and we should learn from that not to do such things in the future.

5. With EIP-4844, how do you verify the next transaction if the data is deleted after a month? Do you think that in the future, when rollups can handle thousands of transactions per second, some of them might offer free tiers? For example: the first 10 transactions on Optimism are free.

Vitalik:

Question 1: I think this issue is generally overstated. A month is roughly as long as Ethereum's weak subjectivity period and is longer than the one-week fraud proof period used by rollups. Therefore, even under extreme conditions, those who need the data can reliably obtain it, which is far beyond the shortest time recognized by society.

There will be other protocols, such as those based on IPFS or others, that can easily store historical chains, and many entities will independently create complete archival copies of it.

Question 2: In fact, I think this is a great use case for something like UBI Coin. Unfortunately, these projects cannot achieve economic scale to provide people with enough coins to cover food and healthcare costs, especially if they truly succeed in scaling to millions, but they will be able to provide UBI large enough to cover people's transaction fees. This could make Ethereum's non-financial applications (like ENS, SIWE, POAP) easier for many people around the world who cannot easily access cryptocurrency exchanges.

6. Are there any plans to address the censorship of Tornado Cash?

Vitalik: I do believe that privacy and the Tornado Cash issue have another important layer, which is the application layer. At the protocol layer, I think it is correct for the ecosystem to stubbornly play to the extreme, essentially saying that it either remains censorship-resistant or it is meaningless.

But at the application layer, this approach becomes less practical, both because for many ordinary users, using banned privacy solutions carries too much legal risk, and also because even if users are willing to take those risks or are in jurisdictions where they are legally safe, if anything from privacy-preserving systems is treated as "contaminated" by default, third-party services (like exchanges) will still create difficulties for them.

Therefore, at the application layer, compromising and trying to more actively commit to privacy solutions that do not introduce centralized backdoors has greater value, while also making it harder for large-scale hackers to participate. The benefit of ZK-SNARK technology is that it offers many options!

One simple option is that those withdrawing from ZK-SNARK mixers can provide additional evidence to prove that their withdrawal deposits do not come from any known "bad" deposit lists (e.g., known hackers), without revealing any other information about the deposits.

The ability to do this can be integrated into contracts (reducing the number of on-chain proofs from 2 to 1) and integrated into the UI to make it the default setting, in which case the hacker's anonymity set could drop by 95%+ by default (while only controversial but not obviously bad actors might see their anonymity drop by 30-70%, but that still leaves them with a lot of privacy).

Another option is to connect ZK-SNARK to some kind of proof-of-humanity system, so that each verified unique human can "cleanly" withdraw up to $N (e.g., $N = $5000) anonymously each month without providing any further evidence. A third, more restrictive option is a privacy system whose participation is more limited to specific communities.

ZK-SNARKs provide a huge and underexplored trade-off space between privacy and verification that we should explore across the entire space.

7. Pick 1 or 2 key features or upgrades from the latest "roadmap" Vitalik published a few months ago (see here for a quick compilation I put together for reference: dropbox link to the compiled Ethereum roadmap chart) ------ What are the key tasks to be completed in the next few years? Specifically, it would be helpful to understand if there are strong disagreements among Ethereum Foundation researchers on this issue.

Vitalik: My current rough priority list is:

• Complete the "basic rollup scaling" project in The Surge phase. This requires (1) EIP-4844, and (2) EVM-equivalent rollups to enter the first phase of takeoff training.
• Improve wallet security (especially through ERC-4337 account abstraction) and commit to adding more and better privacy solutions.
• The Verge, at least to the level where ordinary users (even validators!) can run stateless clients.
• Single-slot finality, generally cleaning up and simplifying consensus.
• Others.

8. Since the invention of the PLONK protocol/proof system (2019), how do you view the developments within the zero-knowledge space? Is it somewhat surprising that Circom is still widely adopted when we have PLONK arithmetic that allows us (theoretically) smaller proof and verification times? I feel this opens up an entire design space for certain applications.

Vitalik: I absolutely hope for more work on ZK programming languages. More openness about internal structures to help people do this is one of my motivations for trying to complete my own PLONK implementation task. We need more tools to help people write circuits and verify circuits; we should reach a point where verifying a verification key on etherscan is as easy as verifying solidity code today.

9. What recent developments in moon math cryptography have you been most excited about?

Vitalik: I hope we can gain a bunch of exciting new primitives through lattice cryptography.

My blog post on fully homomorphic encryption details how lattice cryptography works and should provide an intuition for why lattices can do a whole bunch of things that other cryptographic primitives cannot. They are surprisingly simple in some ways, and the way lattice operations rely on "linear" operations allows them to stack and combine in powerful ways.

Lattices are also quantum-resistant, so when quantum computers become available or are seen as a more direct threat in the future, they will become a truly important part of the stack. In particular, they are one of the few primitives available for post-quantum cryptography (zero-knowledge proofs can only be done with hashes, not in the same sense as encryption; there is even evidence that you can create public-key encryption that requires more than quadratic complexity to break using only hashes).

10. For ordinary people, wallets are the main entry point to Web3 and Ethereum. But for adoption rates to rise, they shouldn't have to care about the underlying chain. In the rollup paradigm, is there a feasible way to completely abstract all bridging and chain switching from users and make it feel like everything is on one chain?

Vitalik: I think over time, I actually increasingly disagree with this. A new blockchain community must offer users a very novel and unique concept that distinguishes it from other products to succeed at this point. Bitcoin and Ethereum are very different from each other, and users do need to care about those differences.

Individual Cosmos chains may generally be similar, but Cosmos as an ecosystem is very different, and individuals must care about the distinctions between it and the Ethereum ecosystem. I increasingly believe that chains that try to be indistinguishable from ordinary users will be overlooked and fail, and users will view Bitcoin, Ethereum, Cosmos, and… different ecosystems just as they do Twitter, Facebook, etc.

11. To what extent have centralized stablecoins become a medium for attacks?

Vitalik: I absolutely strongly support more decentralized alternatives to current stablecoins. Please see my recently published article for my classification of three types of stablecoins. The "fully decentralized" RAI-style approach and a better version of the hybrid approach that MakerDAO/DAI currently has (MakerDAO itself is currently very actively formulating its ongoing improvement strategy) are both interesting to me.

12. Can ZK rollups reduce/eliminate MEV? If so, how?

Vitalik: Not really, ZK rollups are addressing the verification problem, not the transaction inclusion or ordering problem. They are different issues. Although ZK rollup projects can certainly decide to include other technologies to try to better address the MEV problem within their L2 chains.