RFP: Decred Decentralized Exchange Infrastructure

RFP: Decred 去中心化交易设施(DEX)

原始提案链接:Decred Decentralized Exchange Infrastructure
该提案参与投票的票数为15667票,参与率约为38.2%; 赞成票为14411票,反对票为1256票,赞成率为91.98%;参与率和赞成率满足要求,该提案获得通过
详细情况如下图所示:
投票结果

摘要

现有的加密货币交换系统分为4个部分:托管(用户需要把币存在交易所),提供的服务(撮合等),token(交易平台上的token资产)和coin(交易平台上的coin资产)。该提案描述了一种基于开源软件的新型去中心化加密货币交换方式,它允许用户之间直接进行跨链交易,不仅收费低而且技术架构简单。系统内的订单将在每个epoch时间内随机匹配。用户需要支付费用,以阻止恶意的用户。客户端将与服务器和加密货币钱包进行通信,因此他们可以在相应的区块链上传递订单数据并创建原子交换,监控和运行兑换脚本。这项服务没有中心化实体,只是将需要的交易对在客户端之间进行传递。

动机

现有的交易所都直接或间接地是商业活动,其目的是从手续费中获利。去中心化交易解决了以下问题:
不必要的第三方:原子交换技术使中间商成为不必要。服务器只需协助价格发现和订单匹配过程,而且完全是非托管的。
流动性得到保证:开发人员可以通过原子交换直接添加交易对的支持,而不是说服交易所对币进行上架及交易对的开发。
交易费用低:服务为了防止恶意账户,会对账户收取一定的费用(类似保证金),但不会对每笔交易进行收费。
抑制低延迟客户端的优势:订单将在每个epoch时间内中使用伪随机过程进行匹配,因此低延迟客户端并没有对高延迟的客户端具有优势。这将保护市场流动性免受高频交易的影响。
交易的可信度:客户端和服务器处理的所有交易数据都将进行加密签名,因此客户端和服务器都可进行验证。部分客户端和服务器的恶意行为可以公示并独立确认。交易量可以直接在链上验证。
对威胁的抵御能力:简单的客户端 - 服务器体系结构意味着如果任何服务器被关闭,另一台服务器可以快速启动,需要的额外工作非常少。

通过解决现有的中心化交易所中存在的这些问题,我们可以在加密货币之间创建更加透明,公平和有弹性的交换过程。这些观点在2018年6月的博客中有更详细的论述。

这种改进的交换基础设施(DEX)将直接使Decred受益,使交换过程更加自由且投机性更低,从而使DCR的流通更方便并降低做市的风险,而且它也将作为一种通用基础设施使整个加密货币生态系统受益。这也可以成为DCR宣传的一个亮点。

实现

以下是对所涉及的各种流程如何进行的简单描述。注意,为了清楚和简洁起见,该说明仅解决部分交易中可能会碰到的问题,并且关注于如何正确的完成去中心化交易,预计承包商(实际开发人员)将妥善处理所有有可能出现的问题。

客户端-钱包:创建限价订单

  • 用户选择他们希望用于交易的金额,假定此时用户的币存在于A链上
  • 钱包A选择一个或多个UTXO,使其总和大于或等于客户指定的数量
  • 客户在钱包B中选取用于接收交换后的B币的地址
  • 客户A在钱包A中发起订单,生成的订单内容包括((金额,费率,链A的UTXO,B链地址)),并保护好相应的私钥。

客户端-钱包:取消订单

  • 客户请求钱包签署取消订单,该订单引用相应的限价订单,例如((限价订单哈希)),使用相应的私钥来证明资金的控制权

客户端-服务器:创建帐户

  • 客户端连接到服务器,并双方使用一个长期有效的PKI密钥对标识自己(避免用户连接到钓鱼服务器)
  • 服务器响应客户端,要求用户支付账户费用,以便用户获得服务器上的帐户
  • 用户支付费用,服务器为客户提供长期PKI公钥,使用户能访问一个或多个交易对市场

客户端-服务器:提交限价订单

  • 客户提交限价订单作为签名消息,订单包括未花费资金,金额和费率,其中签名证明对未花费资金的控制权和客户的有效身份
  • 服务器接收订单,添加时间戳,签名,存储交易信息并使用签名,回复客户端
  • 在删除用户的身份签名后,服务器将限制订单广播到其他连接的客户端上,并将订单添加到其订单簿中

