In my last post, I was talking about how connecting all blockchains is the final stepping stone for mass-crypto adoption. Here I want to outline the technical building blocks with which this idea can be implemented.
Since I see a lot of downsides to having one large uber-blockchain connecting all others, I will focus on a token-LESS solution. This would have several advantages:
- No need for an additional token.
- Users can “remain” on their blockchain.
- No need to trust a centralized third party.
There are a couple of downsides to such an approach however. Since there is no uber-blockchain or a centralized party ensuring the connection, there needs to be enough liquidity between two blockchains to be connected. If I want to transfer funds from the Ethereum to the Bitcoin blockchain, for example, I need someone who, at the same time, wants to go from bitcoin to ether. For these two large blockchains, you will always find someone willing to go in either direction, but what about from Ethereum to a smaller blockchain or a small blockchain to another small blockchain? While I will be laying out a way on how that could even be solved, I want to stress that liquidity is the key economic factor in such a cryptographically secure multi-asset network.
Basic Building Blocks
Let’s look at the three very basic building blocks that are needed to connect any two blockchains:
- Multisignature feature (Multisig);
- Hashing functionality; and
- Time-lock functionality
Let’s work through each of these three and combine them into a larger single picture.
1. Multisig is an old and well-trusted concept that can be compared to a shared checkbook with multiple required signatories. A multisig transaction allows for the enforcement of arbitrary joint signature rules. In the case of a cryptographically secure, off-chain, multi-asset, instant transaction network (COMIT) one would use 2-of-2 multisig transactions for which both signers have to sign a transaction to become valid and be accepted by the network (an example of this will follow right after). This means a multisig transaction established between two parties needs to be signed by both so that its outcome becomes valid and can be accepted by the network.
In the picture below, a transaction was created with 1 BTC as input; however, in order to get it out, both parties (Alice and Bob) have to sign the transaction:
2. Hash functions are standard cryptographic concepts. These are one-way functions to convert arbitrary data (in our case a secret “s”) into a unique hash “h.” This hash h can then be shared safely without anyone being able to compute the secret s used to create it. This allows us to build a hash-lock transaction which will only unlock the funds with the knowledge of the secret s. In order to route across different blockchains, we need the same cryptographic hash function available in the smart contracting language of each blockchain participating on such a route.
In the picture below, someone put 1 BTC into a contract, but Alice can only take it out once she has the secret (which she normally would get from Bob).
3. Time-lock is a simple requirement for funds to be locked up until a future date. Blockchains are found to have two different time-locks: relative and absolute. Absolute time-locks will lock a transaction output until a fixed point in time in the future, whereas relative time-locks will lock a transaction output relative to an event or a point in time. That is to say, a relative time-lock rather defines a time span than a specific point in time. Time-locks are a requirement for trustless payment channels, and relative time-locks are recommended as they allow for indefinitely open payment channels.
In the example below, someone put 1 BTC in, but in order for Alice to get it out, she has to wait a predefined time.
Putting It Together
If we go ahead and combine these three building blocks, we get something called HTLCs (Hashed Time-Lock Contracts) whose states can be updated on a multisig basis. HTLCs combine the concept of a time-lock for refund purposes with a hash-lock. If the recipient can provide the secret s for the hash-lock before the expiry of the time-lock, he will be able to retrieve the funds. Otherwise, the sender can safely reclaim the funds. In case one party wants to update the HTLCs state, he needs the other party’s approval (signature). This is how the multisig function comes into play.
In the example below, Alice put 1 BTC into the contract with Bob. Bob can either take the 1 BTC out if he gets the hash from Alice within a predefined time, or Alice will get the funds back automatically after that predefined time has past.
Two HTLCs can be coupled with each other resulting in something called atomic transactions. To do so, the recipient first generates a secret s and computes its hash h. Subsequently, the recipient will share this hash h with a sender who in turn creates the first conditional transaction, i.e., its output is (hash-)locked by h. This output can only be redeemed with the knowledge of the secret s.
In layman’s terms, this would mean that if Bob wants to send Alice 1 BTC and wants ETH in return, they could open two payment channels (one with BTC and the other with ETH) and couple them with a hash h. Bob sends Alice BTC as long as she sends him ETH. In case either one backs out, the original amounts would just be returned.
The Full Route
Now we can stack an arbitrary amount of transactions onto each other as every node in this chain can safely use the same hash to create a transaction which is also conditional on knowing the secret s. This hash is initially shared with the sender, who will then subsequently send a conditional payment to the first node requiring knowledge of the secret s to redeem it. Each node in the route can then safely forward the transaction while adding the same condition to the transaction redemption. Through the use of HTLCs we can guarantee that either all of the transactions via this route get fulfilled or all payment channel transactions will be unredeemable. No trust has to be put in any of the nodes in the middle of the route. In the end, you have a chain of transactions which all depend on the same secret to be fulfilled. When the receiver takes the last transaction and uses the secret to redeem the money, every other node will see the secret that was used and can then fulfill their own incoming transaction.
After the secret s has been shared across the route, every payment channel will then settle the transaction back into the channel. This is done by updating the payment channel’s state to the final balances and then invalidating the HTLC transactions by revealing the invalidation key k to the payment channel counterparty, which will eventually make the transaction complete.
The time-lock mechanism is used as a refund mechanism in case of an intermittent routing failure. The time-locks need to be stacked from receiver to sender to make sure no one is able to cheat by having a shorter period than someone after him/her and thereby being able to pull out first.
Conclusion
These transactions can span within the same blockchain, but can also go cross-chain as long as you find someone who is willing to transact on both blockchains. This is where the concept of liquidity and routing comes in. To go back to the beginning where we thought about connecting two low-liquidity blockchains we see now, that we actually don’t necessarily transact between those two directly. By using stacked payment channels one after the other, money could flow from one low liquidity chain to a high liquidity chain and then to the final low liquidity chain.
This concept connects payment channels to a large network that is now:
- Cryptographically-secure (relies on cryptographic standards),
- Off-chain (like the Lightning- or Raiden-Network) ,
- Multi-Asset (cross-chain),
- Instant (no need for a transaction to settle on the blockchain as updates only happen between the parties until it gets broadcasted)
- A Transaction Network, such as COMIT.
In the next blog post, I will talk about the concept of liquidity and Liquidity Providers (LP) and also on how routing through such a network could work.
This is a guest post by Dr. Julian Hosp, the co-founder of TenX and co-author of the whitepapers of TenX and COMIT. The views expressed are his alone and do not necessarily reflect those of Bitcoin Magazine.