Alex describes in this episode the key attack that sharded blockchains need to deal with: data withholding.

A thread 👇 https://twitter.com/AlexSkidanov/status/1252280610728497152
If an invalid block is created, a compact fraud proof can be produced to show this to light clients. Full nodes fully validate everything, so they are unaffected by invalid blocks. They can produce fraud proofs for light clients.

Fraud proofs are "alerts" in the Bitcoin paper.
The problem: data withholding.

Data withholding in a normal blockchain: a majority of the global validators produce an invalid block (say, that gives them a bunch of coins) and withhold the data behind it.

Full nodes can't produce fraud proofs of a missing block!
The issue here is that data withholding is a *non-attributable fault*.

Alice can't tell the difference between Bob withholding data on Charlie and Charlie lying that Bob is withholding data on him without downloading the data herself.
In other words, light clients are dependent on an honest majority of the chain's validators for state safety.

What about sharded blockchains? How does data withholding affect them? Read on and find out!
Now, the real problem: data withholding in sharded blockchains. Only a single shard needs to be corrupted for an invalid block to be produced and its data withheld. In other words, a local validator set.
If each node was a full node of every shard, then we'd have no scalability (see this thread 👇 for more)! So we need shard nodes to only fully validate one shard at a time, and be light clients of other shards. https://twitter.com/VitalikButerin/status/1193914739144966145
As per above, light nodes are dependent on an honest majority of a chain's validators for state safety (i.e. to prevent theft, infinite inflation, etc.). In a sharded blockchain, this would be local to each shard!

In other words, really really cheap to attack. Can we do better?
It turns out that yes we can do better, with probabilistic data availability proofs. Data can be locally verified as available using *sub-linear* work. This is *the* key technique that sharded blockchains rely on for security, ultimately.

https://arxiv.org/abs/1809.09044 
Can we do even better? It turns out that yes we can! Since data availability checks are the key to making sharded blockchains secure, what if we had a blockchain that only ordered data and made it available, and left all execution to be done client-side? https://twitter.com/jadler0/status/1182511693462528000
Client-side execution has two enormous benefits:

1) It optimally deals with the scaling bottleneck (which is execution, not consensus). There's no cheaper execution than no execution!

2) It greatly increases flexibility. https://twitter.com/jadler0/status/1233105715419648001
That blockchain is being built, and it's called LazyLedger @lazyledger_io! It allows for maximal scalability---increasing throughput without increasing node requirements---and greater flexibility than any other blockchain in the world. https://twitter.com/lazyledger_io/status/1202586674515103744
You can follow @jadler0.
Tip: mention @twtextapp on a Twitter thread with the keyword “unroll” to get a link to it.

Latest Threads Unrolled: