As a way of realising some benefit from the beacon chain even before phases 1 and 2 of eth2 are complete, the proposal for a finality gadget to provide PoS-derived finally to the eth1 PoW chain has been proposed. This idea rests on eth1 nodes including a beacon chain light client to allow their fork choice rule to incorporate finality information from the beacon chain.
However, if eth1 clients already need to include light clients on the beacon chain, why stop there? Couldn’t the random beacon be used to select a leader on the eth1 chain as a block proposer, and cut out PoW entirely? This could happen independently of the ongoing phase 1 and phase 2 research and allow eth1 to gain more of the eth2 benefits sooner (shorter and more evenly spaced block times, stronger security assumptions at lower issuance, greatly reduced energy requirements, lower barrier of entry to validators increasing node diversity).
It seems as though given the scale of ambition for eth2 and a number of significant unsolved problems such as state rent/stateless clients, it may still be years before a wholesale migration to eth2 is possible. Therefore in the mean time are there good reasons not to expand the scope of the ‘finality gadget’ aspect of the beacon chain to include eth1 block proposal and eliminate proof of work mining sooner?
Who are the block proposers, and how do you manage updates to that set? The whole point of PoW is that anybody can join, if they can perform enough hashes! If you get rid of the hashes, you need another way of deciding which nodes are acting in the best interests of the network.
Interesting idea but I think there are some non-trivial things standing in the way.
Being a beacon chain validator has been intentionally designed such that it has low hardware requirements.
Eth1.x block creation has a much higher hardware requirement.
So we can’t just use the Eth2.0 beacon chain validators as block creators because that isn’t what they signed up for, nor is it something that they are guaranteed to be able to do. This leaves us with having to effectively implement all of the same mechanisms that the beacon chain uses to manage the validator pool.
I’ll admit I haven’t thought much about this topic so there might be something obvious I’m missing, but I don’t believe there is a simple route to do what you propose.
Thanks. I can see that many of those wishing to become beacon node validates will not have the computational resources to be eth1 block proposers. I guess I was imagining a subset of them would do however. Given the low requirements for the beacon chain, many of the current eth1 miners may well choose to become beacon node validators. They could signal their intention to be block proposers as well as beacon chain validators by depositing to an eth1 contract.
Yes. However, to my understanding, the main reason for these low hardware requirements are that validators can easily switch to between the shards. I think, if we would run the beacon chain with only one shard - the eth1.x shard - then the hardware requirements are not soo bad.
Yes But the choice between the wasteful POW and higher hardware requirements in a “1.x shard” system would be an easy decision for myself.
@Pintail. Thanks for opening this thread. Today, I had a quite similar idea, and I am happy that you already started the discussion. I would imagine a system, where we
keeping eth2.0, as it is.
migrating the current ETH 1.0 chain in a second redeployment of a beacon chain with one single shard and a little bit higher hardware requirements.
Of course, the long term plan would be to merge these two beacon chains with new technologies like stateless clients etc…
It seems worthy of putting some thought into this. Switching 1.x to POS would give the current 5000+ node operators a way to make money from staking, and get rid of the massively wasteful GPU mining. Anyone running an ETH 1.0 node now could easily spin up a 2.0 Beacon node on the same machine without increasing hardware requirements much if at all.
It’s basically going back to separating Casper from Sharding, and implementing Casper POS first. Huge Benefits if it’s possible:
Faster, consistent block times. With 1559, almost all transactions go through in < 6 seconds.
Better 1.x interoperability with 2.0. Easily solve the 2-way bridge problem, plus massive Phase 1 data availability is realistic.
Probably simplifies the transition to 2.0 (just add new shards under the 2.0 umbrella). Validators could choose whether to stay super-light and validate only 2.0 blocks, or also validate 1.0 blocks. Perhaps the incentive would be that full validators could stake the same 32 ETH for 1.0 and 2.0 blocks and get paid double. Over time, 1.x stuff could be slowly deprecated as most new contract development happens on 2.0.
The vast majority of ETH would be staked directly or via pools, creating even more system security.
Yes the 1.x state would keep growing for the next 3-5 years, but network usage should slow as 2.0 is adopted. The new cool semi-stateless “Beam sync” reduces the syncing issues dramatically.
Some centralization would occur as someone with 32000 ETH gets chosen as the next block proposer 1000 times as often as someone with 32 ETH. That’s no worse than the current situation though.
Now that the ice age is going to hit in July 2021, that might be the natural time to switch over to full POS. ETH1 clients would have plenty of time to integrate the Beacon node and Phase 1 would likely be production-ready by then as well.
It’s an alternative roadmap anyway.
I think that there could still just be a single production beacon chain. The second one would be a testnet for 2.0 technologies.
But the choice between the wasteful POW and higher hardware requirements in a “1.x shard” system would be an easy decision for myself.