This week, I completed the reviews on the Ethereum roadmap and identified two topics of interest: staking economics/experience tracking and exploring solutions to liquid staking centralization. Next week, I will delve deeper into these topics, make a final decision, and write a research proposal. # Staking economics / experience track - Raise max effective balance – Enable the consolidation of large stakers into a single validator, drastically lowering the number of attestations to reduce bandwidth load on the beacon chain - ethresear.ch post - Ethereum developers plan to increase the maximum validator stake from 32 to 2,048 ETH in the Pectra upgrade. - The change is part of EIP-7251, aimed at enabling validators to have balances between 32 and 2,048 ETH. https://www.theblock.co/post/284189/ethereums-pectra-upgrade-to-raise-validator-stake-to-between-32-and-2048-eth?utm_source=twitter&utm_medium=social Proposal – Increase the MAX_EFFECTIVE_BALANCE to encourage validator set contraction, which 1. unblocks single-slot finality and enshrined PBS, and “By compressing the validator set, we can begin working towards single-slot finality immediately.” The high-level reasoning here is that the security properties of HLMD-GHOST rely heavily on honest proposers. With every other block being a “builder block”, the action space of a malicious proposer increases significantly (e.g., they may execute length-2k ex-post reorgs with the probability equal to the length-k ex-post reorgs under today’s mechanism). 2. reduces unnecessary strain 58 on the p2p layer. Committees in Ethereum: Slot Committees, Subcommittees, Sync committee It is important that a majority (>50%) of a slot committee’s weight (validator balance) remains under honest control to ensure the proper functioning of the fork-choice rule. The proposal to increase the MaxEB by a factor of k(e.g., from 32 to 2048 ETH is a factor of k=64) raises the question of the probability of slot committees being honestly controlled. We have one main security consideration: we require that in every subnet that contains honest validators there exists at least one honest aggregator, as this ensures that the honest attestations from that subnet make it to the global gossip. Mechanisms are already used: attesting validator weight proposer selection probability sync committee selection # Explore solutions to liquid staking centralization Mitigating centralization concerns around big liquid staking pools controlling - Liquid staking maximalism design by Dankrad - Musings about enshrining liquid staking or making decentralized liquid staking much safer might it make sense to enshrine some kind of in-protocol functionality to make liquid staking less centralizing? what kind of in-protocol functionality? Simply creating an in-protocol fungible "staked ETH" token has the problem that it would have to either have an enshrined Ethereum-wide governance to choose who runs the nodes, or be open-entry, turning it into a vehicle for attackers. - we bite the bullet that if Ethereum gets 51% attacked, only perhaps 5% of the attacking ETH gets slashed. This path is interesting. But it still leaves open the question: what is the specific thing that would get enshrined? - RocketPool already works in a way very similar to this: each node operator puts up some capital, and liquid stakers put up the rest. - There are other clever things that we can do with simple protocol tweaks. For example, imagine that we want a system where there are two "tiers" of staking: node operators (high collateral requirement) and depositors (no minimum, can join and leave any time), but we still want to guard against node operator centralization by giving a randomly-sampled committee of depositors powers like suggesting lists of transactions that have to be included (for anti-censorship reasons), controlling the fork choice during an inactivity leak, or needing to sign off on blocks. This could be done in a mostly-out-of-protocol way, by tweaking the protocol to require each validator to provide (i) a regular staking key, and (ii) an ETH address that can be called to output a secondary staking key during each slot. The protocol would give powers to these two keys, but the mechanism for choosing the second key in each slot could be left to staking pool protocols. It may still be better to enshrine some things outright, but it's valuable to note that this "enshrine some things, leave other things to users" design space exists.