Vitalik 2023 First Reddit AMA 12 Questions 12 Answers

The Way of DeFi
2023-01-14 11:22:58
Collection
On January 11, members of the Ethereum Foundation (EF) research team held the ninth AMA on Reddit. This article excerpts Vitalik's responses to community questions.

Original Title: "V God 2023 First Reddit AMA 12 Questions 12 Answers"
Original Source: Reddit
Original Compilation: The Way of DeFi

On January 11, members of the Ethereum Foundation (EF) research team held the ninth AMA on Reddit. This was also the first AMA of 2023. Ethereum founder Vitalik Buterin, Ethereum Foundation 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 questions.

image

1. Essentially, is canceling sharding and sticking to only implementing EIP-4844 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 rollup combinations 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 ultimately need actual danksharding.

Mathematically, it calculates as follows:

Currently, on L1, Ethereum can support 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 of rollups, ERC20 transfers could reach 262144 / 12 / 154 = 141 TPS.

If we expand EIP-4844 over time to more aggressive parameters, aiming for 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 a day on average, we only need to reach 1157 TPS, so the capacity given above even gives us some breathing room to sacrifice scalability to enhance privacy and other aspects. However, if we want to reach a level of usage that is more common among consumers, we will need to increase capacity by 1-2 orders of magnitude.

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

The temporary focus on the benefits of rollups and EIP-4844 is that 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 people push hard for 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 large 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 of sharding plans 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 "reactive" protocols/roadmaps are:

  1. New types of attacks and changes in the incentive environment (e.g., MEV)

  2. New features 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 rate of discovery 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, stupid thing that everyone can easily understand and agree on its use: accept transactions from anyone, include them on the chain indiscriminately if they pay a fee, 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:

In general, we should definitely be more cautious about making changes to the EVM. I actually don't believe that the Ethereum ecosystem will bear particularly high costs due to "having an inefficient VM": the only place where sufficient EVM computation becomes an issue is in EVM-internal encryption, for which we can always precompile specific forms of computation that are common and worth using. We have already done this for pairing and other elliptic curve operations.

Therefore, in my view, "no longer changing the EVM literally" 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 if new versions of code are created. Additionally, any new EVM features (especially precompiles) should be carefully designed with consideration of the costs of ZK-SNARK implementation.

One completely different route we could take is to eventually transition from the EVM to some ZK-friendly EVM, like Cairo. 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 not to take any irreversible steps that lock us into long-term complexity that we might regret later. Trying to switch to little-endian byte order was a disaster, and we should learn from that and not do such things again in the future.

5. With EIP-4844, how do you verify the next transaction if 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 about as long as Ethereum's weak subjectivity period and is longer than the week-long 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, e.g., based on IPFS or other means, 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 do not have easy access to cryptocurrency exchanges to use.

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 maintains censorship resistance or it is meaningless.

But at the application layer, this approach becomes less practical, both because for many ordinary users, using banned privacy solutions poses too much legal risk, and 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 "tainted" 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 some known "bad" deposit list (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 anonymous set of hackers could default drop by 95%+ (while merely controversial but not obviously bad actors might see their anonymity drop by 30-70%, but this still leaves them with a lot of privacy).

Another option is to connect ZK-SNARKs 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 untapped trade-off space between privacy and verification, and we should explore the entire space.

7. From the latest "roadmap" released by Vitalik a few months ago, pick 1 or 2 key features or upgrades (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?

In particular, 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 rollup to enter the first phase of takeoff training wheels.

  • 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. How do you view the developments in the zero-knowledge space since the invention of the PLONK protocol/proof system (2019)?

Is it a bit 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 the entire design space for certain applications.

Vitalik:

I absolutely hope for more work on ZK programming languages. More publicly opening up 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 advancements in moon math cryptography have you been most excited about?

Vitalik:

I hope we can get 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 they will become a truly important part of the stack when quantum computers become available or are seen as a more direct threat in the future. In particular, they are one of the few primitives that can be used for post-quantum encryption (zero-knowledge proofs can only be done with hashes, which is not encryption in the same sense; there is even evidence that you can 'make 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. However, 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 everything feel like it's on one chain?

Vitalik:

I think over time, I actually increasingly disagree with this. For a new blockchain community to succeed at this point, it actually has to offer users a very novel and unique concept that distinguishes it from other products. 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 treat Bitcoin, Ethereum, Cosmos, and… different ecosystems just like they do with Twitter, Facebook, etc.

11. To what extent do 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 currently held by MakerDAO/DAI (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 issue in their L2 chains.

ChainCatcher reminds readers to view blockchain rationally, enhance risk awareness, and be cautious of various virtual token issuances and speculations. All content on this site is solely market information or related party opinions, and does not constitute any form of investment advice. If you find sensitive information in the content, please click "Report", and we will handle it promptly.
ChainCatcher Building the Web3 world with innovators