There’s been a Cambrian explosion of blockchains in recent years, supporting everything from cryptocurrencies to logistics systems. But by and large, they have been developed in silos and it’s hard to share information between them. Now researchers are trying to build new channels to help these networks speak to each other.
A blockchain is a way to keep records of transactions or exchanges of data without relying on a central authority. Multiple users maintain a copy of the ledger and must come to agreement on any new additions by following a protocol called a consensus mechanism, which makes it hard for anyone to make fraudulent changes. But beyond these basic ingredients, they often have little in common. The kind of data they share, consensus mechanisms, network designs, and a host of other characteristics vary wildly depending on what they’re used for.
While this diversity of approaches means blockchains can be tailored for a wide range of applications—from monitoring industrial equipment to hosting smart contracts that automate insurance payouts—it also means they struggle to share information. “We’ve got these blockchains that are closed worlds that cannot interact with each other,” says Stefan Schulte, and a professor at the Hamburg University of Technology in Germany.
As organizations use them to support a growing number of business processes, says Schulte, this inability to communicate could become problematic. If a logistics company tracks their shipments on a blockchain that can’t talk to the one they use to make payments it could cause plenty of headaches.
Solving this problem is a booming area of research though, and last month Schulte and his colleagues presented a potential workaround at the IEEE International Conference on Blockchain Computing and Applications. Their approach relies on blockchain relays, which are essentially smart contracts running on one blockchain that can verify events on another blockchain.
If a user wants to transfer an asset they first destroy, or “burn,” it on the source blockchain, which is typically done by sending the asset to a user address that doesn’t exist. This transaction also includes details of the asset and which blockchain and user they want to send it to. Third parties monitor the source blockchain for these burn transactions and then send them to the relay for a small reward, which verifies the burn transaction and recreates the asset on the new blockchain.
The challenge, says Schulte, is that these verification processes invoke transaction fees that can quickly make the approach impractical. So they created a verification on-demand system where the relay assumes transactions are valid unless they are disputed. To prevent fraudulent submissions, the third-parties have to put up a stake of cryptocurrency to take part and if they submit an invalid transaction others can dispute it and win their stake as a reward. The approach reduces the cost of running the relay by as much as 92 percent, says Schulte, but at €5.77 ($6.52) it’s still far from a solved problem.
And while this scheme might work well for public blockchains whose data is readily accessible, such as those behind the Bitcoin and Ether cryptocurrencies, there are a growing number of private blockchains that are not so open. These networks may house sensitive commercial data that can’t be broadcast to the public and are often more tightly controlled.
Communicating between these closed systems can be tricky, but a potential workaround is to create trusted gateways to relay details of cross-chain transactions, says Gang Wang, an applied research engineer at Emerson Automation Solutions in Texas. In a paper due to be presented at the IEEE International Conference on Blockchain next week, Wang and colleagues describe a way to use a “trusted execution environment” (TEE)—a secure area of a processor—to create a trustworthy link between any two private blockchains without relying on a third party.
Another way is to create a “blockchain of blockchains.”
The second gateway then passes details of the transaction to participants on its network who verify if it is valid and can be executed on that blockchain. If enough say it is, the gateway passes the message back to the first blockchain where the assets are unlocked and the transaction goes ahead. If the transaction isn’t valid they instead send a release message that tells the first blockchain to abort the transaction.
Wang says the approach is well-suited to applications requiring high-speed transfers. Rather than waiting for the target blockchain to add the transaction to its ledger, which can take seconds or minutes depending on the network, the gateway checks if it is valid in milliseconds.
One other way of facilitating transfers between blockchains is to create a “blockchain of blockchains,” says Rafael Belchior, a PhD candidate at the Instituto Superior Técnico in Portugal. This is the approach being pursued by projects like Polkadot and Cosmos and involves a central blockchain dedicated to passing messages between others.
Each of the subsidiary blockchains can have their own security model, consensus mechanism and specific use cases. The catch, says Belchior, is that all of these blockchains must be built using the same development framework, which includes a shared communication protocol. As a result, the approach can’t interface with existing blockchains or those built using other tools.
Achieving efficient and secure interoperability between any two blockchains still faces considerable challenges, says Belchior. There are still no standards for how blockchains should talk to each other, he says, and it’s difficult to evaluate and compare interoperability solutions, because there are no tools to systematically analyze interactions across multiple blockchains at once.
Perhaps most crucially, though, there are no formal security models that spell out the precise specifications required to guarantee a secure interoperability scheme. “I think only after this kind of work could you have a more stable place to start designing your interoperability solutions,” says Belchior.
Source: Spectrum
