隨著 DeFi 和鏈上金融活動的演化，DEX 作為其基礎設施目前看大概有這樣幾種大的型別。其一是以 etherdelta、0x 為代表訂單簿型別，細分為鏈上撮合和鏈外撮合兩種；其二是以 Uniswap 為代表的 AMM 型別，透過某種數學關係自動設定成交價格從而提供無限深度；其三是以 Kyber 為代表的外部儲備池自動報價的做市商型別。三種模式的統一特點是使用者的資產是自託管的，對服務商無需信任。因此在安全性上大幅超越傳統的中心化交易所。
最近一段時間，隨著 rollup 技術的發展，人們開始嘗試用該技術及其改進的 zk-rollup 和 optimistic rollup 來進行最佳化，引入了鏈外聚合者的角色，將大量交易在鏈外聚合清算，然後定期到 Layer 1 上做結算。這種方法也大幅提高了 Layer 1 的交易吞吐量，降低了交易的平均成本。
CKB 上採用的 Cell 程式設計模型在產品和協議設計上與以太坊等賬戶模型有很大的不同，這就給面向賬戶設計的這幾種 DEX 的實現帶來了挑戰。然而 rollup 這種鏈外聚合鏈上結算的模式又繞開了在鏈上根據使用者的動作更新賬戶資料的問題，只需要驗證鏈外的清算結果是否正確即可。這種模式非常符合 CKB 的業務邏輯，因此本文將深入探討這種 Layer 2 訂單聚合模式在 CKB 上的實現。
基本業務流程
充值 & 提現
使用者需要將自己待交易的資產的操作許可權授權給 DEX 合約，該過程可以類比傳統中心化交易所的充值過程，但資產所屬權仍然歸使用者，它是非託管的。
充值過程是把使用者的資產改為合約管理，並且生成一個對應的 account cell，其中記錄使用者的資產數值。Account cell 本身的業務邏輯由對應的 dex clear type script 來保證，它本身記錄了使用者的 pk_hash 用來驗證來自使用者的交易指令，同時也允許合約本身按照預定規則修改其餘額。Account cell 的 Data 欄位記錄了使用者的各種資產的餘額，同時根據 DEX 型別不同，可能還需要記錄使用者的 order book。
使用者的提現動作和充值動作相反，使用者將自己的 Account Cell 與 一個或多個 Deposit Cell 組合，並生成一個或多個資產 cell。但這裡有一個細節，即如果使用者還沒有結束自己在 Layer 2 聚合器的業務，聚合器可能會同時傳送一個引用該使用者 account cell 的聚合交易，該交易將會與使用者的提現交易衝突，導致二者只有一個可以上鍊。
為了防止這種情況發生，我們需要對提現做額外的限制，例如在提現前使用者需要先公佈一個預提現 cell，正式提現則需要引用這個預提現 cell，同時聚合器如果看到這個預提現 cell，它將自動將該使用者的 account cell 從狀態更新中排除。
交易指令與撮合
我們把使用者在鏈上的 account cell 稱為初始狀態（pervious states），對於 AMM 類的 DEX，會存在類似 Asset pool cell 的額外初始狀態。使用者與 Layer 2 的聚合者建立連線，獲取當前的報價和訂單資訊，並且傳送交易訂單。使用者傳送的交易訂單內容包括對交易的描述（order），例如「0.1 cBTC 置換 1000 cUSD」，以及交易簽名。聚合器收集使用者的報價訂單後，立即反饋使用者，讓使用者看到自己的交易已經被接受。
接著，聚合器實時對收到的訂單進行撮合，隨時更新每個參與者的 account cell 狀態（new states），並定時把新的 account cell commit 到鏈上實現鏈上結算。每個上鍊的交易由初始狀態、新狀態、使用者的數字簽名構成。Account Cell 的 type script 負責驗證整個鏈上結算的有效性。
使用者的手續費收取在這個過程中是比較明確的，即按百分比收取交易資產的數量，並由聚合器負責為 ckb 礦工提供以 ckb 為計價的礦工費。
AMM 模式與撮合流程
類似 Uniswap 的 AMM 需要為流動性提供方設定資產池，用來提供演算法支援下的無限流動性。下面以 ckb-sUDT 交易對為例，描述資產池操作的生命週期。
建立交易對並注入初始流動性
為了防止重複建立交易對，這裡需要引入交易對序號產生器制。
使用者註冊時需要檢測 Registry Cell 中是否已經有了相應的交易對，並以交易對的 token id 的 hash 作為交易對識別符號。新增交易對將在註冊中心新增一條記錄。目前沒有設計反註冊功能。
使用者註冊交易對的同時需要注入初始流動性。初始流動性根據 CKB/sUDT 的市場比價等比注入，例如 1CKB = 0.01USDT 時，使用者同時注入 50k CKB 和 500 USDT。這些資產生成一個單一的資產池 Cell（Asset Pool Cell）用來進行後續交易。
注入流動性將獲得 Liquidity Token，這是一種符合 sUDT 標準的擴充套件 UDT，其合約程式碼與 sUDT 略有區別，資產標籤為交易對的雜湊。Liquidity Token 總是在注入流動性時被自動建立，並在提出流動性時銷燬。具體的業務邏輯與 Uniswap 一致。
增加/退出流動性
流動性增加與退出方式與 Uniswap 也是一致的。具體來說使用者注入資產可以獲得 Liquidity Token，反向則可以提取資產。
為了防止頻繁操作資產池導致交易衝突或 DDoS 問題，可能需要引入一些限制。例如加入閾值要求、提現手續費要求等。
交易撮合與手續費計算
聚合伺服器收集一段時間內的使用者訂單並統一聚合，這些訂單包括：買單、賣單和流動性增減訂單。考慮到交易的公平性，聚合後的訂單按照如下規則（次序）執行。這種處理方法可以最小化交易滑點。
處理增加資產池的訂單
所有的買單、賣單按照當前資產池價格直接匹配
買賣單差額再按照預定的價格曲線與資產池進行清算（ 這裡可以根據訂單的滑點要求按需處理）
處理減少資產池的訂單
手續費方面，使用者的買單賣單需要繳納一定額度（如 0.3% ）的手續費。這部分手續費一部分（例如 0.2%）直接進入資產池，作為流動性提供方的收益；另一部分（例如 0.1% 作為聚合器運營費用支付給指定地址）。
Orderbook 模式與撮合流程
與 AMM 模式相比，訂單簿模式有兩個重要區別：其一是它的訂單一般是限價單而不是市價單，即使用者自己控制交易價格；其二是它無法提供無限流動性，使用者必須等待匹配訂單出現。從資料結構上將，訂單簿模式比 AMM 模式在鏈上增加了訂單資料，同時減少了流動性代幣和資金池。
限價單更新
使用者將資產「存入」DEX 後，即可下限價單，限價單的內容包括：交易物件、交易價格、交易數量等。為了便於跟蹤，每個限價單會生成唯一識別符號 oid（可以透過交易的第一個 input 的 outpoint hash 實現。
交易撮合與手續費計算
注意使用者的限價單訂單下單操作會首先傳送給聚合器，聚合器會直接將可匹配的訂單處理，最後留下暫時無法匹配的訂單才會真正在鏈上更新其訂單列表。下一個聚合週期，這些未完成的訂單會作為 input 參與下一輪撮合，但這時他們就無需使用者提交新的交易簽名了。
撮合引擎按照如下邏輯處理：
所有透過 witness 新增的訂單和留在 cell data 裡面的老訂單一起處理
按照買賣訂單分成兩個佇列並根據價格降序、升序排列
依次撮合兩個佇列的頭部訂單，如果價格匹配，則按照平均價格成交，更新訂單數量資訊、使用者賬戶餘額資訊
繼續處理下一個頭部訂單，直到無法匹配為止
交易手續費按照交易幣種的等比收取（例如 0.1%），由聚合器運營方收取。
一種更簡單的模式
FromJan
一種更簡單的模式是不區分 deposit/account cell:
deposit&make order：Alice 生成一個新的 udt cell (token A, amount X) , lock 設定為 DEX lock, lock args 說明想要交換的 token B, amount Y. 這個交易既是充值又是掛單。這個 cell 的解鎖條件是 output 中有一個 token B cell, amount = Y, 且 lock 是 Alice lock.
take order：Bob 觀察鏈上具有 DEX lock 的所有 cells (orders)，選擇其中一個或者多個進行交易。
這個模式的優點是簡單，只需要實現一個 dex lock script。應用層結合不同的鏈外邏輯既可以實現 OTC 交易也可以實現集中撮合交易。
總結
本文初步設計了兩種 Layer 2 DEX 的設計方案。可以看到他們都充分利用了 UTXO 模型天然的聚合特性，在鏈外完成了交易聚合和撮合，降低了鏈上的交易量和使用者的認知成本。同時保證了資產託管的去中心化性和去信任性。
類比 Rollup 系列技術，本文的交易聚合方案並沒有使用零知識證明或樂觀假設加挑戰等方案對使用者的交易驗證進行運算複雜度降低。因此實際的執行效率和區塊 cycle 上限與單次非對稱驗籤的 cycle 比值有關，預計在 200~300 tps。儘管訂單簿模式中老訂單不需要再次驗證交易簽名，其對交易吞吐量的提升有限。但相信我們可以透過零知識證明技術，聚合簽名技術等密碼學方案大幅提高交易吞吐量。
