用户注册时需要检测 Registry Cell 中是否已经有了相应的生意业务对，并以生意业务对的 token id 的 hash 作为生意业务对标识符。新增生意业务对将在注册中心新增一笔记录。今朝没有设计反注册成果。
雷同 Uniswap 的 AMM 需要为活动性提供方配置资产池，用来提供算法支持下的无限活动性。下面以 ckb-sUDT 生意业务对为例，描写资产池操纵的生命周期。
CKB 上回收的 Cell 编程模子在产物和协议设计上与等账户模子有很大的差异，这就给面向账户设计的这几种 DEX 的实现带来了挑战。然而 rollup 这种链外聚合链上结算的模式又绕开了在链上按照用户的行动更新账户数据的问题，只需要验证链外的清算功效是否正确即可。这种模式很是切合 CKB 的业务逻辑，因此本文将深入探讨这种 Layer 2 订单聚合模式在 CKB 上的实现。
为了防备这种环境产生，我们需要对提现做特另外限制，譬喻在提现前用户需要先发布一个预提现 cell，正式提现则需要引用这个预提现 cell，同时聚合器假如看到这个预提现 cell，它将自动将该用户的 account cell 从状态更新中解除。留意用户的限价单订单下单操纵会首先发送给聚合器，聚合器会直接将可匹配的订单处理惩罚，最后留下临时无法匹配的订单才会真正在链上更新其订单列表。下一个聚合周期，这些未完成的订单会作为 input 参加下一轮笼络，但这时他们就无需用户提交新的生意业务签名了。· 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.这个模式的利益是简朴，只需要实现一个 dex lock script。应用层团结差异的链外逻辑既可以实现 OTC 生意业务也可以实现会合笼络生意业务。
生意业务笼络与手续费计较
充值进程是把用户的资产改为合约打点，而且生成一个对应的 account cell，个中记任命户的资产数值。Account cell 自己的业务逻辑由对应的 dex clear type script 来担保，它自己记录了用户的 pk_hash 用来验证来自用户的生意业务指令，同时也答允合约自己凭据预定法则修改其余额。Account cell 的 Data 字段记录了用户的各类资产的余额，同时按照 DEX 范例差异，大概还需要记任命户的 order book。 郑重声明：本文版权归原作者所有，转载文章仅为传播更多信息之目的，如作者信息标记有误，请第一时间联系我们修改或删除，多谢。
聚合处事器收集一段时间内的用户订单并统一聚合，这些订单包罗：买单、卖单和活动性增减订单。思量到生意业务的公正性，聚合后的订单凭据如下法则（序次）执行。这种处理惩罚要领可以最小化生意业务滑点。
本文劈头设计了两种 Layer 2 DEX 的设计方案。可以看到他们都充实操作了 UTXO 模子天然的聚合特性，在链外完成了生意业务聚合和笼络，低落了链上的生意业务量和用户的认知本钱。同时担保了资产托管的去中心化性和去信任性。
