Notes from the EF’s Research Team AMA
This is by no means an comprehensive list, but just some interesting highlights. Many of these I already knew, some new things I learned about, and some that were clarified. Some of them are accompanied by my thoughts, it should be clear when that’s the case. Full AMA here: https://www.reddit.com/r/ethereum/comments/o4unlp/ama_we_are_the_efs_research_team_pt_6_23_june_2021/
- You can withdraw balances in excess of 32 ETH, and transfer funds above the 32 ETH staked to other addresses. Withdrawals will happen the first hardfork post-The Merge, though it’s unclear when transfers are enabled.
- Data sharding does flip the trilemma on its head, and you’d need a massively decentralized protocol with a million validators to enable this type of scaling. Delegated-type chains with limited validator sets, usually in the hundreds, to at most a couple of thousand, will never achieve this level of data availability securely. With 175,000 validators now and growing at a maximum rate of 900/day, Ethereum is uniquely positioned to offer massive data availability for rollups.
- There are significant trade-offs to reducing the minimum staking amount, but interestingly, using zk-SNARKs we can have a new class of lightweight validators called aggregators.
- Secret shared validators are making great progress, and enables multiple different people to get together and run validators within each 32 ETH. I definitely look forward to decentralized protocols built around SSVs.
- As alluded to before, another incentive to lower the staking requirement is having more validators enables more shards.
- Danny Ryan is excited about universal login across the internet with your ethereum address. Both Danny and Justin are hyped for EIP-1559, but Justin is also looking forward to smart contract rollups like Arbitrum, Optimistic Ethereum and zkSync 2.0.
- Looking into the future decades out, both Vitalikand Justin consider Indistinguishability Obfuscation as the next revolution. One potential application is trustlessly bridging Bitcoin and Ethereum without actually requiring any support from the Bitcoin side. Vitalik is also excited for fully homomorphic encryption, which will be useful before IO. Both Vitalik and Justin think there’s still significant room for ZK-SNARKs to improve and mature, and will continue to drive innovation in the near term.
- Statelessness and state expiry may enable a 2x-3x scalability improvement, but they also may want to use those gains to make running nodes much easier.
- The goal is to not rely on SSDs, and make running Ethereum easy for the average user. With stateless clients, you could even run an Ethereum node on a budget HDD-based system. However, SSDs will still be required for block producers and state providers, so decreasing SSD costs will lead to scalability improvements over time.
- Vitalik is no longer following Austrian or Chicago schools of economics, instead going his own way with models like quadratic funding.
- The EVM is currently “needlessly unfriendly” to rollups, and some minor tweaks could make things much easier for optimistic rollups. For ZK rollups, more radical changes are needed on the L1 side.
- Very interesting question about oracles, but Barnabé Monnot sees it as better addressed by the application layer.
- Each data shard will have independent gas markets, and follow an EIP-1559-style mechanism. Data costs will thus be effectively decoupled from execution, becoming significantly cheaper once data shards are live. While data shards will be primarily intended for use by rollups, L1 smart contracts may too get creative and find ways to use them.
- Following from the above two comments, data availability sampling will follow less than 12 months after shards are first deployed. It won’t require a hard fork, and can be implemented incrementally.
- The transition to post-quantum cryptography is non-negotiable. Fascinating comment by Justin here!
- If zk Rollups prove zkVMs work as intended, execution shards become essentially moot. The better option then becomes to zk-SNARK the EVM at L1. There’s a real chance execution shards never happens, and at this time is only a back up option if zkVMs don’t work out.
- In what is surely my favourite comment of the day, Carl Beek thinks his colleague’s (Justin’s) ultra sound money meme is silly and we should be focusing on ETH’s value being tied to its usefulness instead. However, he acknowledges that Bitcoin deriving most of its value from memes means he may be wrong.
- Sharding and statelessness are being developed in parallel, and it’s unclear which comes first.
- Terrific comment about Vitalik’s process.
- Difference between decentralized staking pools and dPoS-style chains highlighed by Vitalik and Dankrad. I’ll add that delegated-type chains could potentially be viable at home. One example is Cardano, currently with its 7 TPS / 65kB block limit it’s actually easier to run than Ethereum. But of course, not for long, these chains very quickly tend to bump up their limits as without higher scalability they’re kind of pointless.
- Very important point by Dankrad — rollups will maintain composability across multiple data shards. So you could theoretically have one mega-rollup doing 100,000 TPS. Of course, composability between rollups is a harder problem, and we’ll likely have asychronous solutions, though they should be manageable. I’ll add that zkVMs can have Volition-type architectures where they can have multiple sources of data availability, all while retaining full composability.
- Clients that are live are not subject to long range attacks, but some brainstorming on how they can be mitigated long term.
- Shards are speculatively still expected “in 2022”. I’d say late 2022 is the most likely timeline.
- Finally, there are multiple comments about The Merge. I’ll summarize it as the following: no research obstacles left, there’s a complete spec, all that’s remaining is engineering and testing. Q1 2022 seems the most likely timeline.
As a bonus:
- This bit is not actually something from the AMA, just my own estimations, but thought it would be interesting. I’m extrapolating from the clarifications here. The numbers are much clearer to me now, so I can finally do some calculations myself. In an ideal scenario where all activity was on rollups, all transactions were simple ETH transfers consuming 12 bytes, and fixed costs became negligible, the current execution chain could handle upto 6,500 TPS for rollups. This could be higher still on zk Rollups with signature aggregation. For ERC-20 transfers and 16 byte transactions, this would be about 4,800 TPS. Note that these numbers are post-Merge when block times are exactly 12 seconds; in a PoW world they are 10% lower with 13+ second block times. Of course, much lower for complex DeFi transactions. We’ve seen on Ethereum mainnet how the mix of transactions skews towards simpler transactions while the gas price is high, with more complex transactions while the gas price is low. Similarly, I’d expect an explosion of activity on rollups for complex DeFi, prediction markets, privacy etc. transactions as many of these have priced out many people thus far. So, I’d anticipate somewhere between 1,000 TPS to 1,500 TPS on average for rollups. When data sharding releases, this will be accelerated by a further 18x, which is upto 118,000 TPS, or 25,000 TPS including complex transactions. However, note that in the comment Vitalik acknowledges the data sharding rollout may possibly begin with lower data availability if it’s deemed to be lower risk, and then systematically expand. Over the decades, if the maximum of 1,024 data shards are enabled, this would be 400,000 to 1.8 million TPS for rollups.
- But wait, it doesn’t end there, as that doesn’t account for technological progress, so data per shard can also expand! Back to the AMA, how about 7.3M TPS in a decade before even accounting for more shards? Multiply that by the maximum number of shards, and we’re approaching 100 million TPS. (Of course, these are speculative extrapolations and things like storage may not keep up with bandwidth, so please don’t take them seriously, but fun anyway!)