Here is a much more educated proposal:
Introduction:
The attestation concepts for the shards from the ETH 2.0 spec can be used straightforward for an Ethereum 1.0 finalization. The main challenges are coming from the fact, that POW blocks are coming fairly irregularly compared to the POS blocks and the synchronization with the beacon “heartbeats” is not enforced.
Concept:
We define that the rotating attestation committee of the shard 0 will be responsible for the POS validation of the Ethereum 1.0 chain. All other shards 1-1023 will be used as real Ethereum 2.0 shards.
The attestation committee of this shard 0 will, exactly like the others, vote on cross-links for the shard and attestations for the Beacon chain.
We want to call an Ethereum 1.0 block cross-linked if the attestation committee generates a cross-link for this block, (i.e. 2/3 of the attestation committee voted for this block).
We also want to call an Ethereum 1.0 block finalized, if the block is cross-linked and the cross-link is included into a finalized Beacon chain block.
The beacon chain usually justifies/finalizes an epoch_boundary_block. We will call an Ethereum 1.0 block, epoch_boundary_block, if it is a most recent block in the POW chain before the Beacon-chain ‘epoch_boundary_block’ (We will compare it based on block timestamps). This will give us exactly one Ethereum 1.0 epoch_boundary_block per epoch of a beacon chain.
The honest majority of the attestation committee of the shard 0, will only attest to epoch_boundary_blocks of the Ethereum 1.0 chain. The votes of the committee do not touch the Ethereum 1.0 chain, they will just be posted into the Beacon chain, exactly as for the usual shard construction.
In order to have a smooth attestation process, the committee would vote on the epoch_boundary_block of the epoch e, if the Beacon chain is in the epoch e+1. This delay of one epoch (64*5sec), will give the Ethereum POW chain some time for stabilization.
Fork-choice rule for Ethereum 1.0:
Clients of Ethereum 1.0 would need to be aware of the leading Beacon chain block. From this leading Beacon chain block, they would read the leading cross-linked block for the shard 0. From this cross-linked block, they determine the tip of the chain exactly as today: the longest chain.
Because the Beacon chain will never reorg deeper than the last finalized block, also the Ethereum 1.0 chain will never reorg deeper than the last finalized Ethereum 1.0 block.
Analysis
Since we assume an honest 2/3 majority in the Beacon chain, we will have also an honest 2/3 majority in the attestation committee of shard 0 (with striking likelihood). Since the committee is honest they will not do any attestations of cross-links, which will cause deeper, unjustified reorgs, neither will they support special privately mined chains. Hence, the protocol is safe and add security compared to the normal POW security.
Also, since the attestation happens with a delay of one epoch (5-6 min), they will not be able to influence the tips of the POW chain and not be able to give some advantage to some miners.
Implementations:
Beacon chain:
In order to realize the above-mentioned concept, there are no changes required to the Beacon chain(phase 0) at all, (only phase 1 as described in “shard 0 client” later)
Ethereum 1.0 chain:
For the Ethereum 1.0 chain, only the fork-choice rule is affected. No other changes are required. For the fork-choice rule the Ethereum 1.0 client would have to talk to a Beacon chain client. Based on the data from the Beacon chain, the client would calculate the epoch_boundary_blocks, the cross-linked blocks and the cross-linked-finalized blocks. With this information, the new fork choice rule will be easy to follow.
Shard 0 client:
The shard 0 client implementation would contain logic for the attestation committee of shard 0. That means that this client would have to
- be aware of the Beacon chain and the Ethereum 1.0 chain,
- calculate the
epoch_boundary_blocks, thecross-linkedblocks and thecross-linked-finalizedblocks - based on these blocks send out the attestation for the right
epoch_boundary_blockof the Ethereum 1.0 chain for the validators at the right slots.
And that’s it already! Hope to get some feedback and questions.