Cross-L2 Bridge: Hashed Timelock Contract vs Delayed-Proved Timelock Contract

The Problem

Optimistic rollup (OR) is becoming one of the most promising scaling solutions for Ethereum (L1) that offers much less gas cost (~1/6 to ~1/30), and almost the same security as L1. By submitting the off-chain transactions and their results on L1, the expensive on-chain computation can be offloaded to off-chain OR. To make sure the on-chain results are correct, the OR L2 will open a challenge window to allow anyone to challenge the results and to gain rewards if the on-chain results are incorrect. One advantage of OR is that it could easily support EVM so that the user migration effort from L1 to L2 can be minimized.

Due to these merits, multiple ORs with EVM support are developed including Arbitrum and Optimism. This comes up with one imminent demand to transfer a token from one OR to another OR, e.g., from Arbitrum to Optimism. A user can resort to the existing standard token bridge created by the ORs, and route the token via, e.g., Arbitrum -> Ethereum -> Optimism. However, the method can be costly and time-consuming:

• The user has to pay two L1 fees including Ethereum withdrawal and Etherum deposit, which can be expensive;
• The withdrawal from Arbitrum -> Ethereum via standard token bridge generally takes 7 days.

As a result, with the growing adoption of ORs, we are expecting a strong need for a cross-L2 bridge that could

• Almost instant transfer between ORs
• Much lower cost
• Simple user interaction (e.g., one-time payment at source L2)
• Secure, i.e., only rely on the security of L1 and L2s themselves.

Hashed Timelock Contract

One solution to speed up cross-L2 transfer is hashed timelock contract (HTLC). An HTLC is a contract with the following information:

• sender
• recipient
• amount of a token
• expiration
• hashlock=hash(secret_A)

where secret_A is a secret that the user (called user A) generates and is unknown to anyone except user A.

Anyone can create the contract by generating the secret and supplying the token into the contract. To unlock the token, one of the following conditions must be satisfied:

• hash(preimage) == hashlock by recipient with preimage; or
• now >expiration by sender.

You can check here to learn the implementation details of HTLC. In the following, we will give some examples of HTLC.

HTLC: Happy Path

Suppose user A wishes to swap 1,000 XXX on source L2 with LP B for 999 YYY on destination L2 with a secret only known by A at the beginning:

1. User A creates an HTLC on source L2 with the desired token (1,000 XXX) to be swapped and LP B as the recipient (generally found and negotiated off-chain).
2. LP B checks if the source contract is correct and finalized, then LP B will create another HTLC with reversed sender/recipient, i.e., sender = B and recipient = A with the amount of token (999 YYY) that user A wishes to receive. An important note is that LP B will copy the hashlock on the source contract even LP B has no idea the secret is.
3. User A checks if the destination contract matches the user’s swap request and is finalized, then user A will unlock 999 YYY by revealing secret_A.
4. At this moment, LP B can learn the secret and unlock 1,000 XXX at the source contract, which completes the swap.

HTLC: Bad Paths

Note that there are a couple of bad paths

• In Step 2, LP B does not create the source contract. And thus, user A can refund its 1,000 XXX when the source contract expires; or
• In Step 3, user A does not reveal secure_A, and thus LP B can refund its 999 YYY when the destination contract expires.

Note that in both cases, the swap will be failed, and no one loses the tokens.

Pros and Cons of HTLC

Pros:

• Security: P2P, no pooled custodian
• Happy path: almost instantly
• Work on two independent blockchains

Cons:

• User needs to find an LP off-chain, which can be eased by an off-chain match engine
• User has to submit two transactions per transfer — one is at the source chain and another one at the destination chain.
• Cannot support smart-contract-initiated transfer (as a contract has no secret)
• Require LP with sufficient security assurance on L2. E.g., tx on L2 may be reverted or challenged.

Delayed-Proved Timelock Contract

To address some cons of HTLC, especially enabling instant transfer with simple user interaction (e.g, one-time payment at source) and smart-contract-initiated transfer, we could resort to recently developed delayed-proved timelock contract (DPTLC), which was originated from the idea of Vitalik, and later be improved and modified by community members(credits @vbuterin, @amritkumarjain, @qizhou, etc).

A DPTLC is a contract with

• sender
• (REMOVED) recipient
• amount of source token
• (ADDED) amount of destination token
• expiration
• (REMOVED) hashlock
• (ADDED) destination L2 smart contract address

which removes recipient and hashlock fields of HTLC, and adds the amount of destination token the user wishes to receive and the target L2 contract address that the DPTLC trusts and confirms if any LP completes the transfer at the destination.

Similar to HTLC, anyone can create a DPTLC by supplying the source token, and the token can be unlocked only if

• now > expiration by sender; or
• proof from target L2 contract by an LP that the transfer is bought by the LP at destination chain

The second condition can be achieved as follows:

1. The LP buys the DPTLC at the destination L2 smart contract trusted by the DPTLC by supplying the destination token.
2. In the same buy tx, the destination token will be transferred to the user, while the smart contract will append a receipt({hash_of_DPTLC, LP_address}) into the local contract Merkle tree.
3. Anyone is able to push the root of the tree from destination smart contract -> L1 -> source chain DPTLC via standard L1 <-> L2 message passing. Note that although L1 -> L2 message passing can be delivered almost instantly, the L2 -> L1 message passing generally takes 7-days to complete.
4. The LP can prove the bought action by proving the receipt with Merkle proof and thus can unlock the source token that the user locked.

Example

The above graph illustrates an example of a successful transfer, where user A wishes to swap 1,000 XXX on the source chain for 999 YYY on the destination chain. The steps of the transfer are:

1. The user creates a DPTLC on the source chain with the trusted destination L2 address 0xDDDD.
2. Once the DPTLC is finalized, anyone (here LP B) can buy the contract by supplying the destination token (999 YYY), and the buy receipt is appended to the on-contract Merkle tree.
3. Now, anyone is able to notify the DPTLC on the source chain about the updated root, but it will take at least 7-days to complete.
4. After 7-days, LP B can claim the source tokens by submitting the receipt proof.

Demo on Testnet

You can find the demo of the DPTLC on both Arbitrum testnet (on Rinkeby) or Optimism testnet (on Kovan) here.

Pros and Cons

Pros:

• Instant transfer with single user transaction
• No off-chain matching (instead, can use reverse fee auction)
• No further security assumption on L1/L2

Cons:

• LP takes a long time to complete because of the long-time to pass the root from destination to source. Note that a root may contain multiple receipts, so that cost per transfer can be averaged out.

Further Improvements

Further improvement can be made to reduce LP completion time: Instead of pushing L2 -> L1 and waiting 7 days, L1 directly reads unconfirmed block/tx result (with some finality criterion) and sends the receipt root hash to the source chain directly. E.g., Optimism will send the world state root of per post-tx on L1.

However, one issue is that L2-on-L1 data is not cross-chain friendly

• Proof via world state root can be very large
• Receipt root is preferred but currently, optimism has no receipt root on L1

Final Words

If you are interested in the idea, feel free to reach me at qizhou@quarkchain.org. Further, you can find a talk about the idea on Dapp-Learning (in Chinese, and thanks dapp learning for hosting the event).