Initially, the plan for Ethereum was to use a Casper staking mechanism on top of the pow Ethereum chain.

This plan was abandoned because we wanted to focus on developing the Beacon chain. Now, reading the new Beacon chain spec, I think that only small changes would be needed to use the Beacon chain for introducing POS-finalization also on top of our current pow Ethereum 1.0 chain.

We could use the Casper staking mechanism of the Beacon chain to POS-finalize the Beacon chain AND the Ethereum 1.0 chain. This would give the Ethereum 1.0 chain more security, while we are developing proper shards for our Beacon chain in the coming years.

In this thread, I would like to discuss the technical feasibility of POS introduction.

Current eth2.0 spec:

In the current eth2.0-specs, we have a one-way connection between the Beacon chain and our current Ethereum 1.0 chain.

Basically, the Beacon state is aware of the last processed receipt root of the Ethereum 1.0 chain: processed_pow_receipt_root and possible new candidates of pow receipts: candidate_pow_receipt_roots . The Beacon chain needs to be aware of them, in order to make sure that the deposits into to Beacon chain are credited.

If half of the block proposers of the Beacon chain voted for one ‘candidate_pow_receipt_roots’, this candidate will be incorporated and all deposits will be credited:

Set state.processed_pow_receipt_root = x.receipt_root if x.votes * 2 > POW_RECEIPT_ROOT_VOTING_PERIOD for some x in state.candidate_pow_receipt_root

Idea:

In the Beacon chain, we are referencing to “old” Ethereum 1.0 blocks. If blocks of the Beacon chain are finalized, then also the old Ethereum 1.0 blocks from within the references, would be finalized. That means that no reorgs deeper than the last finalized Ethereum 1.0 block is allowed.

Specification details:

See here for the more recent proposal.