I Support EIP-4488! Let's make rollups cheaper!

Let me explain what this is about, and why I support it 🧡

#supportEIP4488
Technical TLDR: EIP-4488 reduces the calldata cost from 16 to 3 gas per byte, with a cap on calldata per block to mitigate security risks.

End-user TLDR: rollup cost overhead decreases, thus lowering L2 fees.
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.

See EIP 4490: github.com/ethereum/EIPs/… (4488 improves it in several ways)
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:

EIP Draft: github.com/ethereum/EIPs/…

Discussion: ethereum-magicians.org/t/eip-4488-tra…

β€’ β€’ β€’

Missing some Tweet in this thread? You can try to force a refresh
γ€€

Keep Current with proto.eth πŸš‚ πŸ¦‡ πŸ”Š

proto.eth πŸš‚ πŸ¦‡ πŸ”Š Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!

PDF

Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

More from @protolambda

19 Jun 19
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 πŸ‘
Read 23 tweets
18 Jun 19
A first technical impression of Libra, aka "facebook coin", compared against Eth 1 and Eth 2.
tweetstorm:
πŸ§β¬‡οΈ

#ethereum #libra #eth2
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)
Read 16 tweets

Did Thread Reader help you today?

Support us! We are indie developers!


This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Too expensive? Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal

Or Donate anonymously using crypto!

Ethereum

0xfe58350B80634f60Fa6Dc149a72b4DFbc17D341E copy

Bitcoin

3ATGMxNzCUFzxpMCHL5sWSt4DVtS8UqXpi copy

Thank you for your support!

Follow Us on Twitter!

:(