在 NXTP 之前，Connext 有開發另外一套跨鏈資產轉移方案 Vector，但 Connext 認為 Vector 設計上有許多先天上的缺點，例如鏈上和鏈下狀態同步的複雜性、依賴瀏覽器儲存使用者資料、轉帳流程繁鎖、資金分散導致記帳上的困難等等，因此 Connext 不斷地思考有沒有更好的方式來進行跨鏈資產轉移，促使 NXTP 的誕生。更多有關 NXTP 誕生的原因，以及 NXTP 如何改善 Vector 的痛點，可以參考 Connext 官方撰寫的介紹文章：
本文將會聚焦在 NXTP 背後的技術實現，包含運作原理、技術細節，安全分析、以及與其相似的跨鏈方案 cBridge 進行比較，相關資源與細節都可以參考他們的文件：
運作原理
運作流程
NXTP 協議裡主要有 3 種角色參與其中：User（使用者 / Sender）、Router（跨鏈流動性提供者）以及 Relayer（協助 User 發送跨鏈交易），其運作流程如下圖：
NXTP 運作分為以下三個階段：
Step1 — Route selection
NXTP 透過 Router 相互競標的方式，讓使用者（Sender）決定要接受哪一個 Router 的報價。使用者首先會透過 NATS 訊息網絡來廣播跨鏈轉帳的需求，例如：從 Ethereum 上的 A 地址轉帳 1000 USDT 至 Arbitrum 上的 B 地址。
網絡中提供跨鏈流動性的 Router 接收到使用者的請求後，會給出透過它進行跨鏈轉帳時的報價，例如：抽取 5% 手續費，當網絡裡存在多個 Router 時，就會產生多筆報價，使用者就能從多份的 Router 報價中選擇對自己最有利的報價，來進行後續的流程。
Step2 — Prepare
使用者（Sender）決定接收某個 Router 的報價後，會將轉帳和報價的資訊，一同提交給 Sender Chain 上的 NXTP 合約，合約驗證資訊無誤後，會將使用者指定的轉帳資產轉移至合約上，並且發出交易準備完成的事件，來表示使用者轉帳的資產已經在 Sender Chain 上完成準備。
Router 會持續監控各個鏈上 NXTP 合約的動作，當發現自己的報價被使用者接受、並且在 Sender Chain 完成轉帳準備後，Router 會主動到 Receiver Chain 上的 NXTP 合約提交轉帳準備，收款方為使用者在 Sender Chain 轉帳準備時指定的 Receiver Chain 地址，轉帳的金額會依據 Router 報價內容扣除相關費用後，從 Router 身上轉移到 NXTP 合約上，等待使用者進行撥款。
Step3 — Fulfill
使用者看到 Router 在 Receiver Chain 完成轉帳準備後，就能開始進行撥款的動作。使用者首先要將 Receiver Chain 撥款所需的資訊在本地端簽好名，接著透過 Relayer 協助將撥款的交易發送到 Receiver Chain 上的 NXTP 合約（會有額外手續費），合約驗證資訊無誤後，Receiver Chain 的收款方就會收到 Router 在 Step 2 代替使用者在 Receiver Chain 提交的資產。
Router 偵測到使用者完成 Receiver Chain 上的撥款後，Router 會取得使用者在 Receiver Chain 撥款交易的內容與簽名，用相同的資訊對 Sender Chain 上使用者一開始在 NXTP 合約建立的轉帳準備進行撥款，取回 Router 在 Receiver Chain 幫使用者預付的資產，完成整個跨鏈轉帳的流程。
Relayer 的角色（有可能會由 Router 同時扮演）讓使用者在 Step 3 進行 Receiver Chain 上的撥款時，不需要持有 Receiver Chain 上的 gas token，取而代之的是需要支付 Relayer 額外的手續費，這個費用會在 NXTP 合約進行撥款時，從撥款的額度裡扣除，因此最終 Receiver Chain 上的收款方收到的金額會是 transfer_amount — (router_fee + relayer_fee)。
使用者也可以選擇不透過 Relayer，就不需要支付 Relayer 額外的手續費，但就必須準備足夠的 Receiver Chain 上的 gas token 來進行撥款。
退款機制
NXTP 協議中每一筆轉帳都需要設定過期時間，最短為 1 天，最長為 30 天，而且 Sender Chain 上的過期時間會比 Receiver Chain 上的過期時間長，原因是 Router 才能有比較充裕的時間，在使用者完成 Receiver Chain 取款後，取得使用者在 Receiver Chain 取款的資訊和簽名，回到 Sender Chain 取回在 Receiver Chain 預付的款項。
NXTP 針對轉帳的不同時效階段，設計了兩種退款機制，來保護協議參與者的資產：
轉帳過期前
NXTP 允許轉帳收款方在轉帳有效期間內，取消該筆轉帳。
若以使用者在 Sender Chain 的轉帳為例，其收款方為某個特定的 Router，該 Router 有權力在轉帳過期前，取消使用者在 Sender Chain 上的轉帳，NXTP 合約會立即退還資產給使用者。
若以 Router 替使用者在 Receiver Chain 提供流動性的轉帳為例，其收款方為使用者指定的收款地址，該地址有權力取消 Router 在 Receiver Chain 上的轉帳，NXTP 合約會立即退還資產給 Router。
轉帳過期後
NXTP 允許任何人在轉帳過期後，發起退款的請求，但退款時需要支付交易手續費，因此通常還是會由參與其中的利害關係人（User & Router）來執行。
技術細節
上圖為 Connext 官方所提供的 NXTP 協議技術的示意圖，此章節會針對圖中的不同技術區塊分別做討論，各個區塊的程式實作可以參考 GitHub：
Messaging
使用者（SDK）、Router 與 Relayer 都是透過 NATS 這套分散式系統訊息交換技術來進行溝通，NATS 提供了許多訊息交互的方式，NXTP 協議主要使用了 Request-Reply 模式，來讓使用者、Router 與 Relayer 之間能夠進行訊息交換，更詳細的技術細節可以參考 NATS 文件：
Router
目前 Router 有白名單機制，只有官方允許的人才能成為 Router。
Router 會監聽來自使用者的轉帳請求，即時回覆使用者轉帳的競標，目前 Router 預設收取的手續費為 5%，手續費目前無法透過 config 設定，需要手動更新程式調整。
有些 Router 會同時充當 Relayer，協助使用者發送 Receiver Chain 的交易並收取額外的手續費，relay 最低的手續費可以透過 config 設定，當使用者願意支付的 relay 費用不足時，會拒絕使用者的請求。
由於 NXTP 協議的資料都儲存在鏈上，Router 不需要資料儲存機制（例如檔案、資料庫）來保存額外的鏈下狀態，而是透過 Subgraph 從鏈上取得運作所需的資料，例如使用者在 Sender Chain 轉帳準備完成的資訊、使用者在 Receiver Chain 撥款完成的資訊等等，以鏈上的資料與狀態為 NXTP 協議共識，大大簡化鏈下資訊同步的成本。
但沒有本地狀態的 Router 可能會有一些效率上的問題，目前 Router 每隔一段時間會透過 Subgraph 撈取所有與自己相關的交易，包含過去已經處理過的交易，當未來 Router 處理過的交易量逐漸增加時，會衍生出效能的問題，這是後續值得追蹤與改善的部分。
SDK
NXTP 提供了讓 Client APP 能夠快速介接協議的 SDK，對於開發者來說是非常貼心的體驗。
SDK 同樣會透過 Subgraph 來從鏈上取得所需的交易資料，並且設計了一套完整的報價機制，包含發送轉帳資訊給 Router 取得報價，以及從眾多 Router 的報價中選擇最優的方案的演算法。除此之外，尋找 Relayer 協助在 Receiver Chain 遞送交易的細節也已經完善，還能支援不透過 Relayer，由使用者自行上鏈的選項。
但也有與 Router 相同的問題，當交易量過大時，有可能會衍生效能的問題，值得後續關注。
Contract
NXTP 協議的合約以 TransactionManager 為核心，實作了在運作原理章節提到的 prepare、fulfill、cancel 等功能，合約實作時同時考慮到身為 Sender Chain 和 Receiver Chain 的邏輯，因此各條鏈上只需要部署這一份合約就好。
另外值得注意的是，合約上除了有實作 Router 白名單機制之外，Router 在為使用者服務之前，必須先將流動性加入合約之中，以合約裡紀錄的餘額來評斷 Router 是否有足夠的流動性來提供服務，任何人都可以透過合約來查詢 Router 流動性深度，以防止 Router 流動性不足卻隨意報價接單，造成協議額外的成本。
安全分析
在理解 NXTP 協議的運作之後，以下對協議運作中可能產生的風險進行討論。
- Sender 惡意詢價
Sender 詢價請求會廣播到整個 NXTP 網絡中，Sender 可以藉此發出大量的報價請求來癱瘓 Router，Router 進行報價前都會做基本的驗證，其中比較耗時的步驟是到鏈上合約確認流動性是否足夠，大量無用的報價請求有可能會導致 Router 無法服務其他用戶。 - Router 惡意報價
惡意 Router 可以故意提供非常低的手續費來引誘使用者選擇它的報價，而當使用者接受惡意 Router 的報價後，如期地在 Sender Chain 上將轉帳資產鎖進合約，此時惡意 Router 故意不履行後續的步驟，將會導致使用者的資產被鎖住，直到轉帳設定的期限到期。 - Relayer 狹持交易
由於 Router 有可能同時扮演 Relayer 的角色，當使用者想透過 Relayer 來完成 Receiver Chain 撥款的動作時，Relayer 有能力可以攔截使用者的簽章資料，直接到 Sender Chain 去完成撥款，取得使用者轉帳的資產。若使用者沒有能力自行至 Receiver Chain 上完成撥款的話，Relayer 甚至可以等到 Receiver Chain 上的轉帳過期，進行退款，造成使用者單方面的損失。
方案比較
NXTP 與之前分享過的 cBridge 核心原理非常相似，都是使用類似於 HTLCs 的機制來達成 Non-custodial 的跨鏈、跨 Rollup 的資產轉移，若對於 cBridge 或 HTLCs 還不熟悉的讀者，建議可以先閱讀之前分享的介紹：
以下將針對 NXTP 與 cBridge 設計上的異同進行分析與比較，讓我們能以更宏觀的角度來了解此類型的跨鏈資產轉移方案的長處與短處。
產品階段
cBridge 已經在主網上線，撰文當下已經支持了 9 條公鏈（L1、L2 都有），以及支持了許多熱門的幣種，如 USDT、USDC、DAI 等等。
NXTP 還在主網測試階段，想要試用的讀者可能還要再等一下。
跨鏈機制
cBridge 和 NXTP 都使用了類似於 HTLCs 的機制來實現 Non-custodial 的跨鏈轉帳，但各自都有依據使用情境做了一些調整。
cBridge 為了提供一致的使用者體驗，調整了 HTLCs 流程中第 3 與第 4 步驟，讓使用者在 Sender Chain 上就能完成所有跨鏈轉帳的操作。
NXTP 忠於 HTLCs 流程，但在協議中額外引入了 Relayer 的角色，協助使用者遞送交易至 Receiver Chain，目的也是讓使用者只需要關注在 Sender Chain，提升使用者的體驗。除此之外，NXTP 協議使用簽名來代替 hash lock，唯有使用者親自同意並簽署交易，NXTP 合約才有權力去移動鎖在合約上的資產。
這些調整雖然能夠提升使用者體驗，但是也都帶來了新的風險，相關的安全議題在各自的介紹文章裡都有詳細的分析，在此就不贅述。
狀態保存
cBridge Node 需要依賴資料庫來記錄鏈下狀態，因此跑節點時必須要同時準備資料庫的基礎設施，也需要時時關注資料庫與鏈上資料是否一致，當節點遭遇異常時（如當機、網路不穩），如何從災難中復原並確保資料不丟失，是額外的技術考驗。
NXTP 將所有狀態儲存在鏈上，不管是使用者和 Router 都是透過 Subgraph 來存取鏈上資料，以鏈上狀態為共識，因此不需要額外維護鏈下狀態，也就不用擔心狀態不一致的問題。但也因為沒有紀錄任何鏈下狀態，每一次都要從撈取完整的鏈上資料，實務上會面臨效能方面的挑戰。
中心化設施
cBridge 需要借助單一 Gateway 來尋找 cBridge Node，NXTP 則需要依靠 NATS 設施來與 Router 通訊，都存在著 SPOF（Single Point Of Failure）的問題，官方如何確保核心單點設施的 HA（High Availability）是值得關注的議題。
結語
以上是對於 NXTP 協議背後技術實現的介紹，如果有任何想法想要分享，或是有地方想要了解更多，都可以留下留言一起討論 😃
