Yes, they could, but it wouldn’t be the default and so far we’ve seen a strong norm in the community (and other blockchain communities!) to follow defaults. I’m 100% in favor of having the version removing the bomb be considered the minority/unofficial/etc. fork.
Well, if exchanges and other stakeholders do, they will given that most of the value will be on that chain. Miners are already aware of PoS, so I’m not convinced that a final upgrade would make much of a difference. Also, we could pick a “final” block to be one that would already be quite hard to mine due to the difficulty bomb, in order to make the choice to not upgrade less attractive.
I still think that having the ability to send transactions on the Eth1 chain may cause significant confusion.
Perhaps a middle-ground approach where you leave the mining reward for enough blocks on the original chain while disabling transactions in blocks (i.e. you can only mine empty blocks) could work. I haven’t thought it through much, though.
You can also imagine a more aggressive difficulty bomb past the “final block”. For example, doubling the difficulty at each block. This way, you get the similar hashpower in ~6 blocks as you would in 100. You still have an incentive to 51% attack the last block, though… not sure how you get around that problem
How do you see this happening? Is there an in-protocol way we could do this? From ETH2, perhaps?
How do you see this happening? Is there an in-protocol way we could do this? From ETH2, perhaps?
We could, but it’s only 2 * 100 = 200 ETH of rewards, so I really do think it’s easier and cheaper for the EF to just pay this itself than for us to spend time figuring out exactly how to allocate eth2 block rewards in-protocol.
ETH1.0 contracts that will be transferred to ETH2.0 will have the same capabilities as the new contracts? is it better to create a new smartcontract without waiting for integration and airdrop the new tokens to the holders of the old ETH1.0 contract?
This seems to be a very disruptive upgrade, and I think such upgrade could be risky and make adversity effect to existing Ethereum community (e.g., miners). To make the upgrade least disruptive, why not implement an ETH2.0 client that
runs the beacon chain and designated shard chain (for validator); and
runs an upgraded ETH1.0 chain that follows beacon-chain-first consensus as defined in Boson consensus, and support cross-shard transactions.
This will make minimal changes to the existing ETH1.0 chain, while the ETH1.0 chain could maintain maximum backward compatibility (and thus retain existing values) and enjoy extra values brought by ETH2.0
The security (double spend) of ETH1.0 chain can be further protected by the beacon chain;
The ETH1.0 chain may act as shard chain 0 in the network, and it could interact with other shard chains that run standard EEs via cross-shard tx;
All existing miners could continue to mine on ETH1.0 (with existing infra such as GPU devices and pools) so that the existing infra and community participants (miners, pool runners, etc) will remain in the community;
The gas cost of IO-accessing operations remain the same so that existing dApp will be least impacted;
Most of existing tools and infra of ETH1.0 could run as before (infura, truffle, metamask);
Almost no offline time for the upgrade.
The extra cost is that a node needs to fully sync ETH1.0 besides beacon chain, but I think the cost should be acceptable considering the benefits.
The extra cost is that a node needs to fully sync ETH1.0 besides beacon chain, but I think the cost should be acceptable considering the benefits.
This is actually a very large cost. Right now the eth1 state is somewhere around 50 GB and rising, and with eth2 the state size reduces to ~600 MB in optimally packaged form in the worst case. We would sacrifice this entire gain by just attaching eth1-as-is to eth2. Additionally, it’s a majority opinion that eth1 in its current form needs to adopt some form of stateless client for sustainability.
Hence the preferred approach of (i) making eth1 stateless-friendly as a key part of the eth1.x initiative (already agreed), and then (ii) transitioning it to be a part of the eth2 system.
I am sorry I still cannot get the full point of the benefit of stateless client especially for eth1.x:
Suppose eth1.x is still PoW, would the stateless client still need to store the full ledger history (blocks)? Note that the block size for stateless can be about 10x larger than stateful one (using the data in [1]). Assuming average block size as 10K and block interval 15s, the per-year block size will be 20G for stateful client, but 200G for stateless. In such a case, would the benefit of saving the state be overridden by the extra storage cost of blocks?
The cost of storage actually decreases exponentially (about half per 14 months, see the below graph) while the size of the state grows linearly over time (assume the gas limit of a block is almost constant, e.g., 8M at the moment). So saving 50GB or more would be worth at the price of a disruptive upgrade over long term (e.g., after 2 years)?
Stateless clients also need data providers to generate witness and pack txs into a block. The data providers still need to store the full state, but it looks to me that the data provider market analysis is not complete and will it introduce any further risks or uncertainties?
