header-langage
简体中文
繁體中文
English
Scan to Download the APP
Partnered With:

V God 2023 First Reddit AMA 12 Questions 12 Answers

Read this article in 22 Minutes
On January 11, members of the Ethereum Foundation (EF) research team held their ninth AMA on Reddit. Here are excerpts from Vitalik's responses to community questions.
Original title: V God 2023 First Reddit AMA 12 Questions 12 Answers
Original source: Reddit
The DeFi way


On January 11, members of the Ethereum Foundation (EF) research team held their ninth AMA on Reddit. It will also be the first AMA in 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. Here are excerpts from Vitalik's responses to community questions.


1. In essence, is unsharding and sticking with only IP-4844 a simple and efficient data availability tool?


In the short term, I think. The rollout of IP-4844 and phase 1 of the rollups combo will be enough to "fix" the expansion issues for now, allowing us to relax and focus on the other (L1 and ecosystem) challenges. In the long run, however, I do think we will eventually need actual danksharding.


Mathematically, it is calculated as follows:


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


The ERC20 transfer will be able to reach 262144/12/154 = 141 TPS using the initial EIP-4844 parameter and using the rollup with basic compression.


If we extend EIP-4844 to more aggressive parameters over time, aiming for a block size of 1 MB per block, then it increases to 567 TPS.


Up to 3799 TPS if rollup adds optimal compression (23 bytes per ERC20 transfer).


That's enough for quite some time: with 100 million users and an average of one transaction per user per day, that only needs to be up to 1,157 TPS, so the capacity given above even gives us some breathing room to sacrifice scalability for things like privacy. However, if we want to reach average consumer usage at a higher level, then we will need to increase the capacity by another 1-2 orders of magnitude.


One thing to note is that "Use DAS vs. Don't use DAS" is a spectrum and not a binary. For example, it makes perfect sense to have a fairly large percentage of nodes directly downloading and some amateurs doing the DAS architecture. This hybrid architecture might even make P2P networks more stable and reduce the worst risks of DAS failure, while still being user friendly.


The benefit of focusing on rollup and IP-4844 for the time being is that it is forward compatible with all possible futures.


2. What parts of the roadmap do you want Ethereum developers to continue to focus on after enabling pledged withdrawals and launching IP-4844?


Vitalik:Wallet security (specifically account abstraction introduced through the ERC-4337) and privacy (ZK privacy solution and incognito address) are two of the major non-extension-related issues that I see.


In addition, I would like to see a big push to reduce the cost of verification chains (this is a "marginal" topic). In the short term, this can be done with stateless clients /verkle trees, which allow instant basic synchronization and eliminate the need for large disk storage to validate chains. In the long term, we can eliminate computational costs, as well as by ZK-SNARK validation of the entire protocol. Data cost is also reduced through data availability sampling (DAS).


3. Some of the major changes we've seen in the roadmap over the years have been driven by unplanned external factors. For example, the invention of rollups made executing sharding plans redundant, and the emergence of MEV optimization as an industry allowed Ethereum to abandon the idea of making it easy for anyone to build competitive blocks and embrace something like PBS instead. Is a rigid agreement safe, or will the world continue to throw curve balls at it, meaning we have to change it?


Vitalik:The two main pressures driving the Reactivity protocol/roadmap redesign are:


New attacks and new changes to incentive environments (e.g. MEVs)


New capabilities provided by more centralized solutions or other chains or something, Ethereum has to adapt in some way to provide "competition"


I personally hope that (1) it will decrease over time. The nature of every ecosystem I know is that the discovery rate of new attacks goes down. Perhaps the best rebuttal to this optimism is that pure technology (e.g. hash functions) is true, but social systems are not (e.g. democracy, which needs to work hard to accommodate today's social media, tomorrow's AI, biological augmentation or uploading humans a few generations from now to......). .


