Interesting paper. However, it’s hard for me to see the exact use case of this.
If you migrate an ERC20 contract across system borders, the accounts associated with token ownership are likely not present on the other chain.
Exceptions here are probably sharding and hard forks.
If this is to be used for sharding, you would have to ensure that no changes are made to the contract state on the source chain - otherwise, clients could end up making decisions on the target chain relying on an expired (source) contract state. That is, you need to implement a mutex.
If you are shifting a contract from a permissionless* to a permissioned chain, you still end up trusting the validators of the permissioned chain for both liveness and safety. You might as well trust them to relay to you the latest contract state from the permissionless chain?
Even more so, if you’re going the other way round.
(Actually, that’s essentially what you are suggesting, no?)
You should also check out PeaceRelay (https://github.com/KyberNetwork/peace-relay) or cross-shard yanking (Cross-shard contract yanking).
On another note: if you are updating static references to other contracts (e.g. libraries), how do you efficiently prove that the contracts are equivalent? I mean, you could have manipulated the state of the library, but I would only find out if I manually verify this.
Perhaps you could add a hash of the bytecode of each referenced contract to the “main” contract before migration (or even upon first deployment n the source chain)? This would at least allow users to quickly check if any of the libraries have been modified.
- note: you can have public permissioned chains, hence public == permissionless
[EDIT: fixing typos]