Cross-chain Explained: Solution Briefing

Published in

DINNGO

6 min readDec 31, 2019

In Technical Challenge, we described a light-weighted implementation of achieving cross-chain trading. Through the HTLC-based atomic transaction set, the orders on different chains can be matched and settled. However, the idea has several challenges to deal with, including

Delaying redemption
Order matching
Common solution
Time cost and fee cost.

Based on the mechanism and giving a solution to the problems mentioned above, we propose our cross-chain trading solution, Portus.

Atomic transaction set

Let’s recall the transaction set of Alice and Bob’s trading in the Technical Challenge.

tx_1: Alice -> Bob   hashlock(p_A) timelock(t_1)tx_2: Bob   -> Alice hashlock(p_A) timelock(t_2)

The two major problems of the aforementioned transaction set are the delaying redemption and the requirement of the receiver.

The problem with the delaying redemption is that the redemption initiator is one of the participants. Applying a third party that is not beneficial to initiate the redemption can prevent the initiation from being controlled by the participant.

tx_3: Charlie -> Alice   hashlock(p_C) timelock(t_1)tx_4: Alice   -> Bob     hashlock(p_C) timelock(t_2)tx_5: Bob     -> Charlie hashlock(p_C) timelock(t_3)

In this transaction set, hashlock(p_C) is a hashlock created by Charlie. Charlie is the third party we mentioned above. When the transactions above are broadcasted, Charlie is the one that is able to initiate the redemption. Alice is able to claim her funds from tx_3, and Bob is able to claim his funds from tx_4. After Charlie claims his funds by revealing the preimage p_C, the most beneficial action for Alice and Bob is to claim their funds. Neither Alice or Bob is able to benefit by delaying the redemption. Alice, Bob, and Charlie play different roles in the structure of exchange. Alice and Bob are users. Charlie is the operator of exchange.

Another problem is the requirement of the receiver. As we mentioned, when users place their orders, the counterparty is not yet decided. Considering this problem, we give different definitions to Alice and Bob: Maker and Taker. With the three main actions of trading in an exchange, the transaction can be revised as below.

tx_E: Exchange -> Taker    hashlock(p_E) timelock(t_E)tx_T: Taker    -> Maker    hashlock(p_E) timelock(t_T)tx_M: Maker    -> Exchange hashlock(p_E) timelock(t_M)

tx_E is the matching completion transaction, tx_T is the taker transaction, and tx_M is the maker transaction.

Matching and withdrawal

There are several phases in a complete process.

Maker order settlement
Taker order settlement
Exchange matching processing
Withdrawal

As the initial order is provided by the maker, we provide an option for the maker to lock up the balance in the first place instead of waiting on line. The following procedure will then be completed automatically without the maker’s participant.

In phase 1, the maker settles the maker order by signing and broadcasting the maker order transaction tx_M.

In phase 2, the taker provides the order information and proceeded by the exchange. The exchange then replies by the order transaction. Taker settles the taker order tx_T.

In phase 3, the exchange reveals the preimage p_E to redeem the funds and create and broadcast the matching completion transaction.

In phase 4, taker and maker are able to redeem the funds in Taker hashlock(p_E) and Maker hashlock(p_E) by the revealed preimage p_E.

Canceling

As the maker should have the right to cancel maker order, tx_M should be able to be refunded.

t_M is a specific time that the funds in Exchange hashlock(p_E) timelock(t_M) can be refunded to Maker after t_M.

For the taker transaction, the refund process should also be considered. In a common situation, tx_E and tx_T are created only when the orders are matched, so the refund function should not be necessary for tx_T. However, if the maker refunds tx_M after the order is matched (tx_E and tx_T are created), and exchange not yet redeem tx_M by revealing the preimage p_E, taker’s funds will be locked in Maker hashlock(p_E). Though this is not a regular situation, we still need to design a refund mechanism for the taker to cancel the transaction.

The timelock set in tx_T also influences the withdrawal time for the maker. The taker is able to refund the transaction after t_T. On the other hand, the maker has to redeem the transaction before t_T, or the taker might take back the funds.

After applying the solution of the transaction set, most of the problems we mentioned can be solved. However, two issues are identified.

Every transaction has to be settled on-chain, which is very time-consuming and fee-consuming.
Every category of trading pair requires the implementation of the handler of settling the atomic transaction set. In other words, as the system expanding the support on a new chain, develop effort grows in a quadratic rate.

Layer-2 multi-chain relayer

Talking about the problem of time-consuming and fee-consuming, it is quite similar to the difficulties of the early decentralized exchange. Users propose their requests for placing, claiming, and canceling an order. Order manager and HTLC Atomic Transaction (HAT) handler will then proceed with the request and create corresponding transactions to the chain. Every order needs to be settled on the main chain, and every order needs to be matched through a command sending to the smart contract.

The user’s request is processed by Order Manager and converted to corresponding transactions by HTLC Atomic Transaction(HAT) handler. Transactions will then be settled to chains.

This problem can be eased in several different ways. In DINNGO, we solved this problem by using a hybrid structure, which is coordinating the off-chain data and on-chain settlement. Though Bitcoin does not have such a powerful resource to support the complicated verification and the following settlement, developers implemented its layer-2 solution to solve the scalability problem. HTLC is also proposed under this demand, Lightning Network.

When the user proposes order, the information is processed by the matching system and settled right away onto the chain. Every action takes the confirmation time and fee to process. By applying a layer-2 structure, the temporary trading information does not require being settled into the main chain.

After the request is processed by the Order Manager and HAT handler, the transactions are settled in a Layer-2 service instead of directly settled on-chain.

Besides reducing the cost and processing time, the extra layer is able to deal with the problem of expanding the trading pair to a new chain. Similar to the routing scheme that is proposed in Lightning Network, the payment between Alice and Bob does not require a direct channel being constructed between them. As long as a route is available between them, such as Alice to Charlie, Charlie to Dave, Dave to Eve, and Eve to Bob, the transaction can be processed. Therefore, the trading pair does not require the chains involved to have the same hashing function (an available route is still required), and not every two chains need to construct an independent trading system.

The Future

The technology of blockchain is being developed at a fast pace. However, the main idea of blockchain is preventing itself from being controlled by any specific person. This makes upgrading and migration of a chain difficult. These frontiers built their system, gained users and proved their values. The upcoming systems will be improved by solving issues in different ways, in order to meet the needs in different scenarios. In light of the decentralized execution nature of each blockchain, there might not be an omniscient chain in the future. Instead, finding a way to communicate between the existing ones, and even the upcoming is more reasonable. Under this circumstance, an exchange is one of the most important infrastructures of blockchain technology. That’s also the reason why we believe that it shouldn’t be another centralized service. For a mature decentralized service, different blockchains are able to provide different resources for operation, and interoperability is the last piece of the puzzle. To achieve the interoperability among the entire blockchain network, Portus aims to provide an idea of a light-weight solution by guarantee the atomicity of the transaction set from different chains.