We’re already at part four of our ARK Core blog series covering the upcoming transaction types and features built into ARK Core v2.6. Next up, we’ll take a closer look into one of the most highly anticipated new transaction types, Hash Time-Locked Contracts (or HTLC for short) — what they are, how they work and how you can use them.
Over the past few weeks, we’ve been exploring all the amazing new features built into our upcoming Core v2.6 upgrade. Following our previous posts covering the introduction of ***Schnorr’s Multisignatures, ***Multisignature Server and ***Multipayments ***it’s time to turn our attention to HTLC. Let’s explore them together…
Creating a platform that is user-friendly with a focus on security has always been a signature of everything we’ve built at ARK. Ensuring that the funds of all ARK users are protected and secure from bad actors and potential network attacks is of the highest priority at all times. With that in mind, the ARK Team feels at this stage there is a necessity to be cautious and to not include HTLC in the ARK Mainnet Core 2.6 upgrade, due to potential loss of funds in the event of a double-spend attack initiated by a network rollback and a lack of finality (read more on this below). We actively encourage all community developers to rigorously test the current implementation on Devnet to help improve and refine the functionality of HTLC before the Mainnet release, and earn bounty rewards for doing so!
As previously revealed in the ARK Developer Roadmap blog, we are planning on building a new consensus algorithm for ARK to strengthen the key components of the Core, written from the ground-up and inspired by Tendermint BFT with stronger finality guarantees. The HTLC transaction types will be introduced to ARK Mainnet once the new consensus has been tested and implemented next year. The ARK Core developers will commence work on the new consensus algorithm after the launch of ARK Core 3.0.
In the meantime, you can still get started with testing the new HTLC implementation. It’s currently available on Devnet so that developers can get a head start building apps that will use HTLC or simply help us improve or report bugs related to HTLC in exchange for bounty rewards.
Stay tuned to blog.ark.io for updates on this.
HTLC transactions enable two parties to exchange tokens safely and securely at the protocol level, removing the need to trust an individual who could potentially be a bad actor and withdraw from a prior agreement once they have received their tokens. HTLC is a core requirement for cross-chain atomic swaps and ARK Core 2.6 is the first step toward interoperability within the ARK Ecosystem.
A Hashed Time-Lock Contract is a set of transaction types that permits a designated party (the “sender/seller”) to LOCK funds by disclosing the secret of a hash. It also permits a second party (the “recipient/buyer”) to CLAIM the funds once in possession of the secret used to initiate the LOCK, or after a timeout is reached enter a REFUND situation.
As per the above, the HTLC implementation within ARK Core introduces three new transactions:
HTLC_Lock — This transaction enables a sender to lock tokens within their wallet behind a hashed secret password using a one-way hash (SHA-256).
HTLC_Claim — This transaction enables the recipient to claim the locked tokens once the sender has revealed the secret password.
HTLC_Refund — This transaction allows the sender to unlock previously locked tokens within their wallet in the event of a dispute or the recipient not claiming them.
Let’s take a look at each transaction more in-depth:
When sending an *****HTLC_Lock* transaction to the ARK Public Network, a number of parameters are required for the transaction to be accepted.
amount — Amount of network currency that will be locked.
secret_hash — A hash of the secret. The same hash must be used in the corresponding “claim” transaction.
expiration_type — Type of the expiration. Either block height or network epoch timestamp-based.
expiration — Expiration of transaction in seconds or height depending on selected expiration_type.
recipient — The recipient's address.
Once the*** HTLC_Lock transaction has been applied, the sender will no longer have access to the locked tokens and consequently can only be unlocked with the HTLC_Refund transaction once the configured expiry time has elapsed. The expiration time will commence as soon as the** *HTLC_Lock transaction has been forged on the network.
Note: All locked tokens will still contribute to your delegate’s vote weight providing the recipient has not claimed them.
The*** HTLC_Claim ***transaction requires two parameters that are required for the transaction to be accepted on the ARK Public Network.
lockTransactionId — HTLC_Lock transaction id, to serve as a reference.
unlockSecret — In order to issue CLAIM transactions, this must be made visible on the chain. Its hash must be equal to HTLC_Lock.secret_hash.
As the recipient address is specified in the*** HTLC_Lock transaction, only the desired recipient can use the HTLC_Claim transaction to retrieve the aforementioned tokens. The recipient can only process a HTLC_Claim ***once the *HTLC_Lock *transaction has been forged on the ARK Public Network.
Retrieving locked tokens can be achieved with the HTLC_Refund transaction. Only one parameter is required for the transaction to be accepted on the ARK Public Network.
The HTLC_Refund transaction can only be initiated once the configured expiry time in the HTLC_Lock transaction has come to completion and can be initiated by anyone (funds become unlocked and again spendable on the sender’s address).
So why do we need HTLC? Since the initial whitepaper release in 2016, a major staple of the outlined vision for the ARK is to create interoperability functionality within ARK’s ecosystem. The implementation of the HTLC transactions within ARK Core 2.6 is the first step to introducing true interoperability between ARK based chains with atomic swaps.
To understand a basic flow of atomic-swap HTLC contracts interacting with each-other check the diagram below. Here we provide an example transaction where Alice is swapping 300 ARK for 3000 NOS with Bob.
**Step 1
**Alice chooses a secret password (e.g: gtMcn7XGlIbq). She hashes the password using a one-way hash (SHA-256) to generate the following hash:
0f128d401958b1b30ad0d10406f47f9489321017b4614e6cb993fc63913c5454
Alice sends a transaction on the ARK blockchain with the instructions:
**Lock 300 ARK from my account for Bob, with the following password hash: **0f128d401958b1b30ad0d10406f47f9489321017b4614e6cb993fc63913c5454
**Step 2
**After waiting for Alice’s transaction to appear on the ARK blockchain, Bob sends a NOS transaction using the same password hash, the instruction reads as:
**Lock 3000 NOS from my account for Alice, with the following password hash: **0f128d401958b1b30ad0d10406f47f9489321017b4614e6cb993fc63913c5454
**Step 3
**Alice sees that Bob has initiated a transaction, and claims his 3000 NOS, using the secret password (gtMcn7XGlIbq) known only to him. Alice claims the NOS with the following transaction on the nOS blockchain:
**Claim 3000 Nos from Bob, the secret password is (gtMcn7XGlIbq) for the password hash: **0f128d401958b1b30ad0d10406f47f9489321017b4614e6cb993fc63913c5454
The password is verified on the NOS blockchain to match the password hash, and the funds are transferred to Alice.
**Step 4
**Bob sees the secret password from Alice’s blockchain transaction. He can then make the claim of 300 ARK from Alice by sending a transaction on the ARK blockchain with the following instructions:
**Claim 300 ARK from Alice, the secret password is (gtMcn7XGlIbq) for the password hash: **0f128d401958b1b30ad0d10406f47f9489321017b4614e6cb993fc63913c5454
The password is verified on the ARK blockchain to match the password hash and the funds are transferred to Bob.
Voila! The above details how a transaction can be performed across two separate ARK based chains by using HTLC transactions. If either Alice or Bob was uncooperative during this transaction, a *HTLC_Refund *transaction could be initiated once the expiry had elapsed resulting in all tokens being unlocked.
Security Deposit for Rentals
It’s standard practice in any rental market for a retailer to request a security deposit as a means of protection in the event that the user damages the equipment owned by the retailer during a loan period. This is ordinarily achieved by the retailer recording the user's credit card details before the loan period commences. Once the user returns the loaned equipment, an assessment of the loaned goods will take place to check for damages, and a charge will be made against the users’ credit card in the event that damage exists. With the assistance of HTLC, retailers can take advantage of the same use-case with the added trustless security of blockhcian technology.
HTLC transactions can provide a similar use-case to the rental market by enabling a user to send an HTLC_Lock transaction to the address of the retailer for a pre-agreed fee. The funds would be locked with a password that both parties agree to. Once the loan period is over and the equipment assessment has taken place, the retailer can issue an HTLC_Claim transaction to retrieve the funds to cover the cost of any damages. If there are no damages, once the expiration time has come to completion, the user can send an *HTLC_Refund *transaction to unlock their funds.
The introduction of HTLC creates an opportunity for users to create payment channels between each other. Payment channels enable users to clear and confirm payments immediately off-chain whilst still possessing the security provided by blockchain technology through HTLC transaction types, similar to that of the Bitcoin’s Lightning Network. To further enhance the capabilities of payment channels, new transaction types could be created on the ARK Network such as ‘Payment routing’ which could be used to create specific bridgechain payment channels, for example.
As stated in the disclaimer, HTLC will not be included in the ARK 2.6 Core release on Mainnet due to concerns with loss of funds with a double-spend attack in the event of a network rollback. Here we will provide an example scenario detailing that rationale.
Consider the following:
Alice engages in a transaction with Bob swapping 300 ARK for 3000 NOS using HTLC.
Alice locks 300 ARK for Bob and Bob locks 3000 NOS for Alice.
Alice claims her 3000 NOS and Bob claims his 300 ARK.
The transaction is successful and both parties are happy.
A bad actor then creates a network fault on the ARK Public Network consequently resulting in the ARK blockchain to rollback to a time previous of the above transactions.
During a network rollback, the reverted transactions are put back into the transaction pool waiting to be forged again. If Alice’s initial HTLC_Lock transaction is still yet to be forged, she could now create a new transaction with the same NONCE to overwrite her previous HTLC_Lock transaction, preventing it from being forged again. The double-spend attack is now complete. Alice now owns the 300 ARK she previously sent to Bob and the 3000 NOS Bob sent to her.
This scenario is just one example that makes the implementation of HTLC on the ARK Public Mainnet with ARK’s current consensus algorithm problematic. Whilst network attack vectors such as double forgery are possible on the ARK network, ensuring the safety and security of all ARK users’ tokens is paramount as we continue to drive the platform forward.
So what’s the solution to this problem? In short, a new consensus algorithm.
By designing and building a new consensus algorithm for ARK Core, we can make a variety of improvements across the board to further enhance the functionality and security of the ARK platform that will allow us to tackle attack vectors such as double forgery in a more proficient manner.
In relation to HTLC, a new Tendermint BFT inspired consensus algorithm will enable ARK Core to achieve absolute finality as transactions are processed on the blockchain. This method is incredibly robust against double-spend attacks and would provide a layer of confidence and security when engaging in HTLC transactions.
Stay tuned to blog.ark.io for updates on this.
Read our new whitepaper! Follow us on social media ( Twitter|Facebook|Reddit ), join our community ( Slack | Discord ) and stay tuned to our blog on Medium and on Steemit.