In today’s core devs call, Vitalik Buterin and Danny Ryan discussed how the coming proof-of-stake beacon can be used to finalize the existing proof-of-work chain.

On Friday’s core devs call, Danny Ryan and Vitalik Buterin discussed the tentative plan to use the proof-of-stake, Casper FFG-implemented beacon chain as a finality gadget for the existing proof-of-work (PoW) chain.

(Note: If a block has the property of finality, that makes it immune to reversion in the case of a 51 percent attack.)

Buterin explained that using the beacon chain for finality on the Ethereum 1.0 chain “would essentially give [the PoW chain] the same security properties that the original pre-beacon chain Hybrid Casper FFG was going to give.”

When asked to estimate an expected timeline for rollout, Buterin did not offer a specific date, but said, “Before sharding and before state execution stuff.” In terms of the Serenity rollout, that translates to somewhere after Phase 0 and Phase 1. Though, he added, “It would be part of the beacon chain code immediately. It’s just that no one would necessarily listen to it immediately.”

Ryan added, “We would want to see stability on the beacon chain, and kind of the increased security there,” before actually using the beacon chain for block finality. Even once the gadget’s security and stability is proven, it would still ultimately be up to clients and validators whether they choose to make use of the finality gadget.

Implementing a finality gadget to the PoW chain could do something to assure those in the ecosystem who are concerned that the hash power of ASIC mining rigs leaves the network more vulnerable to 51 percent attacks. Though, it should be noted that while finality achieves increased security against block reversion attacks, it does nothing to address the ability of a 51 percent attacker to censor the creation of new blocks.

Back in December, Alexander Herrmann, veteran Ethereum researcher currently working for Gnosis, posted a proposal on Ethresear.ch to use the beacon chain for Ethereum 1.0 block finality. Herrmann’s proposal suggests that so long as Phase 0 beacon chain clients adhere to some fairly basic/unobstructive specifications, all that would be necessary on the PoW chain is a modification of the fork-choice rule to communicate with the beacon chain.