OneLedger

Cross-chain Compatibility

Written by OneLedger | Jul 10, 2018 7:38:00 PM

We’ve just released our initial OneLedger MVP version. It has basic blockchain functionality and a subset of the identity management features. For our next release, we are focusing on finishing up our support for cross-chain transactions. This will allow accounts in Bitcoin and Ethereum to swap their tokens.

Actually, that is a slight exaggeration. The idea that tokens can seamlessly travel around from one chain to another is appealing, but certainly non-trivial. In the digital realm, concepts like ‘assets’ really just exist as bits, ones and zeros.

Those bits only have meaning when they are within the system that created them. That is, if you access one big system like Google’s Gmail to create a user account, none of the other emailing systems know about that account or can do something meaningful with it. They might be able to access Gmail with the information you supplied, but that is it. If you want to move that information you have to export it in some common format, then import it into the next system, if those features are available.

Tokens have that same property. Bitcoin tokens live in Bitcoin; Ethereum tokens live in Ethereum.

Now if a token were removed from its original system — if it were burned — then another token might be created in a different system to replace it. That would be a real transfer of assets between chains. That’s hard to accomplish, particularly if the destination chain can’t guarantee that another chain might not really burn the asset.

An alternative to moving tokens around is to lock them in one place, then mirror them in another chain. That is great, but it also requires trust between the chains which ultimately boils down to trust between the developers. That latter case is tricky in that most blockchain code is just an implementation of the protocol, so chains can be running on the works of many different, unrelated, programming groups.

And that’s where it gets really tricky. Byzantine algorithms are predicated on not trusting individuals. What matters is that the whole system comes to a ‘consensus’, no matter what the individual nodes believe. It’s the collective opinion that matters.

Clearly the best way to ensure that assets are locked on a chain is to use the chain’s own protocol to transfer the assets to a specific account. The problem though is who owns that account? If a single node on another chain owns it, we end up trusting that node. We don’t want to do that. The whole chain need to own the account, and only the whole chain can access it, not any individuals. That’s very complicated.

Given that the underlying issues for cross-chain transactions are tricky, and not fully explored yet, we decided to focus our initial implementation on well-understood technical principles. We know that we can use hashed timelocks as basic primitives on several different chains. With these, we understand how to synchronize transactions between chains. Given the issues with assets not existing outside of their chains, we decided to pursue our initial cross-chain mechanics as what should really be called synchronized swaps.

That is, if two parties agree on an exchange rate and initial volumes, they can trade assets cross-chain between their respective accounts. One person gets some Bitcoin sent to their account in Bitcoin, and in exchange another person gets some Ethereum sent to their account in Ethereum. It isn’t quite as exciting as the bitcoins and ether jumping from one chain to another, but it nets out to nearly the same results, with the benefit that we don’t end up placing misvalued trust in intermediaries.

We’re almost finished with adding this functionality to our MVP base. We hope to have it implemented and fully tested over the next few weeks. As always, we’ll ensure that it is easily demonstrated in our self-contained Docker environment so that curious people can run it directly on their own hardware.