Ethereum Foundation 10th AMA Highlights: Validator Set, DVT, EIP4844, Rollup Solution Performance, Foundation's Conclusion
The Ethereum Foundation does not have any income, and some meetings are also non-profit, and it will not use the ETH from the treasury for staking revenue.Original: 《 We are EF Research （AMA）》
Compiled by: GaryMa, Wu Says Blockchain
On July 12, the Ethereum Foundation research team held the 10th AMA on the Reddit forum, where community members could leave questions in the post, and research team members would provide answers. Wu Says has summarized and compiled the relevant questions/technical points discussed in this AMA as follows:
- Validator Exit Related: Validators are allowed to trigger exits from their execution layer (0x01) using withdrawal credentials. If their balance is less than 16 ETH (due to inactivity penalties or slashing events), they will be kicked out of the protocol. Is the 16 ETH threshold too low?
This is mainly related to the EIP-7002 draft. It is understood that several research developers, including Danny Ryan, jointly released the EIP-7002 draft, which aims to allow validators to trigger exits to the beacon chain using withdrawal credentials from their execution layer (0x01). Since validators have two keys, the active key and the withdrawal credential, currently, only the active key can initiate a validator exit. This means that in any non-standard custodial relationship, the holder of the withdrawal credential cannot independently choose to exit and start the withdrawal process. To ensure that withdrawal credentials held by EOAs and smart contracts can control staked ETH in a trustless manner, this specification allows 0x01 withdrawal credentials to trigger exits. This proposal will benefit the development of liquid staking and distributed validator technologies, further promoting the decentralization of the beacon chain while better managing risks, such as private key loss or DVT validators losing connection with most shared keys.
- Random Number Problem: RANDAO + VDF
RANDAO is a method for generating random numbers. Suppose there are 10 students in a class, and the teacher wants to randomly select one student to award a prize. The teacher's selection method is that all students simultaneously provide a random number, and the sum of the 10 random numbers is taken, with the final number taken modulo 10 to determine the selected student. However, a problem can be identified in the operation of RANDAO. If a student cheats by providing their random number after the other 9 students, they can choose a number that is most favorable to themselves based on the information from the 9 random numbers, thus directing the final result towards themselves. Therefore, the effective operation of RANDAO requires the introduction of an anti-cheating mechanism, which ensures that everyone provides their answers simultaneously. This is where VDF comes into play. VDF stands for Verifiable Delay Function, and its important feature is that the computation process to obtain the result cannot be parallelized, meaning it cannot be accelerated. However, once the result is obtained, verifying the computational effort for that result is very small. VDF is implemented through hash functions, and the property of slow computation and fast verification of hash functions aligns with the nature of VDF.
However, research team members indicated that the ultimate economic benefit of attempting to exploit this "last proposer" vulnerability may not be ideal, and such deceptive behavior could severely damage the reputation of validators.
- Is SSV (Secret Shared Validator) and DVT (Distributed Validator Technology) a "must" for Ethereum?
As Ethereum's staking volume exceeds 20%, facing the potential centralization risk of node operators, two research team members indicated that such technologies may be a "must" solution in the short to medium term.
Justin Drake mentioned that his recent thoughts have partially changed because, in the long term, if one-shot signatures are achieved, the importance of these risk challenges will significantly decrease. However, one-shot signatures may take decades to realize, so in the short to medium term, DVT will be a more effective solution.
One-shot signatures are a special type of cryptographic signature where the private key can only be used to sign one message. They can solve many long-standing issues in the blockchain space, providing numerous advantages such as removing penalties, perfect finality, and trustless liquid staking.
- Maximum Effective Balance: Raising the validator staking cap (32 ETH) could reduce the number of validators in the network, thus achieving faster transaction finality (single slot finality), such as: 1) keeping the 32 ETH cap unchanged but limiting the maximum number of validators in the network; 2) considering whether to include the number of validator attestations in voting weight.
Option 1 would lead to the emergence of a trading market for the qualifications of existing validators, introducing potential serious security risks.
Option 2 would change the security model of the protocol and reduce the difficulty for attackers to reorganize the chain.
Recently, there has been a proposal in the community to increase the maximum effective validator balance from 32 ETH to 2048 ETH to help reduce the growth of the active validator set.
- What is the current progress of Single Secret Leader Election (SSLE)?
Vitalik stated that SSLE is still in the research phase, and since the non-secret nature of the leader has not yet been proven to be a problem, the priority of SSLE will be relatively low.
Note: Single Secret Leader Election currently has the proposer selected for each slot on the beacon chain publicly disclosed in advance, making them vulnerable to DoS attacks. The latest proposal encrypts and hides this process, so only the proposer knows their identity, effectively mitigating potential risks.
- Are there any updates on Ethereum's technical roadmap?
Vitalik indicated that most of the developments are progressing as scheduled, although there are adjustments in priority. For example, in April, due to the Mev-Boost vulnerability leading to malicious validator attacks on MEV Bots, the priority for implementing PBS (Proposer-Builder Separation) at the protocol level will be increased. Concerns about potential security risks introduced by re-staking will also raise the priority for optimizing and simplifying the solo staking experience.
Additionally, in a broader sense, priorities need to be raised for initiatives that can effectively assist many ecosystem-level matters, such as ERC-4337 smart wallets needing to achieve friendly cross-L2 interactions and improve gas efficiency.
- Can EIP4844 solve the liquidity fragmentation problem of L1 and L2s?
The instant composability of zk-rollups (which may not be achievable between OP Rollups) does not rely on the completion of EIP4844. There is a vast design space for composable coordination between zk-rollups, one possible solution being a dedicated minimal zk-rollup as a liquidity aggregator.
- Has Justin Drake's idea of Based Rollups to solve the sorting problem of Rollups (sorting on L1) been implemented?
Based Rollups (or Rollups sorted on L1) mean that the sorting of the Rollup network occurs on the L1 it is based on (most commonly the Ethereum network). More specifically, in the case of Ethereum, this means that searchers, builders, and proposers on the network all participate in the sorting of the Rollup network.
Compared to traditional Rollup networks that handle sorting themselves, Based Rollups have many advantages. First, they rely on Ethereum for transaction sorting, thus benefiting from Ethereum's activity. When discussing the risks of different Rollups, we found that if the sorter or validator fails, many issues could arise. However, for Based Rollups, this risk does not exist unless there is a problem with the Ethereum network. Additionally, there are advantages such as decentralization and no need for tokens.
One of the Layer 2 zkEVM projects, Taiko, will adopt Based Rollups for its release.
Some may confuse Based Rollups with sharing the memory pool with L1, but that is not the case; Rollups will have their own memory pool.
- Concerns about the centralization risk of block builders?
Justin Drake stated that the current builder market is already quite centralized (see https://www.relayscan.io/). The main risk of builder centralization is censorship, and currently, some good solutions include partial block auctions, such as inclusion lists, proposer suffixes, pre-commitments, as well as encrypted memory pools and MEV destruction.
- If the number of validators exceeds 1 million this year, can the mainnet operate stably? How many validators can the mainnet currently support?
Currently, the client team states that the mainnet can support approximately 1 to 2 million validators. The developer community is also exploring related matters, such as the next testnet, Holesky, which will have 1 million validators.
- Will the Ethereum Foundation dissolve? What will be the fate of the foundation?
Justin Drake stated that the Ethereum Foundation does not have revenue, and some meetings are non-profit; it will not stake ETH from the treasury for revenue. If the Ethereum Foundation's treasury runs out, funding may come from two sources:
- Public goods financing infrastructure within the ecosystem;
- Relatively low Ethereum L1 budget;
- Currently, there is no mature technical solution for cross-rollup transaction execution. What are your thoughts and suggestions?
Vitalik expressed that he does not believe there are many high-use cases for synchronously executing cross-rollup transactions; asynchronous cross-rollup transaction execution is acceptable and has many use cases. Synchronous cross-rollup transaction execution feels more like a deeply defined area; if we figure it out, it will certainly improve market efficiency to some extent, but otherwise, we can completely do without it.
- If rollup performance encounters bottlenecks in the future, is there a possibility for Ethereum's previous phase of sharding to return to the stage?
Justin Drake stated that execution sharding does not provide more scalability; moreover, the bottleneck of Rollups is data rather than execution. We can actually view each rollup network as an execution shard.
As long as the L1 EVM achieves SNARKified (The Verge phase of the Ethereum roadmap), Ethereum will have an enshrined rollup (a rollup that enjoys some consensus integration on L1), which can also be said that Ethereum has an execution shard at the L1 consensus level. Once the arduous work of SNARKifying is completed, it will become relatively easy to expose the SNARK verification logic itself as EVM opcodes in the L1 EVM. This will enable an unlimited number of enshrined rollups, which at the Ethereum consensus level, will act like execution shards of the mainnet, combining scalability with the same security as the mainnet.
