Vitalik's latest AMA: Strong support for more decentralized stablecoins, focus on wallet security and privacy
Original source:Reddit
Original source:
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.
text
Vitalik：1. In essence, is unsharding and sticking to EIP-4844 only a simple, efficient tool for data availability?
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 ERC 20 tokens per second.
With initial EIP-4844 parameters and a rollup using basic compression, ERC 20 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 (23 bytes per ERC 20 transfer size), 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.
The benefit of focusing on rollup and EIP-4844 for the time being is that it is forward compatible with every possible future.
text
Vitalik：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?
Also, I'd like to see a big push to reduce the cost of validating the chain (this is a "marginal" 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).
text
Vitalik：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?
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"
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.
text
Vitalik：4. Given that zkEVM seems to be the end game, how should we think about EVM modifications?
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 within the 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 stop changing the EVM" is an underrated path in my opinion (I personally don't subscribe to this path, but I do think that if we go this path, the result will not be so bad).
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.
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.
text
Vitalik：
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.
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.
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.
text
Vitalik：6. What are the plans to address Tornado Cash censorship?
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).
ZK-SNARKs offer a large and unexplored space of trade-offs between privacy and verification, and we should explore the entire space.
text
Vitalik：7. Pick 1 or 2 key features or upgrades from the latest "roadmap" published by Vitalik a few months ago (see here for reference what I quickly put together: dropbox link to compiled Ethereum roadmap diagram) ——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.
My personal current rough priority list is:
Complete the "Basic rollup expansion" project in The Surge phase. This requires (1) EIP-4844, and (2) an EVM equivalent rollup to get to 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.
other
other
text
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.
text
Vitalik：9. What is the latest development in lunar mathematical cryptography that excites you most recently?
I hope we get a bunch of exciting new primitives from lattice cryptography.
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 are one of the very few primitives that can be used for post-quantum encryption (zero-knowledge proofs, which can only be done with hashes, are 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).
text
Vitalik：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?
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.
text
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 developing its continuous improvement strategy) are interesting to me.
text
Vitalik：12. Can ZK rollup reduce/eliminate MEV? What if so?