客户端-服务器:提交限价订单

  • 客户提交取消订单,将其作为签名消息,其中签名显示对未花费资金的控制以及客户的长期身份
  • 服务器接收订单,添加时间戳,签名,存储它并使用签名订单回复客户端
  • 在删除用户的身份签名后,服务器将取消订单广播到其他连接的客户端,并从其订单簿中删除

客户端-服务器:提交市价订单

  • 客户端A提交市价订单作为签名消息,订单包括未花费资金,金额和费率,其中签名证明对未花费资金的控制权和客户的有效身份
  • 服务器接收订单,添加时间,签名,存储它并使用签名订单回复客户端A
  • 在一个epoch内进行订单的匹配(详见下文)
  • 服务器端公布已经匹配的订单并进行签名。在一个epoch结束时,更新订单簿(E1)
  • 客户端A在A链上启动原子交换
  • 客户端A将其原子交换合约提交给服务器,添加时间,进行签名
  • 服务器验证原子交换是否正确启动(E2)
  • 服务器将原子交换合约中继到服务器连接的客户端,添加时间,签署消息(E3)
  • 具有限价订单的客户端B验证交换
  • 具有限价订单的客户端B执行链B上的原子交换的第2步
  • 服务器验证原子交换步骤2是否正确执行(E4)
  • 客户端B在B链上赎回
  • 服务器验证B链赎回发生(E5)
  • 客户端A在A链上赎回
  • 服务器验证链条发生了赎回(E6)

客户端-服务器:请求当前订单簿

  • 客户端请求服务器发送订单簿的最新快照,客户端添加时间,签名消息
  • 服务器发送订单簿的最新聚合副本,添加时间,签署消息

服务器内部:订单匹配

  • 客户的市价订单在每个epoch时间内记录在服务器上的队列中
  • 在epoch结束时,将队列中的订单连接,并进行哈希操作,得到的哈希值用于确定队列中订单与订单簿中匹配的顺序,在订单簿侧使用 FIFO
  • 服务器得到该次epoch时间内的匹配摘要,添加时间,签名后向所有连接的客户端广播

客户端 - 服务器:历史数据请求

  • 客户端向服务器进行身份验证并请求历史数据
  • 服务器向客户端回复历史数据,回复的数据可能需要一些限制

除了必须支持的各种功能外,还有几个核心组件必须按顺序完成:

  1. 工程规范: 在编写代码之前,为本提案中描述的功能创建完整的RFC样式规范
  2. CLI工具
    • CLI客户端:通过准备签名订单,提交订单,跟踪订单,完成订单以及存储订单收据等方式来与钱包和服务器交互
    • CLI服务器:充当客户端的会合点,协助原子交换过程,使用收费墙(对每个账号收取费用),广播客户订单,匹配客户订单,以及每个epoch发布匹配的订单
  3. GUI客户端: 与现有的Decrediton钱包及其他钱包集成

理想情况下,代码将使用Go语言,使用带有TLS的gRPC和JSON-RPC(如果可能)连接到钱包,以及使用带TLS的gRPC连接到服务器。对产品最低要求为支持DCR / BTC交易对,其他对在以后添加。

承包商

这是一份RFP( Request For Proposal),我们先征求持票人的意见,然后才会进行投标以完成这项工作。如果该提案通过,之后将根据持票人的决定选择承包商。

项目时间

应该可以在不到6个月的时间内完成这项工作。

项目成本

据估计,这项工作将耗资100,000250,000美元。

后续工作

如果产品(只含有BTC/DCR交易对)运行良好,可以考虑建立服务器网络,网络共用一份聚合订单簿;为客户和服务器创建一个基于politeia的评分系统。

值得注意的变化

  • 删除了评分系统组件。因为在服务器网络和聚合订单簿完成之前没有评分系统的必要。这个建议是由matrix用户isuldor提出。
  • 根据评论中的反馈意见,将预计成本的上限从1,000,000美元大幅减少至250,000美元。* 添加了原始DEX博客文章的链接,以便于参考。
  • 澄清设计,CLI工具和GUI工具是按顺序完成的,而不是并行完成的。

results matching ""

    No results matching ""

    results matching ""

      No results matching ""