路印协议:零知卷叠交易与支付去中心化撮合交易协议

项目介绍

路印协议采用零知识证明技术，允许开发者在以太坊上搭建高吞吐量、低成本、非托管、基于订单本的去中心化交易平台。

路印协议安全

路印协议代码百分百开源，并经过独立第三方的安全审计。作为非托管交易协议，路印保障用户资产与以太坊主网一样安全。

路印协议高性能

路印协议在保障用户资产绝对安全的前提下，在以太坊主网上可以承载每秒2025笔交易。去中心化交易所作为严肃的商业模式第一次可以落地运营。

路印协议低成本

路印协议在以太坊主网每笔交易的成本不足0.001人民币。做市商和专业交易机构第一次可以彻底摆脱中心化交易平台的各种不公平约定和限制。

路印协议吞吐量显著提高

路印协议3.0每秒可清算高达2025笔交易，并保障资产安全性和以太坊本身的安全级别一致。这有赖于零知卷叠（zkRollup）中的链上数据可用性（On-Chain Data Availability），简称OCDA。如果交易所选择关闭链上数据可用性，用户资产安全性就是联盟链级别 - 用户需要信任交易所提供的链外数据可用性解决方案，确保在交易所关闭甚至跑路后依然可以将资产提现出来。关闭数据可用性后（即Validium模式），路印协议的吞吐量可高达每秒16400笔交易。

交易成本大幅降低

路印协议3.0每百万笔清结算费用不到1000人民币左右，其中包含了以太坊油费和链外生成零知识证明的链外费用。这个平均费用还可以通过使用性价比更高的服务器和基于GPU的算法得到进一步的改善。美股代理商每笔股票买卖的手续费也在14到50人民币之间，因此同时保障无风险交易和每笔交易成本不到0.1分钱的性能，路印已具有巨大的商业应用价值。

路印协议设计理念

路印协议3.0的核心设计目标包括两个：第一是高安全性，第二是高性能。协议设计的很多方面，都是围绕着在各种可能的情况下，为用户提现自己充值的资产提供各种保障。这种保障允许用户在极端情况下，仅提供默克尔证明，不依靠于交易所的任何动作，就可以将资产全部取出。而默克尔证明，则可以通过区块链上的数据可用性计算得到。

为了提高吞吐量，并降低清结算成本，路印协议3.0将几乎全部的计算都迁移到区块链外完成。这种计算会更新中继维护的一棵四叉默克尔树，用以保存每个用户每个币种的余额，以及每个订单的成交历史。 中继批量处理几十到几万个充值提现和交易清结算等请求，并将批量更新后的树根上链。为了保障中继的计算更新方式严格遵循协议的规则，中继必须在一定时间内提供批量处理相关的零知识证明。

路印协议3.0的安全性、高吞吐量、和低成本证明了零知卷叠（zkRollup）思路是去中心化应用扩容的最佳方式之一。二层协议消极依靠底层公有链来扩容是不可取的。

路印协议多种部署选项

路印协议3.0提供下列四种部署选项用以支持去中心化交易所的协议升级。请注意协议升级的前提是新协议版本的数据结构是向后兼容的。

自动升级模式

在这种模式下，当具有兼容性的协议新版本发布后，交易所就会自动升级到使用协议的最新版。交易所和用户对协议的升级没有感知，不会影响用户体验。这种模式也意味着交易所需要信任路印协议后续的版本。

这是我们推荐的部署模式。通过自动升级，交易所可以第一时间获得协议的漏洞补丁和新特性。

手动升级模式

手动升级模式依靠于交易所拥有者决定是否升级到具有兼容性的协议新版本。在这种模式下，交易所拥有者无需信任路印基金会以及任何新版协议，他们自行决定是否升级、何时升级、以及升级到哪个版本。

手动升级对交易所用户依然是完全透明且无缝的，因此对用户充值提现以及中继的运行都没有任何影响。

代理模式

代理模式不支持交易所协议升级，这意味着一旦发现现有版本协议有安全漏洞，交易所运营者只能选择关闭交易所，并帮助用户提现已充值资产。

这种模式的优势是部署非常节省油费，不过我们不建议在产品环境下使用该模式。

原生模式

该模式也不支持协议的升级，并且部署消耗的油费也很多。这种模式的优点是部署后每笔以太坊转账的费用都是最优的。

