As we mentioned in Current Landscape, several projects aim to achieve interoperability by implementing a general solution. However, these solutions are still under development. Instead of relying on them to be done, we proposed a structure to provide interoperability for dApp by making the state-changing transactions to be executed simultaneously.
Blockchain can be considered as a database that is maintained and executed in a decentralized way. In a database system, a transaction is defined by matching the properties of ACID, Atomicity, Consistency, Isolation, and Durability. Atomicity stands for the indivisible and irreducible series of database operations that either all occur, or nothing occurs. Consistency represents that any transaction should only change the affected data in an allowed way, in order to guarantee the database constraints are not violated. Isolation describes that transactions should not affect each other’s execution. Durability guarantees that the result of committed transactions should survive permanently.
Since each blockchain is an independent database. While we are trying to perform transactions and coordinate among different chains, consistency, isolation, and durability can be guaranteed by their original design. Atomicity is the only property that requires extra constraints.
Atomicity
One single transaction can only affect the state in one single blockchain. Therefore, when we perform the operation among plural chains, multiple transactions are required to give sufficient power. In this case, we need to combine several transactions that are located on different chains into one. In other words, how do we guarantee the atomicity of these transactions?
Bitcoin is one of the most representative blockchain protocol. Although the development of its protocol is still active, Bitcoin is limited to handle complex functions due to its key concept of simplifying the structure to serve the purpose of a payment system. The functionality of Bitcoin is implemented by a scripting system, which is a simple, stack-based system. To meet the needs of producing conditional payments for different services, Hash Time Locked Contract is able to give extra conditions by using hashlocks and timelocks.
Hash Time Locked Contract
Hash Time Locked Contract (HTLC) is introduced to achieve the implementation of Lightning Network. The purpose of an HTLC is to allow for a global state across multiple nodes via hashes. bip-0199 describes a script for generalized off-chain contract negotiation implemented by HTLC.
HTLC transaction is a transaction that can be redeemed in two ways: Hashlock and Timelock. Hashlock is performed through a hash function. The locker locks the transaction by a hash value, while the solver needs to provide the seed corresponding to the hash value. The seed is called the preimage, which can be considered as the key to the lock. Timelock does not require extra information to solve. It will be unlocked when the predefined time expires. Therefore, the destination of timelock is usually the sender, which triggers a refunding process.
Bitcoin
As mentioned in bip-0199, HTLC is implemented through a series of script operations. For operators, there are several options in Bitcoin’s implementation. The hashing function can be RIPEMD-160, SHA-1, SHA-256, HASH-160, or HASH-256. To redeem the HTLC transaction, the spender needs to provide the preimage for the hashlock as the key to solve the hash puzzle. Another way is to wait until the defined timelock expires.
Besides Bitcoin
While the mechanism is proposed in Bitcoin, other chains are able to support it in other ways, such as the implementation of a smart contract. Take Ethereum as an example, we can write a simple contract to simulate the behavior of HTLC.
The following code illustrates a basic implementation of HTLC.
The contract implements an HTLC that is able to handle ether. ERC20 tokens can also be applied by some minor modifications.
Atomic transaction set
Through the implementation of HTLC, an atomic transaction set can be implemented like:
tx_1: Alice -> Bob hashlock(p_A) timelock(t_1)tx_2: Bob -> Alice hashlock(p_A) timelock(t_2)
p_A is a preimage provided by Alice. t_1 and t_2 are the expiration time that corresponding senders are able to refund the transaction. The execution sequence can be separated into several phases: settle, redeem and refund.
- Settle
- Alice created tx_1 with hashlock(p_A) and timelock(t_1). The transaction is then broadcasted to the network.
- Alice provided the hashlock(p_A) to Bob.
- Bob acknowledged that tx_1 was broadcast.
- Bob used hashlock(p_A) and timelock(t_2) to create tx_2 and broadcast it. Notice that t_1 should be greater than t_2.
- Redeem
- Alice revealed p_A and claimed the funds from tx_2;
- As p_A was revealed, Bob was able to claim the funds from tx_1 as well. Since that t_1 is greater than t_2, Bob should have time to perform the redemption.
- Refund
- When t_2 expired, Bob would be able to refund tx_2 to get his funds back.
- Alice would also be able to refund after t_1 expires.
When tx_2 is redeemed by Alice, Bob is able to have sufficient information to redeem tx_1. On the other hand, if Alice does not reveal p_A, Bob is unable to get the funds from tx_1. This satisfies the rule of atomicity, that operations either all occur, or nothing occurs. Note that the mechanism above does not require tx_1 and tx_2 to be located on the same chain. The only requirement is that the hashing function of hashlock should be the same, so the revealed preimage p_A can be applied to unlock the same hashlock(p_A). For example, Bitcoin supports RIPEMD-160, SHA-1, SHA-256, HASH-160, and HASH-256. Ethereum supports Keccak-256(SHA-3), SHA-256 and RIPEMD-160. By choosing SHA-256 or RIPEMD-160, both Bitcoin and Ethereum are able to support the same hashlock. In this case, a cross-chain atomic transaction set is achieved.
Challenge
Although everything seems perfect, the mechanism still has some problems when being applied to practical usage.
Delaying redemption
Let’s recall the transaction set of Alice and Bob.
tx_1: Alice -> Bob hashlock(p_A) timelock(t_1)tx_2: Bob -> Alice hashlock(p_A) timelock(t_2)
As we mentioned above, when performing the redemption, Alice is the one who is able to decide whether the transaction set is executed or not.
Order matching
Matching orders refer to how exchanges methodically pair orders from buyers and sellers at compatible prices. If one user wants to buy a quantity of cryptocurrency and another wants to sell at the same price, their orders match and a trade is made. However, the receiver must be determined when a trade is created. This is why users are asked to sign transactions after their order is matched, which seems quite annoying to them.
Common solution
Considering that the preimage should be capable to solve the corresponding HTLCs that are created on different chains, these chains need to support a common hashing function. It is a difficult problem to solve when we try to extend the supporting chain in the system. As the system grows, the intersection of the hashing function becomes smaller.
Time cost and fee cost
To guarantee that every transaction is properly relying on another, each transaction must be put on the chain before they can be acknowledged and matched. The settling process will be very time-consuming on most of the chains.
Another problem is the fee cost. Every order placement requires an actual transaction settlement. Therefore, the user has to pay the transaction of each order on every corresponding chain, even if they are not matched.
Along with the clarification of the challenges, the concept of Portus becomes clear.
In our next article, we will share the solution briefing. Stay tuned.
Links
- Official Website: dinngo.co
- Twitter: https://go.dinngo.co/twitter
- Contact Us: support@dinngo.co
