这个模式的利益是简朴，只需要实现一个 dex lock script。应用层团结差异的链外逻辑既可以实现 OTC 生意业务也可以实现会合笼络生意业务。

凭据交易订单分成两个行列并按照价值降序、升序分列

Orderbook 模式与笼络流程

生意业务笼络与手续费计较

雷同 Uniswap 的 AMM 需要为活动性提供方配置资产池，用来提供算法支持下的无限活动性。下面以 ckb-sUDT 生意业务对为例，描写资产池操纵的生命周期。

充值进程是把用户的资产改为合约打点，而且生成一个对应的 account cell，个中记任命户的资产数值。Account cell 自己的业务逻辑由对应的 dex clear type script 来担保，它自己记录了用户的 pk_hash 用来验证来自用户的生意业务指令，同时也答允合约自己凭据预定法则修改其余额。Account cell 的 Data 字段记录了用户的各类资产的余额，同时按照 DEX 范例差异，大概还需要记任命户的 order book。

AMM 模式与笼络流程

总结

一种更简朴的模式

用户的提现行动和充值行动相反，用户将本身的 Account Cell 与 一个或多个 Deposit Cell 组合，并生成一个或多个资产 cell。但这里有一个细节，即假如用户还没有竣事本身在 Layer 2 聚合器的业务，聚合器大概会同时发送一个引用该用户 account cell 的聚合生意业务，该生意业务将会与用户的提现生意业务斗嘴，导致二者只有一个可以上链。

最近一段时间，跟着 rollup 技能的成长，人们开始实验用该技能及其改造的 zk-rollup 和 optimistic rollup 来举办优化，引入了链外聚合者的脚色，将大量生意业务在链外聚合清算，然后按期到 Layer 1 上做结算。这种要领也大幅提高了 Layer 1 的生意业务吞吐量，低落了生意业务的平均本钱。

处理惩罚淘汰资产池的订单

CKB 上回收的 Cell 编程模子在产物和协议设计上与以太坊等账户模子有很大的差异，这就给面向账户设计的这几种 DEX 的实现带来了挑战。然而 rollup 这种链外聚合链上结算的模式又绕开了在链上按照用户的行动更新账户数据的问题，只需要验证链外的清算功效是否正确即可。这种模式很是切合 CKB 的业务逻辑，因此本文将深入探讨这种 Layer 2 订单聚合模式在 CKB 上的实现。

与 AMM 模式对比，订单簿模式有两个重要区别：其一是它的订单一般是限价单而不是市价单，即用户本身节制生意业务价值；其二是它无法提供无限活动性，用户必需期待匹配订单呈现。从数据布局大将，订单簿模式比 AMM 模式在链上增加了订单数据，同时淘汰了活动性代币和资金池。

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.

注入活动性将得到 Liquidity Token，这是一种切合 sUDT 尺度的扩展 UDT，其合约代码与 sUDT 略有区别，资产标签为生意业务对的哈希。Liquidity Token 老是在注入活动性时被自动建设，并在提出活动性时销毁。详细的业务逻辑与 Uniswap 一致。

交易单差额再凭据预定的价值曲线与资产池举办清算（ 这里可以按照订单的滑点要求按需处理惩罚）

所有通过 witness 新增的订单和留在 cell data 内里的老订单一起处理惩罚

FromJan

聚合处事器收集一段时间内的用户订单并统一聚合，这些订单包罗：买单、卖单和活动性增减订单。思量到生意业务的公正性，聚合后的订单凭据如下法则（序次）执行。这种处理惩罚要领可以最小化生意业务滑点。

活动性增加与退出方法与 Uniswap 也是一致的。详细来说用户注入资产可以得到 Liquidity Token，反向则可以提取资产。

郑重声明：本文版权归原作者所有，转载文章仅为传播更多信息之目的，如作者信息标记有误，请第一时间联系我们修改或删除，多谢。