Our Thoughts on Blockchain Interoperability

Defining Interoperability:
Consider two Ethereum blockchains E1 and E2. We assume them to be Ethereum-like to keep things simple in this discussion.
By interoperability we mean that, Smart contract S1 on chain E1 should be able to trigger actions (call functions) in another smart contract S2 on E2, and vice-versa, in a trust-less manner.

We further assume that digital signature technology is compatible across all blockchains. Meaning an address on one blockchain is also recognised on another blockchain.

Now, consider two cases and what interoperability means in each of them.

Case1: Consider Two pre-existing Ethereum-like blockchains e1 and e2
We want to design some open source code/protocol that makes e1 and e2 interoperable. This means that:
1. State changes on e1 should trigger state changes on e2
2. State changes on e2 should trigger state changes on e1

Case2: Consider one Ethereum-like blockchain E and another custom-blockchain C
We want to design C such that C and E are interoperable. This mean that:
1. C should be able to trigger actions on C based on state changes on E
2. C should be able to trigger actions on E based on state changes on C

Lets discuss Case 1 first:

Since e1 and e2 already exist and have pre-existing development communities, we must propose a solution that does not require making changes to L1 of either blockchains, otherwise it will be very difficult to get our solution live. We must only use the L2 layers since they are open to use anyhow we want.

Consider when State changes on e1 should trigger state changes on e2.

Since state data from e1 is external to e2, an externally owned account (EOA2) on e2 must digitally sign this data and put in on e2. A smart contract on e2 could also in theory do the same job, but this smart contact itself would need to be provided the state data from an EOA.

Currently, the only known decentralized solution to push external data on a blockchain is oracles. Hence, EOA2 is essentially an oracle. I must re-iterate that what I am essentially saying here is this — for two pre-existing blockchains, it it not possible to be interoperable unless they are willing to use oracles.

If you are thinking about making changes at L1 to solve this, then that is similar to Case 2, which we will now discuss.

Case2:

Since we are developing C ourselves, we can make changes at L1 itself. We can design C such that it requires running an E node along side C nodes. This will enables C to read all state data from E and trigger actions accordingly. Reading E state data and making sense of it could be baked right into the core protocol of C itself, and all C nodes shall run software that implemets this.

This solves the 1st problem of reading E data and triggering actions on C.

But, when it comes to writing data to E, we again run into the same problem as Case1 ⇒ you can’t push external data to a pre-existing blockchain without using oracles.

So, next steps?

1. Explore Oracles
2. Design an L1 plugin that all pre-existing blockchains can implement, that makes them read data from another blockchain.