Driving Chains

Posted by OneLedger on Jul 30, 2018 3:45:00 PM

One of the more interesting aspects of the OneLedger MVP is how we are using the blockchain to drive other chains. Satoshi’s original paper focused on the idea that transactions were primarily about moving assets, which was reflected in the structure of the data.

So, a send transaction in one of the chains moves inputs to outputs; fungible assets to new owners. That allows the blockchain to act as a system of record for specific assets like crypto-currencies, but there is so much more that the technology can achieve.

For our MVP, we use the transactions to act as the communications pathways between two users interacting on two different external chains. That is, Alice transfers money on one chain if and only if Bob transfers money on another chain. Underneath they use hashed timelocks to ensure safety and reliability of the transfers, but if they did all of the steps themselves they would find it tedious and prone to failure.

Instead, we’ve automated it. And we did this by extending the meaning of transactions. In that sense a transaction can be an indication that one of the parties would like to perform a swap, it could mean that the mechanics are setup on one side or the other, or is could pass the underlying information over to the other party to allow processing.

This simple method of ‘driving’ the behaviour on other chains is extremely powerful. It can be used for swaps, but there is a huge range of other problems that can be solved this way. Of course the downside is that the chains become large, and they contain transactions that are temporary in nature. That is a significant problem, but that leads to the next direction in our MVP development: side-chains.

For the next stage we will jump into the development of both the side-chains and channels, focusing on how we control scope for the data within chains. In this way we can achieving the scalability of the OneLedger chain by partitioning the transactions across multiple chains.

So, this will allow us to build a solid instructure for our protocol that supports the design and architecture for our Business Modules. The possibilities are endless.