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:
state.processed_pow_receipt_root = x.receipt_rootif
x.votes * 2 > POW_RECEIPT_ROOT_VOTING_PERIODfor some
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.
See here for the more recent proposal.
Old initial idea
Only slight details of the current eth2.0 -spec beacon chain would need to be changed. These changes are:
The Beacon chain state should be aware of the last POS-finalized block of the Ethereum 1.0 chain.
New Beacon chain blocks are only processed by the Beacon chain clients if the new Beacon block also refers to an Ethereum 1.0 block, which is a child of the POS-finalized block. More specifically, each new Beacon block in the cycle x should refer to the Ethereum 1.0 block, which was minted during the Beacon cycle x-50 (that should be roughly 4x6x50 blocks in the past) and has the highest timestamp and is a child of the last finalized block.
At the end of each Beacon cycle, any new finalization on the Beacon chain, where the old justified block and the new justified block both reference to Ethereum 1.0 blocks on the same branch ( new justified block must refer to a child block of the referred block in the old justified block), will also set a finalization of the Ethereum 1.0 chain. The Ethereum 1.0 block, which was referenced in the new finalized Beacon block, will be the new finalized block.
If we are getting a new finalization on the Beacon chain, where the old justified block and the new justified block do not reference to blocks on the same branch, we will not do any finalization of Ethereum 1.0 blocks in this cycle.
Deposits from the Ethereum 1.0 chain into the Beacon chain would be handled similarly as in the current spec, only the point of time would be different: It would happen, if there is a new finalized Ethereum 1.0 block.
Alternatively, one could also dedicate one shard id to the Ethereum 1.0 chain and use crosslinks for the finalization of the Ethereum 1.0 chain.
The changes for the Ethereum 1.0 chain clients would be also very minor. We would just need to make them aware of the happening of the Beacon chain and do not allow any reorgs deeper than the finalized block.