Address space unification.

[zie1ony]

Given recent development of 2.0 and new VM, I noticed that long awaited address space unification is not really happening... Let me unpack that.

Currently Casper offers three different address spaces:

• Account Hash - represents an account,
• Contract Hash - represents a single contract version,
• Contract Package Hash - represents a pack of Contract Hashes that (mostly) share the same storage.

We have learned that using Contract Hashes to represent the contract in another contracts is not a good idea. It's simply not practical. Consider following scenario:

• There is a (CEP18/ERC20) token contract that hold token balances for accounts and contracts.
• There is another contract with Contract Hash 0xVersion1 and Package Hash 0xPackage.
• If Contract Hash is used as a balance key, then in token contract would has a record in a balances dictionary: 0xVersion1 -> 100.
• Now if contract is buggy or simply needs an upgrade, then it would be replaced with a new version 0xVersion2.
• But the data in the token contract points to 0xVersion1, so tokens are not accessible to 0xVersion2, and require a migration, which is not always possible, expensive and wrong architecture in general.

The solution is to use Contract Package Hash as a key. This way balance key is 0xPackage -> 100 and even after an upgrade of the contract, tokens are accessible. This is why CEP18 uses Key to represent an address.

What I expected in terms of address space unification in 2.0 is that Account Hashes and Contract Package Hashes would be unified under a single type. Instead Account Hashes and Contract Hashes are unified under a single type (EntityHash), and Contract Package Hashes are left as they were.

I think this is missed opportunity for solving actual problem.