Ethereum 2.0 and Beyond (SBC19)

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!