This sounds too good to be true, so here's the catch:
It does not directly increase L1 data capacity, but rather balances cost of execution with cost of data in favor of rollups,
while retaining a similar max capacity.
This rebalancing means that the average data usage of available capacity will go up, not the max capacity itself.
So long-term we definitely need sharding for the capacity increase, but short-term we get to enjoy lower rollup fees.
Not too long ago I started working with @OptimismPBC, but this is not the only rollup that will benefit.
Starkware started the conversation (AFAIK), and others like Arbitrum will also benefit.
Data-availability is the most fundamental scaling problem, and this EIP is a relief for L2 protocols that are fighting it.
Long-term I still plan to continue my work on sharding, with the support of @OptimismPBC.
In the short and medium term it is too early for sharding however, Merge is top-priority, and rollups are still evolving rapidly.
Generally I think this is the right direction for ethereum:
Rollups can grow with adoption (= feedback & funding) while L1 is primarily focused on the move to Proof of Stake, and everyone can commit to Sharding when ready.
Regarding governance: when I first discovered this EIP I was very hesitant, I respect other EIPs which have been delayed till after the Merge and the proposed timeline for 4488 is very quick (before Merge would be best).
And while being invested in the development of rollups, taking a blind stance in favor would be wrong.
However, the technical complexity is low and it makes sense before we have sharding.
Authors of other EIPs I reached out to were all positive as well, the support is there.
And if someone is not working on it already, I might help write or test some of the implementation.
And you too can #supportEIP4488! Join the R&D discord and ask who you can help.
If you want to read more, you can find the EIP and discussion here:
Libra TAKE-2. Whitepaper is somewhat confusing, source code is where it's at to get the details. Dug through it for you. Not an audit, just fun. Comparing with Eth1/Eth2 where relevant. Getting in merkleization/hashing/crypto/misc, but not consensus.
Tweetstorm β¬οΈ π§
0. First of all, source code is located here: github.com/libra/libra
Apache 2.0 license. π
1 They actually have a "legacy" and "next-gen" crypto package. Guess what's in the next gen? An unused BLS12-381 implementation. What we use in Eth2. Work in progress, but everyone is welcome to join standardization process. And experiments like this help the whole space π
0. data keying:
- 32 byte keys seem to be the future. Not only Ethereum 2 is using them in SSZ, Libra will use them for account keys
- static generalized indices, can't find much for "light" clients, you're either a powerful validator, or a user (to be expected)
1. Hashing/merkleization:
- SHA3-256. Not like eth1 (older SHA3), or ETH2 (SHA2-256, like bitcoin)
- No derived merkle structures ("hash tree root" in Eth 2) just bare binary trees.
- Sparse binary trees, with leafs moved upwards. Efficient, but not static enough (important too)