tl;dr: We can create a system where account state (e.g. all data associated with an address, including balance, tokens, etc.) regularly migrates between blockchains.
The point of using blockchains is not about blockchains. They do not exist just to exist. It's about the data they can carry and what options and guarantees can be provided by using blockchains as a carrier. Blockchains are a transport layer for data, if you will, or a wrapper, which provides interesting features, mostly about data reliability and trust. This data is usually formatted into transactions, which is a concept which differs from just saying "data records" because it implies business rules which govern when and why the data is valid. Pieces of code (both in the platform code and in the smart contract) which govern which transactions are acceptable, and after that, which blocks are acceptable, are collectively known as the "consensus code", and they are analogous to database constraints (like foreign keys, primary keys, uniqueness) and stored procedures.
The main thing to note is that that blockchains are of secondary importance to the data they carry. What we're really interested when looking in blockchains are not the blocks themselves but the data in them.
The second thing to note is that most modern blockchains have expanded the concept of an "address" as used in Bitcoin into "accounts", with rich state. In Bitcoin, an address had only one explicit piece of data attached to it: its balance (though it is implemented in a much more fine-grained way with UTXOs). In Ethereum and newer blockchains, an address effectively has a dictionary of data (or a small database) attached to it, which can be modified by smart contract code.
In Bitcoin, Satoshi introduced blocks to implement Reusable Proof of Work and created an incentive for miners to secure the network. And that's basically why blocks exist: they are a way of using basic human greed to implement a kind of a trustless system (where nodes don't trust each other beside the common algorithms they are all running).
Ethereum kind of took that notion and ran with it, introducing rich account state by the way, but still assuming blocks and transactions are a part of a single system and unseparatable.
Looking at it from a bit different angle, how about we make it all about state, and not about either data or blocks?
It's about account state, not transactions or blocks
Here's what I'm thinking about:
Account state is all the data associated with an account. It includes the account's balance (e.g. in Ether), but also includes everything else added to the account (e.g. balances of ERC20 tokens).
This state can be serialised into a single stream of bytes in a unambiguous, standard way. It doesn't matter exactly which way - it could be a well-defined strict subset of JSON. All that matters is that multiple implementations can read this state, do with it whatever operation is needed, and store it in exactly the same way.
This state does NOT have to be stored in the blockchain. Only proofs that a state exists need to be stored (e.g. digital signatures), but for practical purposes, because it's convenient for third parties to be able to read/verify the on-chain data, we'll assume that transactions contain instructions on how to modify the state, for example commands like "set key=value", "delete key", etc.
Transactions themselves must be ordered, and include ordering information in their data. This can be a nonce like an incrementing integer. They also contain a reference to the previous transaction.
Transactions also include a digital signature of the new account state after this transaction is applied to it.
When a transaction is accepted into a blockchain (e.g. it's "mined"), its ID receives a prefix identifying it as a member of this particular blockchain.
When verifying a new transactions for acceptance into a blockchain, one of the two things can happen:
If the "previous transaction ID" is also on the current blockchain, the new transaction is simply verified with it.
If the "previous transaction ID" is on an external ("foreign") blockchain, first it needs to be fetched from that blockchain, then the new transaction can be verified against it.
By making blockchains be about state and not about transactions and blocks, there are some neat things that can be accomplished:
There is no need to tie a particular account to a particular blockchain implementation.
There can be fast / efficient blockchains running all over the world without as much need for global synchronisation until a transaction switches blockchains. This could mean that an end-user is using a particular blockchain for its transactions because its fast for their current geographic region, then switches to a new blockchain when they move. Or it could mean that a particularly egregious user can choose to record each of his transactions into a new blockchain, forcing the miners to synchronise often.
Did I mention blockchains using this principle can be much faster than currently popular ones, because there's no need for constant global synchronisation? This is important.
In fact, when put in this way, why use blocks at all? Since transactions are themselves signed, the added layer of signing them again when compacted into a block does not add much. The primary purpose of having blocks is mining and RPOW-based creation of new coins. If the creation of new coins is done in a different way, perhaps a PoS (remember, this is all about accounts, nor blocks!), there's really no need for blocks themselves, and thus no need for the particular data structure of blockchains. (I realise PoS becomes immensely more complicated under this scheme).
So far, all this is basically a re-telling of my previous article in a less technical way.
Sharing account state among incompatible blockchains
Though it would be much more efficient and faster to use a "blockchain firmware"-based approach to this, I think the features I've described can be implemented within common blockchains which support smart contracts. Let's call such a system "Chainmail" because it needs a name.
But it would involve treating addresses and account state non-natively. In effect, most of the transaction handling infrastructure would need to be implemented with smart contract code. It would go something like this:
A smart contract would be created on a generic blockchain, let's call it "BCHAIN". It would have its native address and its state would basically be the state records of all transactions participating in the Chainmail system.
A third party software, probably a user's wallet, will create a Chainmail transaction, which references a previous Chainmail transaction for its starting state, contains instructions how to modify the state, and a digital signature of the resulting state. The hash of all this will be the "bare" transaction ID.
If the user chooses to publish his transaction on BCHAIN, the wallet will send it wrapped in a new transaction whose recipient is the smart contract from the first step.
If the Chainmail transaction references a previous transaction which is also on BCHAIN, this smart contract will validate the state against the old state and possibly accept it. If it's not, it will need a help of an external oracle to bring in the previous transaction in. Since we're only interested in current transaction state, there's mo need to recursively fetch all transactions belonging to this account.
If the transaction involves modification of multiple accounts, like in a cryptocurrency transaction (i.e. one account is debited, another credited), then both accounts will be pulled into the same chain, e.g. BCHAIN in this case.
I think that the described system works well to maintain and move an account's state across incompatible blockchains, but it does have an issue which needs to be resolved: how to ascertain which state, on which blockchain, is the "current one", i.e. the latest one.
A solution which comes to mind is to use a DHT mechanism which would keep track of where the latest state of an account is stored, i.e. for each key which is the account address, it would hold which blockchain stores its latest state - this information would need to be signed and trusted. I don't like this solution, though, since it proposes a globally synchronised database which I was trying to move away from. On the other hand, this requirement is less "heavy" than having all transactions ever synchronised in a single blockchain.
Sharing state among incompatible blockchains | Ecency
