The eth1 -> eth2 transition

sorry if this is a dumb question, but how does the client know which shard an account/address is on?

Would it be possible that all of ETH1 moves out to other shards after the transition and the new chain gets rid of of the “legacy baggage” kind of like a hermit crab that has grown out of its shell?

What is meant by the EE term?

Also an actual question about the transition. I assume that when the post-state root of the final block is uploaded everyone (every account) can upload their Merkle Proof to the ETH2.0 chain to prove that they had X account with Y code and for every storage address we access we also prove their value (or use the value currently known by ETH 2.0) - I assume this is the witness data.

In optimizations it is mentioned to “clear out dust accounts”. The dust accounts are unlikely to even prove their balance on ETH 2.0, so would this optimization get done by default because it is unlikely that the account will get touched again, or the “owner” of this account will upload the witness data to ETH 2.0 to get their low balance back?

Possible but highly unlikely - there are too many dapps and business built on eth1.

EE is Execution Environment - new terminology for shards .

Not quite. It’s a subtle difference, but Execution Environments are not the same as shards. A single shard may have more than one EE, and an EE can exist in multiple shards. The concept of EEs is an abstraction of the EVM; basically, the Eth2 system will be able to handle more than one virtual machine. The most-used EE will likely be the EVM (eWASM), but in my understanding other EEs could exist that model state execution in different ways, e.g. a UTXO-based system, or Libra, or lots else.

There isn’t actually a great single resource that explains EEs (at least that I’ve been able to find), likely because its still an evolving concept. My current understanding has come from cobbling together bits and pieces from various places (and is probably incorrect to some degree!). If anybody more knowledgeable than I about EEs wants to create such a resource, I’m sure the community would greatly appreciate it :slight_smile: .

1 Like

Exactly, this is a great explanation.

For those who want to dive deeper, here are some currently available resources from the ConsenSys Quilt team (they are actively working on EEs):

Hope this helped.

3 Likes

This seems like a pretty risky assumption. Why not coordinate with ETH1 to have an upgrade where the difficulty bomb goes off on a specific block? In other words, instead of going up exponentially, make the difficulty “infinity” on block X, such that block X+1 can never be mined, and hardcode X as the final ETH1 block in ETH2.

If anyone wants ETH1 to continue they could bring out an alternate fork that removed the difficulty bomb entirely. Certainly no miner would upgrade to a version of Ethereum 1 that would stop them from mining.

The problem with this is that we want the ETH1 chain to continue getting mined for a short while after the fork to prevent 51% attacks that try to cause confusion about what the fork block is.

(The in-protocol block rewards for mining those blocks would of course not get included, but the EF could easily subsidize 100 block rewards)

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.

That’s a good point, I hadn’t thought of it.

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 :thinking:

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?

How can one get involved and participate in helping develop the ‘Eth1 chaindata state -> Eth2 EE’ transition ?

A few avenues:
Scheduling our first call - get involved here
Catch up with the current work - which links to a group and community call

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:

  1. 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?

  2. 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)?
    image

  3. 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?