Difference between Sharding and Plasma

Question

What are the differences between Ethereum Sharding Proposal and Plasma? I know plasma can run on top of sharding, but what are the differences innterms of paradigm and technology?

Answer 1

The first phase implementation of sharding and Plasma are both essentially sidechains that tie into the main chain via smart contracts. However, the responsibilities of these smart contracts and properties of the sidechains is different for each project.

Plasma sidechains are somewhat similar to state channels (e.g. Lightening and Raiden) in that they use the main chain primarily to adjudicate fraud on the sidechain. Anyone can create a Plasma sidechain, which itself may consist of subchains, so any number can be created.

In contrast, shard sidechains act more like extensions to the main chain by periodically commiting a state root hash of transactions from their shard. There are no deposits to bond the sidechain transactions. Instead a proof of stake process on the main chain assigns notaries from a pool to validate blocks (called collations) on a fixed (SHARD_COUNT) number of shards.

See also: https://github.com/ethereum/wiki/wiki/Sharding-FAQs#how-does-plasma-state-channels-and-other-layer-2-technologies-fit-into-the-trilemma

Answer 2

The above answer is outdated on sharding, notaries are used instead of validators. See https://github.com/ethereum/wiki/wiki/Sharding-FAQ#how-does-plasma-state-channels-and-other-layer-2-technologies-fit-into-the-trilemma.

After editing the above post, it is outdated again with the latest spec ditching the contract on the PoW main chain, and instead using a PoS beacon chain which is planned to become the main chain, with the PoW main chain planned to be later phased out.

See also https://github.com/ethereum/wiki/wiki/Sharding-FAQs#what-might-a-basic-design-of-a-sharded-blockchain-look-like.

What might a basic design of a sharded blockchain look like?

A simple approach is as follows. For simplicity, this design keeps track of data blobs only; it does not attempt to process a state transition function.

There exist nodes called proposers that accept blobs on shard k (depending on the protocol, proposers either choose which k or are randomly assigned some k) and create collations, thus they also act as a collator, and so agents that act as both a proposer and collator may be referred to as prolators. A collation has a collation header, a short message of the form "This is a collation of blobs on shard k, the parent collation is 0x7f1e74 and the Merkle root of the blobs is 0x3f98ea". Collations of each shard form a chain just like blocks in a traditional blockchain.

There also exist notaries that download (to ensure availability) and verify (only in the case of an EVM existing, by executing data to ensure validity) collations in a shard that they are randomly assigned and where they are shuffled to a new shard every period via e.g. a random beacon chain and vote on the availability of the data in a collation (assuming no EVM, with an EVM they may also act as an executor and vote on the validity of data).

The source of randomness for the beacon chain is some publicly Verifiable Random Function such as RANDAO or a blockhash produced by a BLS aggregate signature. The former is preferred due to favouring availability over consistency and does not require an honest / uncoordinated majority assumption (i.e. no bribing attack or colluding majority), while it probabilistically requires a lower stake power to revert a chain, although this is minimized through using a n-of-n committee. N-of-n means, using 3-of-3 as an example: "at every tick of the global clock a new proposer and a new 3-member committee is elected for the RANDAO beacon. In order for a proposal to make it through (a proposal is the preimage corresponding to the last commitment) the proposal needs to get all three signatures from the committee." (source). Thus, n-of-n means that all n (or n out of n) members of the committee must sign off on the proposal.

A committee can then also check these votes from notaries and decide whether to include a collation header in the main chain, thus establishing a cross-link to the collation in the shard. Other parties may challenge the committee, notaries, proposers, validators (with Casper Proof of Stake), etc., e.g. with an interactive verification game, or by verifying a proof of validity.

A "main chain" processed by everyone still exists, but this main chain's role is limited to storing collation headers for all shards. The "canonical chain" of shard k is the longest chain of valid collations on shard k all of whose headers are inside the canonical main chain.

Note that there are now several "levels" of nodes that can exist in such a system:

• Super-full node - fully downloads every collation of every shard, as well as the main chain, fully verifying everything.
• Top-level node - processes all main chain blocks, giving them "light client" access to all shards.
• Single-shard node - acts as a top-level node, but also fully downloads and verifies every collation on some specific shard that it cares more about.
• Light node - downloads and verifies the block headers of main chain blocks only; does not process any collation headers or transactions unless it needs to read some specific entry in the state of some specific shard, in which case it downloads the Merkle branch to the most recent collation header for that shard and from there downloads the Merkle proof of the desired value in the state.