Problems with interoperable blockchains & hybrid exchanges

I’ve spent months researching on interoperable blockchains trying to figure out how to create one. In this post I have combined all my insights in hope to shed some further light on the topic.

Interoperable blockchains are the future: A brief

Interoperable blockchains basically allows users to interact with multiple of different types to communicate with each other.

Take atomic swaps for example. Atomic swaps allow for two blockchains to “speak” to each-other and allow for two parties to securely trade cryptocurrencies between the two blockchains (for example between Bitcoin & Litecoin).

But atomic swaps are just the start

Many new projects have come up that have promised to offer more than just atomic swaps. These projects promise to create a blockchain that can actually speak and interact with blockchains and allow developers to extend the functionality of these chains.

A typical interaction with an interoperable blockchain would be one wherein you have a have a balance of multiple other cryptocurrencies (like Bitcoin) and you can create smart-contracts that’d interact with these cryptocurrencies (so for example, you can probably write a smart-contract that does something with Bitcoin! which you otherwise couldn’t do with the native Bitcoin blockchain)

Couple of projects in this space include

• Wanchain
• Blockstream’s liquid
• Polkadot
• Ethereum’s Plasma

Each whitepaper brings forward major breakthroughs and revolutionary concepts, full-filling the promise of creating a scalable interoperable blockchain.

These blockchain projects come with a big promise. That they’ll be able to create a system that will be able to speak to other blockchains and which will truly be decentralised.

But the question is, will they be successful? Will they be able to include blockchains like Bitcoin? I think not. And here’s why.

What’s happening under the hood behind these interoperable chains?

In Ethereum’s plasma, things are pretty straightforward. A side-chain following the plasma protocol will ask a user to deposit ether into a smart-contract controlled and monitored by the side-chain.

Once a deposit is made and locked in the Ethereum smart-contract, pegged tokens are immediately issued to the user on the side-chain and then used within the side-chain itself.

Whenever a user wants to withdraw ether from the side-chain, the pegged-tokens are burnt and the ether is released from the Ethereum smart-contract and sent back to the user.

Take Matic.network for example. A side-chain based on Ethereum’s plasma that allows users to interact with Ethereum in a proof-of-stake model.

With Ethereum, interoperability is pretty simple because of the fact that Ethereum supports smart-contracts and you can write very complex logic to support your ‘interoperable needs’.

But what about blockchains like Bitcoin or Tether? Blockchains that don’t support smart-contracts-like functionality? Is there a way to properly lock funds and interact with these chains?

Let’s look at Bitcoin and dig deeper. How will an interoperable chain work with Bitcoin?

What many papers have proposed is something similar to Ethereum’s plasma.

You place your Bitcoins in a wallet controlled by an interoperable chain and you’ll immediately get pegged tokens on the interoperable chain that’ll represent those Bitcoins.

But the question is this. How does one ensure that the Bitcoin wallet provided by interoperable chain is secure? The only way for you to have control over the funds from such a wallet was if you held the private key to sign transactions and spend from that wallet.

And this is the crux of the problem with interoperable blockchains. How can you prevent misuse of the private keys of a wallet controlled by the nodes in an interoperable blockchain?

After going through various solutions, I’ve summarised my findings and what different people are doing below.

1. Have few nodes manage the private keys

This is what Blockstream mentions in their whitepaper. https://blockstream.com/strong-federations.pdf

However the main issue with this is that it is very much centralised as one would have to trust Blockstream to not misuse these private keys.

2. Have many nodes keep pieces of the private key

In this case, the private key is split into ’n’ different pieces and distributed across ’n’ different participants.

At any point of time, whenever the private key needs to be recreated, the pieces are brought together and the entire key is reconstructed.

You can take this a step further by using a key-sharing algorithm like Shamir’s secret sharing algorithm and split the private key into ’n’ parts but only require ‘k’ parts (where k ≤ n) to reconstruct the entire private key.

However the problem here is that the once the private key is reconstructed, it can very well be misused by the node who has it. Which makes this system effective if only one transaction needs to be made as after that the security features of the wallet will be broken.

3. Have many nodes keep signature shares of the private key (n-of-n)

So this is similar to Shamir’s secret sharing algorithm however the private key is never reconstructed in the network.

If you have 20 nodes that keep 20 pieces of a private key, each node can sign the raw transaction using their own piece and create their own ‘signature shares’. Each ‘signature share’ can later on be used to create the final signed transaction.

The problem here however, is that this is a n-of-n solution, not k-of-n. Which means that even if one node drops out of the network, then there’s no way for the other nodes to gather all ‘signature shares’ required to create the final signed transaction. Hence effectively making the wallet inaccessible until the dropped node comes back online.

Some ideas to counter this could include penalising nodes that drop out. But again another question arises what is the penalty? Will the penalty be enough to recover the funds locked in the wallet?

4. Have many nodes keep signature shares of the private key (k-of-n)

This is what ideal case for interoperable blockchains should ideally.

There are implementations of k-of-n solutions where you can create a full signature using k signature shares from n shares, however these operations are not scalable as n increases and k decreases.

Researches from Princeton University have published an excellent paper where they’ve described a “threshold signature scheme”. They’ve even open-sourced an implementation of their algorithm in Android. However the main issue with their system is that as the number of participants increase, the time-complexity increases exponentially.

Which makes this system ineffective as you try to have more than 20 key shares.

Taking a few lessons from EOS

As of writing EOS is now exactly a month old. However to say it’s journey hasn’t been smooth is clearly an understatement.

The main issue right now is that EOS centralised? Is 21 block producers a good enough number for EOS to stay decentralised? What are the chances that block producers will not try to collude with each other?

What EOS & Bitcoin teaches us is that we should remove power away from humans and give it to the impartial machines.

However the question arrises that what if we did that fully how can we ensure.

Conclusion

To create a truly hybrid exchange, one needs to first solve the problems with interoperable blockchains first.

While we’re at the most interesting of times in the Blockchain era, I just don’t see how many of the ICOs/projects that claim to be creating an interoperable chain are actually able to create a fully decentralised system, without having tackled the issues with any of the four solutions above.

If you have suggestions or if you think I’ve missed out something, please feel free to let me know.