One way to think about this rebuttal is that if we want the stability of blockchains to be more like the first than the second, then the simplicity of the properties they offer needs to be more like the first than the second. A concrete example might be its opposition to the idea that Ethereum should provide in-protocol prognosticators, such as prices. Make it a simple silly thing that everyone can easily understand and agree on what it's for: Take anyone's deals, if they pay a fee, include them on the chain without discrimination, and enforce them according to the EVM.


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


Vitalik:In general, we should definitely be more careful about making changes to EVMs. I don't actually believe that the Ethereum ecosystem suffers a particularly high cost of "having an inefficient VM" : the only place where EVM computing occurs enough to be a problem is in EVM encryption, in which case we can always precompile for certain forms of computing that are common enough to merit its use. We've done pairing and other elliptic curve operations. So "Literally no more changes to EVMs" is, in my opinion, an underrated path (I personally disapprove of this path, but I do think the results won't be so bad if we go this route).


However, if we do change EVMs, I personally am strongly in favor of how we do it and try to reduce the overall complexity of EVMs over time. For example, requiring EVM implementations to become more complex over time as we build new versions is unacceptable to me. This was the inspiration for the EOF changes I proposed, which would make it easier to upgrade existing on-chain code if new code versions were created. In addition, any new EVM features (especially precompilation) should be carefully designed with ZK-SNARK implementation costs in mind.


An entirely different route we can take is to eventually move from EVMs to ZK-friendly EVMs such as Cairo. The existing EVM code will be replaced by 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 at the moment is not to take any irreversible steps that lock us into long-term complexity that we may regret later. Trying to switch to small-endian byte order was a disaster, and we should learn from it and not do it again.


5. Using IP-4844 If the data is deleted after a month, how do I verify the next transaction?


Do you think in the future, when rollups can handle thousands of transactions per second, some of them might offer free packages? For example: In Optimism, the first 10 deals are free.


Vitalik:Question 1: I think this problem is often overstated. A month is about as long as Ethereum's weak subjective cycle, and longer than the one-week fraud proof cycle used by rollups. As a result, even under extreme conditions, people who need data have reliable access to it, which is already well beyond the minimum period of time acceptable to society.


There will be other protocols, for example. Based on IPFS or other means, it is easy to store the history chain, and many entities will independently make a full archived copy of it.


Q2: Actually, I think this is a good use case for something like UBI Coin. Actually, unfortunately, these programs will not be able to reach the economic scale to provide people with enough coins to pay for food and health care, especially if they are really successful in scaling up to millions of people, but they will be able to provide UBI large enough to cover people's transaction costs. This could make Ethereum non-financial applications (e.g. ENS, SIWE, POAP) more accessible to the many people around the world who don't have easy access to cryptocurrency trading platforms.


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 issues, which is the application layer. At the protocol level, I think it's right that the ecosystem takes stubbornness to the extreme, basically saying that either it stays censor-resistant or it doesn't make sense at all. But at the application level, this becomes less practical, both because the legal risks of using a prohibited privacy solution are too great for many ordinary users, and because if anything from a privacy protection system is deemed "contaminated" by default, even if the user is willing to take those risks or if the user is in a legally secure jurisdiction, Third-party services, such as trading platforms, still pose difficulties for them.


At the application level, therefore, 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 engage without introducing centralized back doors. The great thing about ZK-SNARK technology is that it has so many choices!


An easy option would be for people withdrawing money from ZK-SNARK mixers to provide additional evidence that the deposits they are withdrawing are not from some known "bad" deposit list (for example, known hackers) without revealing any other information about the deposits. The ability to do this can be integrated into the contract (reducing the number of proofs on the chain from 2 to 1) and integrated into the UI so that it becomes the default setting, in which case the hacker's anonymous set can drop by 95%+ by default (while just controversial rather than obviously bad molecules might see their anonymous set drop by 30-70%, But that still leaves them a lot of privacy).


Another option is to connect ZK-SNARK to some kind of humanity proof system, so that each unique verified human can "cleanly" anonymously extract 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 restricted to specific communities.


ZK-SNARKs offer a large and untapped space for trade-offs between privacy and verification, and we should explore the entire space.


7. Pick one or two key features or upgrades from Vitalik's latest "roadmap" released a few months ago (see my quick piece together here for reference: dropbox links to compiled Ethereum roadmap chart) - what are the key tasks to accomplish in the next few years?


In particular, it would be helpful to know if there is strong disagreement among Ethereum Foundation researchers on this issue.


Vitalik:My personal rough list of priorities right now is:


- Complete The "Basic rollup Extension" project in The Surge phase. This requires (1) IP-4844, and (2) EVM equivalent rollup to enter stage 1 of the take-off training wheel.


- Improve wallet security (especially through the ERC-4337 account abstraction) and work on adding more and better privacy solutions.


- The Verge, at least to average users (and even validators!) The level at which you can run stateless clients.


- Single slot final certainty, usually cleans and simplifies consensus


- Other


8. Since the PLONK protocol/proof system was invented (2019), how do you see the development in the field of zero knowledge?


Isn't it surprising that Circom is still widely adopted when we have PLONK arithmetization allowing us (theoretically) smaller proof and verification times? I think it opens up a whole design space for some applications.


Vitalik:I definitely wish there was more work on the ZK programming language. Being more open about the internals 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 and verify them; We should get to the point where we can validate a validation key on etherscan as easily as we can validate solidity code today.


9. What is the latest development in lunar mathematical cryptography that you are most excited about?


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


My blog post on complete homomorphic encryption details how lattice cryptography works, and should give an intuition of why grids can do a whole bunch of things that other cryptographic primitives can't. They are surprisingly simple in some ways, and the way that grid operations rely on "linear" operations allows them to stack and combine with each other in powerful ways.


Grids are also quantum-proof, 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 proof, which can only be done with hashing, is not encryption in the same sense; There is even evidence that you can 'use hashes only to make public key encryption that requires more than quadratic complexity to crack.


10. For the average person, wallets are the main outlet for Web3 and Ethereum. But in order for adoption to increase, they don't have to care about the underlying chain. In the rollup paradigm, is there a workable way to completely abstract away all Bridges and chain switches from the user and make it feel like everything is on a chain?


Vitalik:I think I actually disagree with that more and more as time goes on. For a new blockchain community to succeed at this, it will actually have to offer users a very new and unique idea that sets it apart from other products. Bitcoin and Ethereum are very different from each other, and users do have to care about those differences. Individual Cosmos chains may often be similar, but Cosmos as an ecosystem is very different, and one must care about the difference between it and the Ethereum ecosystem. I am increasingly convinced that chains that attempt to be indistinguishable from the average user will be ignored and fail, and users will combine Bitcoin, Ethereum, Cosmos and... Different ecosystems, just like they did with Twitter, Facebook, etc.


11. To what extent has centralized stablecoin become an attack medium?


Vitalik:I absolutely strongly support a more decentralized alternative to the current Stablecoin. See my recent post for my classification of the three stablecoins. Both the "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 strategy for continuous improvement) are interesting to me.


12. Does ZK rollup reduce/eliminate MEVs? What if so?


Vitalik:Not so, ZK rollups is solving validation issues, not transaction inclusion or sequencing issues. They are different problems. Although the ZK rollup project could certainly decide to include other technologies to try to better solve the MEV problem in its L2 chain.


Original link


Welcome to join the official BlockBeats community:

Telegram Subscription Group: https://t.me/theblockbeats

Telegram Discussion Group: https://t.me/BlockBeats_App

Official Twitter Account: https://twitter.com/BlockBeatsAsia

举报 Correction/Report
Choose Library
Add Library
Cancel
Finish
Add Library
Visible to myself only
Public
Save
Correction/Report
Submit