As a person that does not write smart contracts and just hold ETH with the anticipation that it may someday be used as currency for daily economic uses, what are the things that I should do and when is the best time to do them after everything is said and done before the ice age hits, post-eth1?
For example, will I need to generate a new address based on eth2 chain and make a transfer of all my ETH from eth1 chain’s address to this new eth2 chain’s address?
For example, will I need to generate a new address based on eth2 chain and make a transfer of all my ETH from eth1 chain’s address to this new eth2 chain’s address?
You don’t need to do this. If you want to take advantage of the benefits of eth2, you may want to move your funds into a wallet that supports other eth2-based functionality eventually, but you do not strictly have to and there is no time limit.
I can’t understand it.What is voting for its ancestor at number TRANSITION_HEIGHT .
What is ancestor mean?
“Ancestor” means an earlier block in the same chain.
Many thanks for replying.
So it is like when vote algorithm selected 1001(1000 is the specified block height ),it would be back to 001?
No, if the vote algorithm would have selected block 1001, it instead selects its direct parent, whose block number is 1000.
If the balance of an Eth1 account will remain the same in the Eth1 EE of Eth2, how the Beacon Chain balances will be awarded?
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 
.
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.
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 
How do you see this happening? Is there an in-protocol way we could do this? From ETH2, perhaps?