Per the Virtualchain paper, Blockstack's virtualchain is fork*-consistent. There is no "longest chain" rule like there is in Bitcoin. Instead, your client software selects which fork it wants to follow (currently, there is only one).
Can somebody please explain this using the example from some hypothetical situation. I am aware of Onename migration but I don't understand how is that possible.
For example, I can control my Onename identity that is ultimately registered in the Bitcoin blockchain using Blockstack's virtualchain protocol implementation. Then somebody from Onename top management team decides that Bitcoin is not suitable anymore for their needs and decides to migrate to AnotherCoin. How will I control my identity in that case, if my keys are from Bitcoin assets, not AnotherCoin's?
Do I understand correctly that being a Virtualchain specific implementation, Blockstack Inc can decide which blockchain to choose and migrate the whole PKI and DNS (with all registered namespaces)?
No, this is not possible. Blockstack Inc cannot force you to run different software. Moreover, Blockstack Inc cannot force your node to change which fork it follows (fork*-consistency means that multiple forks are allowed, so long as nodes in different forks ignore one another).
However, what Blockstack Inc can do is select the software's default parameters, including which blockchain the node follows. The software is open-source, so each individual has the power to fork the software and change the default parameters as well. Migrating from one blockchain to another would almost certainly require a hard-fork in the consensus rules, and we have not implemented the blockchain-migration opcodes yet (see below).
That said, it is entirely possible for there to be two divergent Blockstack histories on Bitcoin today. No one can stop you from forking off of Blockstack's current history and creating a divergent history, and no one can stop you from staying on Bitcoin if Blockstack Inc opts to migrate off of it. Similarly, no one was stopping you from continuing to use Namecoin and the
u/ Namecoin TLD even though Onename migrated away. The consensus hash construction enables each node to identify which fork it is reading, so in the limit each user could choose which history they want to follow. Whether or not using a different fork is useful in practice is an orthogonal matter.
Anyway, we haven't implemented the blockchain-migration opcodes because by the end of next year, we hope to have an on-chain voting mechanism like Bitcoin's miner signalling in place where users can decide to do things like migrate to a different blockchain. The high-level idea is to create a
.vote namespace with uniformly-priced names that have a very short lifetime. Users would burn Bitcoin to cast ballots, and if users consistently and overwhelmingly vote to activate a particular feature over a fixed interval of time, the feature automatically activates (i.e. Blockstack Inc would release the software with the features deactivated, and users would vote to activate the features). Users can cast as many ballots as they want, but since each one costs a fixed amount of BTC, the chain history will show how strongly the Blockstack "economic majority" wants something to happen. Doing disruptive things like migrating chains or changing the consensus rules would be put to a vote in this way. We're still fleshing the protocol out, so feedback is of course welcome