Share this page!

Bartek Kiepuszewski Profile picture
Twitter logo
20 Nov, 10 tweets, 3 min read
1/ After seeing so much confusion about upcoming data sharding in Ethereum, here's my take on why you will soon see massive increase in tx throughput on Ethereum and how this is achieved 👇🧵
2/ The main factor limiting Rollup scalability today (both Optimistic and ZK) is the fact they both use tx calldata to store L2 txs on L1 and the size of calldata is limited by L1 block size. Hence ideas such as Validium or zkPorter (blog.matter-labs.io/zkporter-a-bre…)
3/ These ideas are nice, but they introduce additional security assumptions, such as "Data Availability Committees" with their own tokenomics. What if there was a way to somehow make L1 validators to be such a committee ?
4/ In other words, what if instead of using calldata Rollups had access to a nice distributed storage that is maintained and secured by the same validators as the L1 blockchain ? That storage is right now being speced out and will be the next big thing in Ethereum after the Merge
5/ We call this additional storage "data shards" which is a bit unfortunate as most people, when thinking about "shards", think about "execution shards", i.e splitting blockchain state into independently-validated pieces. I will call them data blobs to avoid confusion
6/ Execution shards will also happen in the future (think few years), but on the short term roadmap (next year) Ethereum will deliver just this additional storage (data blobs). So we will still have just one execution shard and one shared state (i.e. today's L1 EVM state)
7/ So how these "data blobs" work and how clients can cheaply check that data is available ? Through a technique called "data availability sampling" and KZG commitments dankradfeist.de/ethereum/2020/…
8/ Simply put, everybody will be able to run a "light" client that will sample the data from validators w/out the need to download it and it will receive guarantees that data is available. If not, validators will be slashed, similarly if they produced invalid blocks
9/ These data blobs are being built mainly for Rollups. So your dapps will still continue to live on Rollups as today (check full list on @l2beatcom) it's just that suddenly they will be 100x cheaper for end users to use as paying for calldata space is the main fee factor today
10/ Interested in more details ? Here's the link to high-level overview: hackmd.io/G-Iy5jqyT7CXWE… and the actual spec github.com/ethereum/conse…

• • •

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

Keep Current with Bartek Kiepuszewski

Bartek Kiepuszewski 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 @bkiepuszewski

Bartek Kiepuszewski Profile picture
12 Nov
1/ What are your favourite blockchain myths ? Can you add sth to this list of my personal favourites (in no particular order) ? Which one you disagree with ? Myths and Truths below: 👇🧵
2/ M: There is no extra social layer in blockchains, consensus is programmed into the software and blockchains are truly immutable
T: Users can decide to change consensus rules, fork the blockchains, change history
3/ M: Users will prefer immutable, code-is-law, blockchains over blockchain that changes former consensus rules
T: If programmed consensus rules seriously clash with what is understood to be the social consensus (the intent) users prefer a forked blockchain (ETH vs $ETC)
Read 16 tweets
Bartek Kiepuszewski Profile picture
13 Oct
1/ Let's try to dispel the biggest confusion about Optimistic Rollups and their 7-day fraud proof window. Imagine you have 1000$ DAI and send it to Alice. Then you send it again to Bob. Obviously you expect that first tx confirms, the second reverts with "out-of-balance" error 👇
2/ Clearly Alice should now have 1000$ DAI and not Bob, provided that the *sequence* of txs are as above. Now, Sequencer posts both transactions to L1 in a batch and also posts a state root (a magic number). L1 does not do anything fancy, except recording these.
3/ If Sequencer is honest, the state root "confirms" to L1 that it's Alice that has $DAI on L2 and not Bob. So Alice can withdraw that $DAI to L1, i.e. release them from L1 deposit contract. Not Bob. But how L1 can be sure that L2 Sequencer is honest ?
Read 9 tweets
Bartek Kiepuszewski Profile picture
23 Sep
1/ The second, after censoring, aspect of L2s is what users need to do if L2 operator stops pushing new state roots on L1 @l2beatcom 🧵👇
2/ You can read about the censoring in the previous thread here:
3/ Pushing state roots is crucial so that users can withdraw their funds from the bridge. And to be able to do it, you need to provide Merkle Proof of your balance against that state root on L1
Read 12 tweets
Bartek Kiepuszewski Profile picture
22 Sep
1/ How important is Censorship Resistance for L2s ? Applications can censor individual users based on where they come from, or whole dApps could be rendered useless if Rollups censored all incoming txs to them. What are the possible solutions right now ? 👇@l2beatcom
2/ @arbitrum and @optimismPBC allow users to "force" their transactions via L1. This is perhaps inconvenient for the end users, but it is a very generic mechanism that works for all dApps on a Rollup. And dApps don't need to do anything, it's just there. And it works
3/ @StarkWareLtd based L2s (@SorareHQ, @dydxprotocol, @deversifi, @Immutable) also have force transaction mechanism, but they are application specific. Namely, they allow you to force only certain tx (typically withdrawal request). It's as if each dApp had to implement it on L1
Read 7 tweets
Bartek Kiepuszewski Profile picture
16 Sep
1/ With @arbitrum Sequencer down for an hour, Arbitrum chain effectively reduced itself to L1 Ethereum wrt to cost and speed, but it never stopped working. How is it possible ? And why @l2beatcom claims that users should propose blocks when operator is down ? 🧵👇
2/ Arbitrum, as any L2 Optimistic Rollup, posts on Ethereum L2 transaction batches and, periodically, state roots of L2. Anyone can confirm that the latest state root of L2 is indeed the result of executing L2 transactions previously posted. Verify, don't trust !
3/ So, who is posting L2 txs on Ethereum ? Typically sequencer, but if Sequencer is down, users can do it themselves. This is what we mean by "transacting using L1". Users can do it if Sequencer is down, or if the Sequencer is censoring them
Read 10 tweets
Bartek Kiepuszewski Profile picture
18 Aug
After long discussions we, at @l2beatcom ended up with the series of questions that we hope each Rollup provider will be able to answer so that users will be able to properly assess the risk of their funds deposited into the Rollup: 👇
1. Let's start with the obvious - are you using Validity Proofs or Fraud Proofs on L1 to secure the state ? What are the details ? How can users be sure that you are proving what you claim to be proving ?
2. Transaction data will be needed for Fraud Proofs, Emergency Exits, etc... where is the data stored ? If on L1, how users can be sure that they will be able to decode it if needed ? If not, where is it and what entity(s) are securing it ?
Read 8 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

Thank you for your support!

Follow Us on Twitter!

Like this author's thread?

Get emails when @bkiepuszewski has new unrolls!

Check out other threads from @bkiepuszewski!

Read all threads by @bkiepuszewski

:(