State migration between subnets and subnet migrations

[adlrocha]

We need to support for users to be able to migrate their state hosted in a subnet to some other subnet. If a subnet is dying, or its security guarantees are reduced, users will look to escape their subnet and keep operating somewhere else. This may not be straightforward and we'll need to narrow this down:

• What do we understand for by state (actor state? balances? etc.)
• How can we verify that the state being migrated is valid?
  Maybe we could attach a succinct proof of all state changes so it can be easily verify that the state is valid.

It may also be the case that ahandle subnet wants to "migrate to some other parent", due to locality reasons, or because it no longer trusts its parent to orchestrate it system interactions.

[adlrocha]

Adding a proposal shared off-band in slack for completion:

We can use similar approach to the one used for hot migration of databases: we first don't accept new messages to the original subnet ID and we wait for all queued message to the old ID to be processed; we migrate/merge the subnet (or/and the state) to it's new location in the hierarchy; we spawn the subnet in its new location with it new ID (according to its new position in the hierarchy).
This could also be used to migrate actors between subnets.

[adlrocha]

Also, in order to avoid potential attacks over the migration protocol where a subnet tries to migrate state (or itself) to two different locations in the hierarchy (can we call it a replay migration attack?), we should not only bind the state to the deterministic discovery ID of a subnet (i.e. the SubnetID in our current implementation) as this ID changes after the migration. The state tree of a subnet should also be binded in some way to a unique ID that allows anyone in the hierarchy to determine the "uniqueness" of the subnet/state tree independent of its current location.

This identifier be invariant to the location of the subnet. We can think of the discovery ID that we currently have as the file_path, and we need to come up with an identifier analogous to filesystem's inode.

[aakoshh]

I don't know if the migration of state is a meaningful operation in the general case.

Subnets are possibly special purpose vehicles, with their own actors that are only deployed on them, doing some work that can't easily be uprooted and continued on another subnet which has none of the supporting machinery. Or maybe they are part of a larger sharding scheme, based on some criteria that means a certain account is expected to reside in a certain shard, otherwise it won't be found by the application.

Maybe like MMOG some accounts need to be migrated between subnets to balance out the load between them, but this could be the concern of the larger application managing the migration, rather than built into the consensus itself.

[adlrocha]

Yes, you are right. We may not need to be able to migrate fine-grained state from a subnet (this is application-specific), but we may want to migrate the full-state (i.e. the whole network), to some other location in the hierarchy.

An example use case that would need this feature (albeit futuristic) is the "inter-planetary migration of networks" mentioned in the following HC with VDF design doc. We may have a network operating on the earth whose parent is the EarthNet and that wants to be migrated to some other planet. We need a way to "decouple" this subnet from the earth, and "couple" its state to the root network of the new planet so it can keep operating in a new location and with a new parent. Juan brought up this example a few times in our CoLo, and there seem to be several potential use case that would require this feature.

(That being said, I don´t think we need this in the first version of IPC, we can probably ship something without it)