本文简要介绍路印协议3.0的工作原理，以及我们如何使用零知识证明技术来实现可扩展和安全的DEX。如果想深入学习，您可以在GitHub上查看完整的设计文档。
介绍
路印协议3.0解决了去中心化交易所的可扩展性问题。路印协议的早期版本已经实现了链下订单撮合，但还在链上进行交易结算，这意味着链上需要很高的计算和存储成本。为了解决这个问题，路印协议3.0通过使用零知识证明技术将几乎所有的数据和请求计算迁移到链下。
默克尔树（Merkle Tree）
数据存储在默克尔树（Merkle Tree）中，默克尔树（Merkle Tree）使用帐户模型。每个用户都有一个帐户，与他的以太坊地址一对一映射。该帐户可以存储交易所支持的所有代币余额和用户交易历史数据。请求会修改默克尔树（Merkle Tree），并且在链上通过证明来验证状态的转换。
区块
为了提高效率，请求按区块进行批量处理。无论区块中有多少请求，验证证明的成本都保持不变，但是我们会在区块中限制请求的数量，否则链上证明验证将不再有效。区块包含的请求数量取决于请求的复杂性。如果一个区块包含多个请求类型，那么执行每种请求类型的计算需要额外的花费，所以我们现在限制区块为单个请求类型。
目前我们支持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需要在一定时间内将请求包含在区块中。如果超过时间限制，我们首先强制运营商通过提交链上提款区块来处理它。如果运营商仍然拒绝处理提款请求，则交易所进入提现模式。提现模式是不可逆的，即使交易所完全关闭，用户仍然可以提取资金，这可确保用户在所有情况下都能完全控制其资金，而无需信任任何人。
获取路印协议更多最新的动态，请访问我们的社区帐号：
⭑ Twitter: twitter.com/loopringorg
⭑ Reddit: reddit.com/r/loopringorg
⭑ 电报: t.me/loopringfans (中文)
⭑ 微博: https://weibo.com/loopringfoundation