See above. Meaning that both blockchains have to approve a name before Blockstack accepting it as valid.
Would reduce the chance of needing a migration for Blockstack (I guess it’s some sort of a worst case?).
And if not, it should at least make the migration easier (because there’s (hopefully) at least one blockchain left that proves the authenticity).
The model we’re currently exploring is where Blockstack can process multiple blockchains to construct the global state where each namespace is tied to a single blockchain. Meaning that say the .id namespace is defined to run on Bitcoin and a .eth namespace is defined to run on Ethereum. Blockstack can process transactions from both blockchains and update the state of namespaces, but the consistency of any given namespace depends only on the underlying blockchain it was defined on.
Yes, it can potentially help with a migration because you’ll only need to migrate the namespaces where the underlying blockchain failed. However, it’s important to think about the root namespace. The root namespace defines the namespaces and is needed to bootstrap the system. Currently, we use the Bitcoin blockchain for the root namespace. A failure of the blockchain where the root namespace is defined is a bigger problem than failure of an individual namespace. So we really need to ensure that we use the most secure blockchain for the root namespace even if the blockchain has lower bandwidth/throughput.
Can’t we just say a valid Blockstack transaction is when the transaction in blockchain 1 and 2 went through in the Blockstack protocol?
Should work with the root namespace too. Or did I get something wrong?
You’ll get into ordering and consistency issues. Trying to build a total ordering of operations from N blockchains (where N can be 2) is much more complex than building a total ordering of operations where the operations can only be announced on a single blockchain.