http://www.7klian.com

十分钟速览路印协议 3.0 利用 ZKP 扩容的道理及实践

用户流程充值

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

DEX 通过笼络两个订单和向 DEX 运营商发送请求,来建设结算请求,该 DEX 运营商将把请求包括在区块中,以得到指定的用度,然后运营商在链上提交区块。

一旦 DEX 运营商(Operator)在链上提交了一个区块,他还需要在限按时间内提交该区块的证明。因为生成证明需要一些时间,区块和证明的提交是分隔举办的。一旦生成证明,运营商就可以发送链上的证明,从而验证区块中完成的状态转换。假如运营商不能实时提交有效证明,他将受到惩罚,状态将自动规复为有效状态。

...

双重授权,以防备订单或环路结算被窃取

链上提现

链下打消订单

生意业务结算

今朝我们支持 5 种差异的请求:

向 DEX 付出用度

生意业务

用户对订单举办签名,订单包括 DEX 结算订单所需的所有数据。该协议支持:

本文扼要先容路印协议 3.0 的事情道理,以及如何利用零常识证明技能来实现可扩展和安详的 DEX。假如想深入进修,可以在 GitHub 上查察完整的设计文档。

以下是路印协议连系首创人兼 CMO Jay Zhou 对路印协议 3.0 详细技能实现的扼要概述。

Jay Zhou,路印协议连系首创人兼 CMO

市场订单

默克尔树(Merkle Tree)

数据存储在默克尔树(Merkle Tree)中,默克尔树(Merkle Tree)利用帐户模子。每个用户都有一个帐户,与他的以太坊地点一对一映射。该帐户可以存储生意业务所支持的所有代币余额和用户生意业务汗青数据。请求会修改默克尔树(Merkle Tree),而且在链上通过证明来验证状态的转换。

充值

从 DEX 向订单拥有者返佣

订单笼络完全取决于 DEX,但在所有环境下,生意业务结算都遵守订单建设者的意愿。

提款

郑重声明:本文版权归原作者所有,转载文章仅为传播更多信息之目的,如作者信息标记有误,请第一时间联系我们修改或删除,多谢。

说点什么吧
  • 全部评论(0
    还没有评论,快来抢沙发吧!