Haseeb-Qureshi/ethereum_2_dot_0.md

## ethereum_2_dot_0.md

      
    Raw
  

              ethereum_2_dot_0.md
            
          
    Ethereum 2.0 and beyond

Vitalik Buterin (Ethereum Foundation)


Ethereum 2.0 spec pre-release

Released yesterday!


Proof of stake and sharding have been part of the ETH roadmap since 2014

Started with Slasher in 2014, which is totally broken
But since then have made a lot of progress
Casper FFG devised and formally verified
Sharding is now better specified
All this is being implemented, a couple months away from testnet


What is Ethereum 2.0?

Hub and spoke system around the beacon chain

Connected to the ETH 1.0 chain (this is necessary, but temporary, to migrate assets to new chain)
1024 shard chains connected to the beacon chain


Phase 0 (just beacon chain and PoS)
Phase 1 (data sharding, shards contain just data blobs)
Phase 2 (state + execution, now you actually get smart contracts on shards, storage rent, etc.)
Phase 3 (STARKs, other scaling approaches)


The Beacon Chain!

PoS system, you need to burn at least 32 ETH into a 1-way burn contract
Publish a Merkle proof receipt of this burn onto the Beacon chain

Now you are deposited onto the Beacon chain (into BETH)
Thus, the Beacon chain needs to be aware of root hashes on Ethereum chain


The Beacon chain runs PoS consensus independently of other systems
Time is broken up into slots about 6 seconds long, grouped into 64 slots in an epoch

In each epoch, each validator makes 1 signature
First signed by block proposer, then signed by large randomly selected committee of other nodes


Attestations get put into the chain and chain moves forward
Attestations do three things:

Contribute to beacon chain fork choice (not Nakamoto consensus, but through LMD Ghost)
Contributes to beacon chain finality (FFG)
Validates data and commits to shards


What is LMD Ghost?

An adaptation of GHOST (Sompolinsky, et al 2013)
Idea: look only at latest messages of each node as evidence what chain that node favors
GHOST is a fork choice rule that says start from genesis, walk up the tree

at each branch, choose the child that has more latest-messages supporting it in the tree

(in traditional GHOST, you choose child with most PoW built on its subtree)


LMD GHOST can take in information from many parallel attestations in one block

Making it less dependent on proposers, fewer messages are wasted
This is really valuable for high block throughput!
1 confirmation becomes as final as 50 confirmations on ETH 1.0 chain


FFG Finalization

Adaptation of classical consensus algorithms

Dual-purpose messages that are already part of a chain-based PoS to achieve finality


If more than 2/3rds of messages agree on blocks within 2 epochs,

then block at the beginning gets finalized
This is asynchronously and cryptoeconomically safe (not possible in PoW or chain-based PoS)


Crosslinks

How PoS interfaces with sharding
Each shard is its own chain, and each validator on beacon chain validates some shard chains

Blocks in shard chains get committed into beacon chain
If beacon block gets finalized, the shard chain block gets finalized by proxy


With enough crosslinks...

Anything that happens on one shard can be proven to happen on another shard

Via Merkle proof


This is also the engine through which shards talk to each other


Crosslinks are signed by committees (128-4096 validators)

Note: you're assuming that committees are >1/2 honest
For each crosslink, the committee is sampled via random sortition via on-chain randomness


BLS Signature Aggregation

We might have a LOT of validators... At worst case, we can have hundreds of thousands of validators
4K + signatures can be aggregated into a single ~600 byte signature, about 7ms to verify


Proof of custody

Can we do better than an honest majority assumption among validators for crosslinks?
Given validator's dilemma... how much faith should we put in validators?

Most nodes are lazy and will not validate if they don't have to


Well, let's give them an incentive to pay attention to crosslinks!
Proof of custody is a way to put bounties on each of these crosslinks

The attester runs a computation on the raw block data, adding a secret salt
Then publishes a commitment to a Merkle tree
Later, they reveal the salt, which lets anyone with the true block recompute the tree
If you didn't do the computation correctly, watchdogs can catch you with a fraud proof
And if you perform the commitment over some bullshit data that you don't even have...

They can initiate a fraud challenge, and you won't be able to produce evidence


Either way if you misbehave, you get slashed, and the whistleblower gets rewarded


Future directions

Data availability proofs via erasure coding

Basically, instead of committing to Merkle root of regular data...

Instead you commit to Merkle root of erasure coded version of data
(Such that half of data is needed to recover original data)


Light client can randomly sample Merkle branches, and if more than half of data is available, they can assume it's mostly there
Useful for allowing light clients to check block data is available w/o downloading it
Providing maximally close to full-node security guarantees in case of 51% attacks


STARKs

Useful for compressing Merkle branches (needed by crosslink committees)

These branch proofs are larger than even the block contents
With STARKs, we can compress that and get a 5x improvement on data efficiency


Verifying correctness of proofs of custody, data availability proofs, etc.
Verifying correctness of arbitrary computation (maybe someday!)


Casper CBC

Not integrated into roadmap yet, but actively looking at
Significantly reduced protocol complexity
Lets large portions of validators go offline
Significant performance improvements recently


And that's Ethereum 2.0!

A lot of disparate technologies and ideas that have synergies between them
Next milestone will be testnets released sometime in the next few months
Ethereum Foundation and core research team and trying to spearhead spec development

But implementation itself should happen through other development teams
Prysmatic Labs, Pegasys, Lighthouse, Nimbus, etc.
If you want to hear about timelines for launch, ask the implementers, not Ethereum Foundation!