Who will administrate Blockstacks's Virtualchain in case of long-lived fork or blockchain migration

Meta
#1

I have just finished reading those three provided white papers and I can’t quite get the topic of virtualchain administration during a long-lived fork of the underling blockchain as well as during blockchain migration.

As stated in the “Extending Existing Blockchains with Virtualchain” paper (sorry if the copy paste from the pdf is not well formatted):

To detect long-lived forks, a node runs multiple processes that subscribe to a ge- ometric series of prior block heights. If a process at a lower height derives a different consensus hash than one from a higher height, then a blockchain fork must have occurred then, and all processes at higher heights have potentially-divergent state. This means all running nodes will be in a separate fork set from bootstrapping nodes. Reconciling the fork sets requires human intervention, since irreversable actions taken by the application may be based on now-lost state transitions. Fortunately, long-lived forks are rare and severe enough to be widely noticed [2] [3] [4]. This means that when they happen, users and administrators can determine which transactions were affected, and come to concensus about which state-transitions need to be re-sent.

and

To begin, the application administrator(s) announces a future block after which the current blockchain will no longer be used and sends special “migrate” transactions to both the current and the new blockchain (to announce the migration process). The administrator(s) (a) acquires a lock on the new blockchain, (b) writes the current application state (excluding historic state transitions) to the new blockchain, and © releases the lock on the new blockchain and opens up the new blockchain to new transactions. Virtualchain verifies that the migrate transactions are signed by the same principal and verifies that the last-known state on the old blockchain is consistent with the consensus hash announced on the new blockchain. This enables seemless cross-chain migration.

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)?

#2

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 :slight_smile:

#3

Thanks for your reply! It is now more clear that until Bitcoin’s blockchain hardforks (as soft forks won’t hurt Blockstack’s virtualchain / temporary forks are unlikely to exceed 10 blocks length) or Blockstack nodes reached consensus on self-hardfork, the system seems to be quite stable (Bitcoin’s hardfork is unlikely to happen) and central authority independent.

Though, my hunger to understand this technology in depth is not over. Have to read the newly released paper before asking other questions :slight_smile:

#4

@ion Which new whitepaper are you referring to? Can you link me to it? Thanks!