如果交易所对协议升级不感兴趣，且想最小化运营成本，可以考虑使用这种模式。

我们建议在节省油费和协议升级之间，选择可升级性。

本文简要介绍路印协议3.0的工作原理，以及我们如何使用零知识证明技术来实现可扩展和安全的DEX。如果想深入学习，您可以在GitHub上查看完整的设计文档。

路印协议3.0介绍

路印协议3.0解决了去中心化交易所的可扩展性问题。路印协议的早期版本已经实现了链下订单撮合，但还在链上进行交易结算，这意味着链上需要很高的计算和存储成本。为了解决这个问题，路印协议3.0通过使用零知识证明技术将几乎所有的数据和请求计算迁移到链下。

默克尔树（MERKLE TREE）

数据存储在默克尔树（Merkle Tree）中，默克尔树（Merkle Tree）使用帐户模型。每个用户都有一个帐户，与他的以太坊地址一对一映射。该帐户可以存储交易所支持的所有代币余额和用户交易历史数据。请求会修改默克尔树（Merkle Tree），并且在链上通过证明来验证状态的转换。

区块

为了提高效率，请求按区块进行批量处理。无论区块中有多少请求，验证证明的成本都保持不变，但是我们会在区块中限制请求的数量，否则链上证明验证将不再有效。区块包含的请求数量取决于请求的复杂性。如果一个区块包含多个请求类型，那么执行每种请求类型的计算需要额外的花费，所以我们现在限制区块为单个请求类型。

目前我们支持5种不同的请求：

1. 交易结算
2. 充值
3. 链上提现
4. 链下提现
5. 链下取消订单

构建功能完备的DEX，只有前三个是必需的，后两个为用户和交易所提供了一些额外的灵活性。

一旦DEX运营商（Operator）在链上提交了一个区块，他还需要在限定时间内提交该区块的证明。因为生成证明需要一些时间，区块和证明的提交是分开进行的。一旦生成证明，运营商就可以发送链上的证明，从而验证区块中完成的状态转换。如果运营商不能及时提交有效证明，他将受到处罚，状态将自动恢复为有效状态。

数据可用性（DATA AVAILABILITY）

只有默克尔树根 （Merkle tree root ）存储在链上，这足以证明用户在DEX持有一定数量的代币。即使DEX运营商不合作，任何用户都可以在提现模式下提取他们的资金。

用户需要创建默克尔证明，因此他们需要访问完整的默克尔树，而不仅仅是默克尔树根。这些数据最好由DEX提供，但不能保证实际情况就是如此。为了确保所有用户都能获得数据，这些数据是在链上发送的，这是使用CALLDATA完成的，而不是存储，这样成本更低且更具前瞻性。目前，以太坊的成本仍然很高（虽然这在未来将有所改善），也限制了可以实现的最大吞吐量，这也是我们支持关闭链上数据可用性的原因，DEX可以自由地实施一些链下解决方案。

用户流程

充值

交易开始之前，用户首先需要将一些资金充值到智能合约，这是通过链上交易完成的，并且请求会被添加到链上充值队列中。一旦DEX运营商将充值请求放在一个区块中，用户就可以开始交易。

交易
用户对订单进行签名，订单包含DEX结算订单所需的所有数据。该协议支持：

• 挂单（Maker）/吃单（Taker)（使用相同的订单）
• 市场订单
• 向DEX支付费用
• 从DEX向订单拥有者返佣
• 订单自动缩放
• 订单部分成交
• 双重授权，以防止订单或环路结算被窃取
• ...

订单撮合完全取决于DEX，但在所有情况下，交易结算都遵守订单创建者的意愿。

DEX通过撮合两个订单和向DEX运营商发送请求，来创建结算请求，该DEX运营商将把请求包含在区块中，以获得指定的费用，然后运营商在链上提交区块。

提款

如果用户想要从交易所提取他们的代币，他们需要做提款请求。如果用户在链上请求提款，DEX需要在一定时间内将请求包含在区块中。如果超过时间限制，我们首先强制运营商通过提交链上提款区块来处理它。如果运营商仍然拒绝处理提款请求，则交易所进入提现模式。提现模式是不可逆的，即使交易所完全关闭，用户仍然可以提取资金，这可确保用户在所有情况下都能完全控制其资金，而无需信任任何人。