基于 Layer 2 订单聚合模式的 DEX 设计

2020-08-25 18:42 栏目:经验之谈 来源:网络整理 查看()

随着DeFi和连锁金融活动的发展,DEX作为其基础设施,目前有几种主要类型。一种是以etherdelta和0x为代表的订单类型,分为链上匹配和链外匹配两种类型;第二种是以Uniswap为代表的AMM类型,它通过一定的数学关系自动设定交易价格,提供无限的深度;第三种是以Kyber为代表的做市商类型。这三种模式的统一特征是用户的资产是自我管理的,不需要信任服务提供商。因此,它在安全性上大大优于传统的集中式交换。

近年来,随着汇总技术的发展,人们开始尝试利用该技术及其改进的ZK-汇总和optimize汇总进行优化,并引入链外汇总者的角色来汇总和结算链外的大量交易,然后定期在第1层进行结算。这种方法还极大地提高了第1层的事务吞吐量,并降低了平均事务成本。

CKB采用的Cell编程模型在产品和协议设计上与其他账户模型(如以太网)有很大不同,这给这些账户设计的DEX的实现带来了挑战。但是,汇总是一种在链外聚合结算的模式,它绕过了根据链上用户的操作更新帐户数据的问题,只需要验证链外的结算结果是否正确。这种模式非常符合CKB的商业逻辑,因此本文将深入探讨这种二层订单聚合模式在CKB的实现。

基于 Layer 2 订单聚合模式的 DEX 设计

基本业务流程

充值提现

用户需要授权他们的资产的操作权限来交易到DEX合同。这一过程可以与传统集中交易的充值过程相比,但资产的所有权仍然属于用户,这是不受管理的。

基于 Layer 2 订单聚合模式的 DEX 设计

充值流程是将用户的资产转为合同管理,并生成相应的账户单元,在其中记录用户的资产价值。账户单元自身的业务逻辑由相应的dex clear类型脚本来保证,该脚本记录用户的pk_hash以验证来自用户的交易指令,并允许合同本身根据预定规则修改其余额。“帐户”单元格的“数据”字段记录用户的各种资产的余额,也可以根据“索引”类型记录用户的订单簿。

用户的取款行为与充值行为相反。用户将自己的帐户单元与一个或多个存款单元结合,并生成一个或多个资产单元。然而,这里有一个细节,即如果用户还没有在第2层聚合器中完成他的业务,聚合器可能同时发送引用用户的账户单元的聚合事务,这将与用户的现金提取事务冲突,导致两者中只有一个可以链接。

为了防止这种情况发生,我们需要对提取现金施加额外的限制。例如,在提取现金之前,用户需要发布一个应计单元格,当正式提取现金时,需要引用这个应计单元格。同时,如果聚合器看到此应计单元格,它将自动从状态更新中排除用户的帐户单元格。

基于 Layer 2 订单聚合模式的 DEX 设计

交易订单和匹配

我们将链中用户的帐户单元称为初始状态。对于AMM类的DEX,将有一个类似于资产池单元的附加初始状态。用户与第2层的聚合器建立连接,获取当前报价和订单信息,并发送交易订单。用户发送的交易指令的内容包括交易的描述,如“0.1 cBTC替换1000 cUSD”和交易签名。从用户那里收集报价订单后,聚合器会立即反馈给用户,这样用户就可以看到他们的交易已经被接受。

然后,聚合器实时匹配收到的订单,随时更新每个参与者的账户单元状态,并定期将新的账户单元提交给链,以实现链结算。每个上行链路事务由初始状态、新状态和用户的数字签名组成。账户单元的类型脚本负责验证整个链中结算的有效性。

基于 Layer 2 订单聚合模式的 DEX 设计

在这个过程中,用户的费用收取相对清晰,即交易资产的数量是按百分比收取的,聚合器负责向ckb矿工提供以ckb计价的矿工费用。

AMM模式及匹配过程

像Uniswap这样的AMM需要为流动性提供者设置资产池,以提供算法支持的无限流动性。下面以ckb-sUDT事务对为例描述资产池操作的生命周期。

创建交易对并注入初始流动性

为了防止事务对的重复创建,有必要引入事务对注册机制。

基于 Layer 2 订单聚合模式的 DEX 设计

当用户注册时,他们需要检查注册表单元中是否有对应的事务对,并将事务对的令牌id的散列作为事务对标识符。添加事务对将在注册表中添加一条记录。目前,还没有设计反注册功能。

用户需要在注册交易对时注入初始流动性。初始流动性根据CKB/苏迪特的市场价格比率注入。例如,当1KB=0.01美元时,用户同时注入5万CKB和500 USDT。这些资产为后续交易生成一个资产池单元。

