Celer cBridge 是一個跨鏈的資產轉移方案，cBridge 同時支援了 L1 與 L2、以及 L1 與 L1 之間的資產橋接。我們可以從 cBridge 的 Web APP 上看見他們已經支援了許多知名的 L1 與 L2 的公鏈：
cBridge 的理念以及優勢可以參考 Celer 在部落格上的文章介紹，本篇文章會側重在 cBridge 背後的技術實現，包含運作原理、合約實作以及節點維運的介紹。
運作原理
cBridge 主要使用了 HTLCs 技術來實現跨鏈的資產轉移，對於 HTLCs 不熟的讀者，可以先參考以下文章的介紹，了解其原理以及應用場景：
運作流程
cBridge 在其合約 GitHub 的文件裡描述了 cBridge 的運作流程，以下節錄其中：
- Sender sends transferOut tx on the source chain.
- Bridge node sends transferIn tx on the destination chain, using the same
hashlockset by the sender. - Sender confirms the transfer on the source chain.
- Bridge node confirms the transfer on the destination chain.
為了幫助理解，我將步驟畫成如下的流程圖：
以下會針對四個關鍵步驟依序進行細節說明：
Step 1 — Send transfer out by sender
整個 cBridge 跨鏈的資產轉移流程會由 source chain 的 sender （即使用 cBridge 進行轉帳的使用者）發起，sender 會負責產生 hash lock、設定轉帳的時限，並與轉帳的資訊（token 地址、token 數量、destination chain 代號、recipient 地址）一同向部署在 source chain 的 cBridge 合約發起 transfer out 請求，合約接收到請求後會先將要轉帳的 token 數量，從 sender 身上移轉到合約身上，唯有提供 hash lock 的解答，或是轉帳時限到期後，才能將 token 取出。
Step 2 — Send transfer in by cBridge Node
在鏈下的 cBridge Node 會持續監控各個鏈上 cBridge 合約的動作，當它發現 source chain 上有一筆新的 transfer out 請求，它會在鏈上取得這筆 transfer out 的細節，主動對部署在 destination chain 上的 cBridge 合約發起 transfer in 請求，其中收款方為 transfer out 指定的 recipient 地址，並使用與 transfer out 相同的 hash lock，以及較短的取款時限（約為 source chain 上設定時限的 2/3），並將 transfer out 指定的 token 數量扣掉 cBridge Node 轉發的成本和手續費後，從 cBridge Node 身上轉移至 destination chain 上的 cBridge 合約。
此時 cBridge Node 並不知道 hash lock 的答案，要等到 sender 在 Step 3 完成source chain 上 transfer out 的撥款，並揭露 hash lock 的答案後，cBridge Node 才有能力執行 destination chain 上 transfer in 的撥款。
Step 3 — Confirm transfer out by sender
Sender 確認 cBridge Node 有在 destination chain 提交相應的 transfer in 請求後，就可以進入 source chain 上 transfer out 的撥款階段。Sender 首先要對 source chain 的 cBridge 合約提交 transfer out 的 hash lock 答案，合約驗證答案無誤後，會將 transfer out 指定的 token 數量轉移給 cBridge Node，完成 source chain 上 transfer out 的撥款。
Step 4 — Confirm transfer in by cBridge Node
在鏈下的 cBridge Node 監控到 sender 已經在 source chain 完成 transfer out 撥款後，隨即拿著 sender 撥款時揭露的 hash lock 答案，到 destination chain 的 cBridge 合約提交 hash lock 答案，完成 transfer in 的撥款，此時 destination chain recipient 就會收到來自 source chain sender 的款項，完成跨鏈的資產轉移。
細節步驟雖然看起來有點繁瑣，但對於 cBridge APP 的用戶來說只要進行兩次簽名操作（Step 1 發送 transfer out 交易、Step 3 對 transfer out 撥款），並等待一些時間（3~5 分鐘），過程中完全不需要切換錢包的網路，使用起來的體驗是非常簡單順暢的。
退款（refund）機制
不管是 transfer out 或是 transfer in 都會設定一個有效時限，當有任何一方沒有履行義務時，在設定的時限之後，雙方都有能力可以直接要求 cBridge 合約退回事先放進去用來轉帳的 token，不需要提供 hash lock 的答案。退款機制能夠保護雙方的資產，不會因為對手方不作為而導致資產被永久鎖在 cBridge 合約上。
另外值得注意的是，destination chain 的 transfer in 會比 source chain 的 transfer out 更早過期，有可能 cBridge Node 已經對 transfer in 進行退款，使用者才對 transfer out 進行確認撥款，此時也會對使用者造成損失。
目前 cBridge Web APP 設定的 transfer out 過期時限為 12 小時，其對應的 transfer in 約為 12 * 2/3 = 8 小時，時間相對充足，一般正常的轉帳只需要數分鐘，如果過程中有出現非預期的狀況，還可以有足夠的反應時間處理。
簡單的操作體驗背後的成本
眼尖的讀者可能已經發現，cBridge 運作步驟中的第三與第四步，與典型的 HTLCs 不同，典型的 HTLCs 會是 sender 先到 destination chain 揭露 hash lock 的解答，確認 recipient 能夠收到撥款，cBridge Node 才能到 source chain 取回它在 destination chain 預先墊付給 recipient 的款項。
Celer 官方說明是為了提升使用者體驗，如果走典型的 HTLCs 流程，使用者在確認 transfer out 撥款的步驟中，必須要切換錢包的網路至 destination chain，還需要事先在錢包裡準備足夠的 destination chain gas token 來支付撥款所需的交易手續費，對使用者來說非常不方便，因此 cBridge 調整了最後兩個步驟的順序，讓使用者只需要在 source chain 進行操作，來大幅提升使用者的體驗。
但這樣的調整並非沒有成本，它會為使用者帶來額外的風險，試想一個情境：當使用者在 source chain 上完成 transfer out 撥款，cBridge Node 收到使用者的款項後，卻沒有在 destination chain 上將 transfer in 撥款給 recipient（可能是惡意、gas token 不足或是當機），等到 destination chain 上的 transfer in 過期，cBridge Node 甚至有能力對 transfer in 進行 refund 的動作，cBridge Node 有機會可以無償得到使用者轉帳的 token。
這部分必須仰賴使用者自己採取行動去降低風險，當使用者發現在 transfer in 有效區間內等了足夠久的時間，recipient 都還沒有收到款項，使用者必須要自己主動到 destination chain 提供 hash lock 答案，完成 transfer in 撥款的動作，以防止資產被惡意取走。
安全分析
總結以上，我們針對 sender 和 cBridge Node 在 cBridge 四個運作步驟中可能產生的安全議題，進行分析與整理：
- 如果 sender 執行了 Step 1 但 cBridge Node 沒有往下執行，此時 sender 的資產會單方面地被扣押在 source chain 的 cBridge 合約之中，必須要等待 12 小時之後，才能進行退款。
- 如果 cBridge Node 執行了 Step 2 但 sender 沒有往下執行，此時 sender 和cBridge Node 的資產分別會被扣押在 source chain 和 destination chain 的 cBridge 合約中，必須等到轉帳過期後，才能各自進行退款。值得注意的是，cBridge Node 在 destination chain 上的 transfer in 有更短的過期時間 （8 小時），能夠比 sender 更早完成退款。
- 如果 sender 執行了 Step 3 但 cBridge Node 沒有往下執行，此時 sender 已將資產轉給 cBridge Node，但 destination chain 上的 recipient 還沒有收到對應的款項。如果這個狀態一直持續到 destination chain 上的 transfer in 過期後，cBridge Node 甚至有能力進行退款取回 transfer in 的資金，而造成 sender 單方面的損失。
這個狀況對 sender 有很大的安全疑慮，sender 需要在 transfer in 過期前（8 小時內），自行（或委託他人）到 destination chain 上完成 transfer in 的撥款。正常 cBridge 的轉帳流程能在十分鐘以內完成，如果 sender 撥款給 cBridge Node 後，recipient 卻遲遲沒有收到款項，這時候就需要提高警覺了。 - 如果 cBridge Node 執行完 Step 4 但交易一直沒有成功（例如 gas 不足），此時 sender 仍然有資金損失的風險。因此建議 sender 在完成撥款之後，要隨時留意轉帳的狀態與經過的時間，以保護自己的資金安全。
合約實作
cBridge 合約實作很單純，提供了 transferOut、transferIn、confirm 以及 refund 的功能，不多不少，都是 cBridge 運作流程中的核心動作，而且這些方法都是公開可以讓任何人去呼叫的，因此當節點在轉帳過程中出現問題時，使用者都有能力能夠直接對合約進行操作，保護自己的資產。
特別要注意的是，合約方法 transferOut 的第一個參數 address _bridge，這個參數要填入能夠服務這次跨鏈轉帳需求（例如支援 1000 USDT 從 Ethereum 到 Polygon）的 cBridge Node 地址，換句話說，使用者在進行跨鏈轉帳之前，必須先決定好要找哪個 cBridge Node 來服務。
Celer 官方提供了一個 Gateway 服務，負責 cBridge Node 的路由，使用者只要將轉帳的資訊丟給該服務，它會選出符合使用者轉帳需求，且當下狀態最好的 cBridge Node（例如成功率高、手續費低等等），使用者就能在進行 transferOut 時填入 Celer Gateway 推薦的 cBridge Node。
由於 Celer 官方並未提供 Gateway 相關的資訊，有技術背景的讀者可以試著去操作 cBridge Web APP，瞭解其背後的實作細節。
除了方法之外，合約裡也有一些重要的事件大家可以去關注：
- LogNewTransferOut 事件：transferOut 完成時會發出的事件，會紀錄這筆 transfer out 的 transferId。
- LogNewTransferIn 事件：transferIn 完成時會發出的事件，會紀錄這筆 transfer in 的 transferId 以及其對應的 transfer out 的 transferId（srcTransferId）。
在 cBridge 合約上不管是要進行 confirm 或是 refund，都需要提供 transferId，因此 transferId 在 cBridge 的應用中是至關重要的資料。除此之外，透過這兩個事件的觀察，能夠幫助我們將跨鏈的 transfer out 與 transfer in 關聯起來，以利持續追蹤轉帳的狀態，並在意外發生時能有應對的能力。
節點維運
Celer 官方開源了 cBridge Node 的實作，任何人雖然都可以跑起自己的節點，但 cBridge 現階段有白名單機制，想擔任 cBridge Node 來服務使用者必須要先跟官方接洽。
擔任節點的好處在於可以從每一筆跨鏈轉帳中賺取一定比例的手續費，但也要考量到維運節點的成本，Celer 官方很貼心地在 cBridge Node GitHub 文件裡詳細列出當節點需要注意的事項，包含機器建議配備、支援的幣種和最少需要提供的流動性、各條鏈的建議配置、維運節點的 Best Practice 等等，節點甚至還有內建統計數據的 API ，讓維運者能夠隨時監控節點的交易狀況。
從 GitHub 文件的詳細程度以及考量了維運節點的各個面向，可以感受到 Celer 官方對社群的用心，對於維運 cBridge Node 有興趣的讀者建議一定要好好將 GitHub 文件看過一遍。
結語
以上是對於 cBridge 背後技術實現的介紹，如果有任何想法想要分享，或是有地方想要了解更多，都可以留下留言一起討論 😃
