Original post: Reddit , compiled by Tao of DeFi.
On January 11, members of the Ethereum Foundation (EF) research team conducted their ninth AMA on Reddit. It will also be the first AMA of 2023. Ethereum founder Vitalik Buterin, Ethereum Foundation researcher Danny Ryan, Dankrad Feist, Justin Drake, Domothy and others participated online to answer questions from community members. This article is an excerpt of Vitalik's answers to community questions.
Image Credit: Generated by Maze AI
1. In essence, is unsharding and sticking to EIP-4844 only a simple, efficient tool for data availability?
vitalik:
In the short term, I think the rollout of EIP-4844 and phase 1 of the rollups mix will be enough to give us a "temporary fix" to scaling , allowing us to relax and focus on other (L1 and ecosystem) challenges. However, in the long run, I do think we will eventually need actual Danksharding.
Mathematical calculation is as follows:
Currently on L1, Ethereum can support transfers of 15000000 / 12 / 21000 = 59.5 ETH or approximately 15000000 / 12 / 50000 = 25.0 ERC20 tokens per second.
With initial EIP-4844 parameters and a Rollup using basic compression, ERC20 transfers will be able to reach 262144 / 12 / 154 = 141 TPS.
If we scale EIP-4844 to more aggressive parameters over time, targeting a block size of 1 MB per block, it increases to 567 TPS.
If Rollup adds optimal compression (each ERC20 transfer size is 23 bytes), it can reach up to 3799 TPS.
That's enough for quite some time: if there are 100 million users, and each user makes an average of one transaction per day, that only needs to hit 1157 TPS, so the capacity given above even gives us some breathing room To sacrifice scalability to improve privacy and other aspects. However, if we want to reach general consumer usage at higher levels, then we will need to increase capacity by another 1-2 orders of magnitude.
One thing worth noting is that "with DAS vs. without DAS" is a spectrum and not binary. For example, it is perfectly reasonable to have an architecture with a sizable percentage of nodes downloading directly and some amateurs doing DAS. This hybrid architecture might even make the P2P network more stable and reduce the worst-case risk of DAS failure, while still being user-friendly.
The benefit of focusing on Rollup and EIP-4844 for the time being is that it is forward compatible with every possible future.
2. After enabling staking withdrawals and rolling out EIP-4844, what parts of the roadmap do you want Ethereum developers to continue to focus on?
Vitalik:
Wallet security (specifically the account abstraction introduced via ERC-4337) and privacy (ZK privacy solutions and stealth addresses) are the two main non-scaling related concerns in my opinion.
Also, I'd like to see a big push to reduce the cost of validating the chain (this is a "fringe" topic). In the short term, this can be done with a stateless client/verkle tree, which enables instant basic synchronization and eliminates the need for massive disk storage to verify the chain, and in the long term, we can eliminate computational costs, as well as ZK-SNARK verification of the entire protocol, and data cost reduction through Data Availability Sampling (DAS).
3. Some of the major changes we have seen in roadmaps over the years have been driven by unplanned external factors. For example, the invention of rollups made executing a sharding plan redundant, and the emergence of MEV optimization as an industry made Ethereum abandon the idea of making it easy for anyone to build competitive blocks in favor of something like PBS . Is the rigid protocol safe, or will the world continue to throw curveballs at it, meaning we have to change it?
Vitalik:
The two main pressures driving a "reactive" protocol/roadmap redesign are:
- New types of attacks and new changes to the incentive environment (e.g. MEV)
- New features provided by more centralized solutions or other chains or something, ethereum has to adapt somehow to provide "competition"
My personal hope is that (1) will decrease over time. The nature of every ecosystem I know of is a decline in the discovery rate of new attacks. Perhaps the best counter-argument to this optimism is that pure technology (e.g. hash functions) is true, but social systems are not (e.g. democracy, which requires hard work to accommodate today's social media, tomorrow's artificial intelligence, bioaugmentation Or upload humans a few generations later...).
One way to think about this counterargument is that if we want the stability of blockchains to be more like the first than the second, then the simplicity of the property they provide needs to be more like the first than the second. A concrete example might be that it opposes the idea that Ethereum should provide an in-protocol oracle (e.g. price). Make it a simple dumb thing that everyone can easily understand and agree on what it's for: accept transactions from anyone, if they pay a fee, include them on-chain without discrimination, and execute them.
4. Given that zkEVM seems to be the end game, how should we think about EVM modifications?
Vitalik:
In general, we should definitely be more careful about making changes to the EVM. I don't actually believe that the Ethereum ecosystem incurs a particularly high cost of "having an inefficient VM": the only place where enough EVM computation happens to be a problem is in-EVM encryption, for which case we can always Precompiled for specific forms of computation that are so common that it's worth it. We've done pairing and other elliptic curve operations. So "literally no more changes to the EVM" is an underrated path in my opinion (I personally don't subscribe to this path, but I do think the results won't be so bad if we go this path).
However, if we do change the EVM, I personally strongly favor how we do it and try to reduce the overall complexity of the EVM over time. For example, it is unacceptable to me to require the EVM implementation to become more complex over time as we create new versions. This was the inspiration for my proposed EOF change, which would make it easier to upgrade existing on-chain code if new code versions are created. Additionally, any new EVM functionality (especially precompilation) should be carefully designed with ZK-SNARK implementation costs in mind.
A completely different route we could take is to eventually move from the EVM to some ZK-friendly EVM like Cairo. Existing EVM code will be replaced by the execution of the EVM interpreter written in Cairo. At this point, though, it's all pretty long-term speculation.
I think the most important thing right now is not to take any irreversible steps that lock us into long-term complications that we may later regret. Trying to switch to little-endian was a disaster, and we should learn from it and never do something like this again.
5. Using EIP-4844 If the data is deleted after one month, how to verify the next transaction?
Do you think some of them might offer a free tier in the future when rollups can handle thousands of transactions per second? Example: On Optimism, the first 10 trades are free.
Vitalik:
Problem one: I think this problem is generally overstated. A month is about as long as Ethereum's weak subjective period, and longer than the one-week fraud proof period used by rollups. As a result, those who need data will have reliable access to it, even under extreme conditions, well beyond socially acceptable minimum times.
There will be other protocols, eg. Based on IPFS or otherwise, the chain of history can be easily stored, and many entities will independently make full archived copies of it.
Question two: Actually, I think this is a good use case for something like UBI Coin. In practice, unfortunately, these projects won't be able to reach the economies of scale that will provide people with enough coins to pay for food and healthcare, especially if they actually manage to scale to millions of people, but they will be able to provide UBI large Enough to cover people's transaction fees. This could make Ethereum non-financial applications (e.g. ENS, SIWE, POAP) more accessible to many people around the world who do not have easy access to cryptocurrency exchanges.
6. What are the plans to address Tornado Cash censorship?
Vitalik:
I do think there is another important layer to the privacy and Tornado Cash issue, which is the application layer. At the protocol layer, I think the ecosystem is right to take its stubbornness to the extreme, basically saying that either it remains censorship resistant or it doesn't make sense at all. But at the application layer, this becomes less practical, both because the legal risk of using a banned privacy solution is too great for many ordinary users, and because even if the user is willing to take those risks or the user is in the In jurisdictions that are legally safe, third-party services (such as exchanges) can still create difficulties for them if anything from a privacy-preserving system is considered “tainted” by default.
Therefore, at the application layer, without introducing centralized backdoors, there is greater value in compromising and trying to work more aggressively on privacy solutions that simultaneously make it harder for large-scale hackers to participate. The great thing about ZK-SNARK technology is that it has a lot of options!
A simple option is that people withdrawing from ZK-SNARK mixers can provide additional evidence that the deposits they withdraw are not from some known list of "bad" deposits (e.g., known hackers) without revealing Any other information about the deposit. The ability to do this could be integrated into the contract (reducing the number of on-chain proofs from 2 to 1), and into the UI to make it the default, in which case the hacker's anonymity set could drop by 95% by default + (whereas molecules that are merely controversial and not obviously bad may see their anonymity set drop by 30-70%, but that 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" anonymously withdraw up to $N per month (e.g. $N = $5000) without providing any further evidence. A third, more restrictive option is a privacy system, where participation is more limited to specific communities.
ZK-SNARKs offer a large and unexplored space of trade-offs between privacy and verification, and we should explore the entire space.
7. Pick 1 or 2 key features or upgrades from the latest "roadmap" that Vitalik published a few months ago (see here for reference what I quickly put together: dropbox link to compiled Ethereum roadmap chart) ——What are the key tasks to be accomplished in the next few years?
In particular, it would be helpful to know whether Ethereum Foundation researchers are strongly divided on this issue.
Vitalik:
My personal current rough priority list is:
- Complete the "Basic Rollup expansion" project in The Surge phase. This requires (1) EIP-4844, and (2) EVM equivalent Rollup to enter stage 1 of the takeoff training wheels.
- Improve wallet security (especially via ERC-4337 account abstraction) and work on adding more and better privacy solutions.
- The Verge, at least to a level where normal users (and even validators!) can run stateless clients.
- Single-slot finality, generally cleans and simplifies consensus
- other
8. Since the invention of the PLONK protocol/proof system (2019), how do you see developments in the field of zero knowledge?
Isn't it a bit surprising that Circom is still widely adopted when we have PLONK arithmetization that allows us (theoretically) smaller proof and verification times? I feel like this opens up a whole design space for certain applications.
Vitalik:
I definitely hope there will be more work on the ZK programming language. Exposing the internals more to help people do this was one of my motivations for trying to complete my own PLONK implementation. We need more tools to help people write circuits, verify circuits; we should get to the point where we can verify a verification key on etherscan as easily as we verify solidity code today.
9. What is the latest development in lunar mathematical cryptography that excites you most recently?
Vitalik:
I hope we get a bunch of exciting new primitives from lattice cryptography.
My blog post on fully homomorphic encryption details how lattice cryptography works, and should give an intuition as to why lattice can do a whole bunch of things that other cryptographic primitives can't. They are surprisingly simple in some ways, and the way lattice operations rely on "linear" operations allows them to be stacked and combined with each other in powerful ways.
Lattice is also quantum resistant, so they will be a really important part of the stack in the future when quantum computers become available or are seen as a more immediate threat. In particular, they're one of the very few primitives that can be used for post-quantum cryptography (zero-knowledge proofs, which can only be done with hashes, are not encryption in the same sense; there's even evidence that you can't use only hashes to Make public-key encryption that requires more than quadratic complexity to break).
10. For ordinary people, wallets are the main outlet for Web3 and Ethereum. But for adoption to rise, they don't have to care about the underlying chain.
In the Rollup paradigm, is there a viable way to completely abstract all bridging and chain switching from the user, and make it feel like everything is on one chain?
Vitalik:
I think I actually disagree with that more and more as time goes on. For a new blockchain community to be successful at this point, it actually has to offer users a very new and unique idea that sets it apart from other offerings. Bitcoin and Ethereum are very different from each other and users really have to care about these differences. Cosmos chains may generally be similar, but Cosmos as an ecosystem is very different, and individuals must be concerned with the differences between it and the Ethereum ecosystem. I'm increasingly convinced that chains that try to be indistinguishable from normal users will be ignored and fail, and users will treat Bitcoin, Ethereum, Cosmos, and ... different ecosystems like they do Twitter, Facebook, etc.
11. To what extent are centralized stablecoins an attack vector?
Vitalik:
I absolutely strongly support more decentralized alternatives to current stablecoins. See my recent post for my breakdown of the three stablecoins. Both a "fully decentralized" RAI-style approach and a better version of the hybrid approach that MakerDAO/DAI currently has (MakerDAO itself is currently very active in its strategy for continuous improvement) are interesting to me.
12. Can ZK Rollup reduce/eliminate MEV? What if so?
Vitalik:
Not really, ZK rollups are solving validation problems, not transaction inclusion or ordering problems. They are different questions. Although the ZK Rollup project could of course decide to include other techniques as well in an attempt to better address the MEV problem in its L2 chain.