流动性令牌将通过注入流动性获得,这是符合sUDT标准的扩展UDT。它的合同代码与sUDT略有不同,它的资产标签是事务对的散列。流动性令牌总是在注入流动性时自动创建,在提议流动性时自动销毁。具体的业务逻辑与Uniswap是一致的。

增加/提取流动性

流动性增加和退出的方式也与Uniswap一致。具体来说,用户可以通过注入资产获得流动性令牌,并通过反向提取资产。

基于 Layer 2 订单聚合模式的 DEX 设计

为了防止资产池频繁操作导致的交易冲突或DDoS问题,可能需要引入一些限制。例如,增加门槛要求、提取费用要求等。

交易匹配和费用计算

聚合服务器在一段时间内收集用户订单,并统一聚合它们。这些订单包括支付订单、销售订单和流动性增加和减少订单。考虑到交易的公平性,汇总订单根据以下规则(顺序)执行。这种处理方法可以最大限度地减少交易失误。

1.处理添加资产池的订单

2.所有买入指令和卖出指令都根据当前资产池价格直接匹配

3.根据预定的价格曲线和资产池来清除采购订单和销售订单之间的差异(在这里,可以根据订单的滑动点要求根据需要进行处理)

4.处理订单以减少资产池

在手续费方面,用户需要为买卖订单支付一定金额(如0.3%)的手续费。部分手续费(例如0.2%)作为流动性提供者的收入直接进入资产池。另一部分(例如,0.1%作为聚合器的运营费用支付给指定地址)。

基于 Layer 2 订单聚合模式的 DEX 设计

订单模式和匹配流程

与AMM模式相比,订单簿模式有两个重要的区别:第一,它的订单一般是限价订单而不是市场订单,即用户自己控制交易价格;其次,它不能提供无限的流动性,用户必须等待匹配的订单出现。在数据结构方面,与AMM模式相比,订单簿模式增加了链中的订单数据,减少了流动性令牌和资金池。

限价单更新

在用户将资产“存入”DEX之后,他可以发出限价单,其中包括交易对象、交易价格和交易数量。为了便于跟踪,每个限价单将生成一个唯一的标识符oid(这可以通过交易第一个输入的outpoint散列来实现)。

基于 Layer 2 订单聚合模式的 DEX 设计

交易匹配和费用计算

请注意,用户对限价订单的下单操作将首先发送给聚合器,聚合器将直接处理可匹配的订单,最后将暂时不匹配的订单留在链中,以真正更新它们的订单列表。在下一个聚合周期中,这些未完成的订单将作为输入参与下一轮匹配,但此时它们不需要用户提交新的交易签名。

基于 Layer 2 订单聚合模式的 DEX 设计

匹配引擎根据以下逻辑进行处理:

通过见证添加的所有订单都与单元格数据中留下的旧订单一起处理

根据采购和销售订单分成两个队列,并根据pr按降序和升序排列

依次匹配两个队列的头顺序。如果价格匹配,将根据平均价格进行销售,并更新订单数量信息和用户账户余额信息

继续处理下一个订单,直到无法匹配

交易费用根据交易货币的相等比率(例如,0.1%)收取,该比率由聚合器运营商收取。

更简单的模型

从一月

一个更简单的模型是无区别存款/账户单元:

?存款指令:Alice生成一个新的udtcell(令牌a,金额x),将锁设置为DEX锁,锁参数指示令牌B,要交换的金额Y。该单元的解锁条件是输出中有一个令牌单元,数量=y,锁为爱丽丝锁。

接受订单:鲍勃观察链中所有带有DEX锁的单元格(订单),并选择其中一个或多个进行交易。

这种模式的优点是简单,只需要实现一个dex锁脚本。应用层结合链外的不同逻辑,实现场外交易和集中匹配交易。

摘要

本文初步设计了两种二层设计方案。可以看出,它们都充分利用了UTXO模型的自然聚合特性,完成了链外的事务聚合和匹配,降低了链上的事务量和用户的认知成本。与此同时,它确保了资产监管的权力下放和不信任。

与卷积序列技术相比,本文提出的事务聚合方案不使用零知识证明或乐观假设加挑战来降低用户事务验证的计算复杂度。因此,实际操作效率和块周期上限与单个非对称签名的周期比有关,该周期比预计在200和300 tps之间。尽管订单簿模式中的旧订单不需要再次验证交易签名,但是交易吞吐量的提高是有限的。然而,我们相信通过诸如零知识证明技术和集合签名技术的加密方案,我们可以极大地提高事务吞吐量。

微信二维码
售前客服二维码

文章均源于网络收集编辑侵删

提示:仅接受技术开发咨询!

郑重申明:资讯文章为网络收集整理,官方公告以外的资讯内容与本站无关!
NFT开发,NFT交易所开发,DAPP开发 Keywords: NFT开发 NFT交易所开发 DAPP开发