解锁隐私保护的去中心化金融。ZEX运行不需要协议级修改，也不需要协处理器。尽管在用户体验和gas费方面都很繁重，但这是一个早期的概念验证草案。任何反馈都将非常宝贵！

ZEX协议构建在cWETH保密代币模型之上。请先仔细查看它，然后再继续。

1. 引言

以太坊的透明性，虽然是其最宝贵的优势之一，但已成为现实世界金融采用的障碍。公共区块链默认会暴露余额、授权、交易对手方，甚至代币获取情况。

图6：保密交换流程4724×3600 435 KB

3.2.1. 报价放置

交换发起者公开定义并发布报价配置：交换汇率 rr（每个assetSell的assetBuy）和可用于交换的最大数量 MM 的assetSell。

通过调用publicConfidentialApprove函数，向指定的ZEX合约批准 MM 个代币，从而保证交换的卖出代币的可用性。

3.2.2. 报价接受

在接受报价之前，对方必须首先验证特定报价的公开允许额度是否存在，以及报价是否已被接受。

接受者然后选择在交换期间要接收的 bb (b \le M)(b≤M) 数量的assetSell，并根据约定的汇率 rr 计算出要支付给报价发起者的相应数量的assetBuy aa，取 a=bra=br。

之后，接受者必须通过confidentialApprove批准 aa 个assetBuy代币，指定ZEX合约为操作者，报价发起者为支出者。此外，接受者还需要提供零知识证明，证明所选数量不超过发起者发布的最大可用数量 bb。

3.2.3. 交换完成

为完成交换，报价发起者必须首先验证对方的保密允许额度对特定报价是否充足。

之后，报价发起者需要计算要卖给报价接受者的正确数量的assetSell。这是通过解密在confidentialApprove期间提供的 aa，并计算卖出数量 b=b= a \over rar。

发起者然后准备通过使用接受者的公钥加密来转移 bb 个assetSell代币，并计算剩余的assetSell允许额度 l=M-bl=M−b。

为转移约定的assetSell数量，ZEX合约调用publicConfidentialTransferFrom，将 bb 个代币添加到接受者的余额，同时将自我加密的剩余允许额度 ll 添加回发起者的待处理余额。最后，在同一笔交易中，发起者通过ZEX合约调用的confidentialTransferFrom接收 aa 个assetBuy作为付款，通过使用接受者在报价接受期间授予的保密允许额度。

总之，用户要么按指定汇率完成交换并交换代币，要么随时取消批准以停止交换过程。在任何时候，去中心化交易所都不会公开实际交换的数量，仅公开交换汇率和初始报价放置数量。

function cancelPublicConfidentialAllowance(address approver,address spender,bytes calldata balanceEncryptionData,bytes calldata amountCommitmentData,bytes calldata proofData) external;

余额加密数据用于存储退款后批准者的新的DH加密余额，而金额承诺数据表示实际津贴退款金额的ElGamal承诺。

4.4. ZEX函数

4.4.1. 发起交换报价

要创建交换报价，发起者需要调用以下函数：

function initiateOffer(address assetBuy,address assetSell,uint256 rate,uint256 maxAmountToSell,bytes calldata approveData) external returns (uint256 offerId);

approveData由initiateOffer函数中调用的publicConfidentialApprove所需的参数和零知识证明组成。

4.4.2. 接受报价

要接受现有报价，提供了acceptOffer函数：

function acceptOffer(uint256 offerId,bytes calldata approveData,bytes calldata proofData) external;

approveData存储acceptOffer函数中调用的confidentialApprove所需的数据。它还包括从发起者购买的assetSell的加密金额。proofData表示一个零知识证明，证明该金额在定义的最大可用报价金额范围内。

4.4.3. 完成交换

要完成点对点保密交换，报价发起者需要调用以下函数：

function finalizeSwap(uint256 offerId,bytes calldata transferFromDatabytes calldata proofData) external;

transferFromData由交换完成期间调用的publicConfidentialTransferFrom和confidentialTransferFrom函数所需的值组成。proofData参数是一个零知识证明，用于验证接受者购买金额的正确解密和发起者出售金额的计算。

• 接受者的私钥；
• 从发起者处购买的选定金额；
• ElGamal承诺中使用的随机数。

操作这些信号，电路必须具有以下约束：

1. 所提供的私钥确实是所提供的接受者公钥的私钥。
2. 所提供的从发起者处购买的金额是用于计算使用ElGamal承诺向发起者支付的金额。
3. 所提供的从发起者处购买的金额小于或等于最大可售金额。

5.2.2. 要约最终确认电路

用于最终确认交换要约证明的电路信号列表如下：

公共信号：

• 接受者的公钥；
• 发起者的公钥；
• 汇率；
• 从接受者处购买的assetBuy金额的ElGamal承诺；
• 向接受者出售的assetSell金额的ElGamal承诺。

私有信号：

• 发起者的私钥；
• 向接受者出售的金额；
• 用于出售金额的ElGamal承诺的随机数。

操作这些信号，电路必须具有以下约束：

1. 所提供的私钥确实是所提供的发起者公钥的私钥。
2. 所提供的向接受者出售的金额是从解密的从接受者处购买的金额计算得出的。
3. 所提供的向接受者出售的金额是使用ElGamal承诺提交的。

6. 安全考虑

ZEX协议存在几个必须强调的现有安全挑战。

1. 初始要约额度可能被用于推断实际交换的代币数量。如果要约发起者不小心处理公开批准，他们可能会泄露关于之前交换的信息。
2. 交换要约可能会被以少量购买代币接受而被篡改。一种潜在的缓解方法是让要约发起者指定他们可接受的购买代币范围，但这可能会导致泄露更多关于交换的信息。

7. 未来工作

尽管本文概述了ZEX协议和保密额度的主要功能概念，但仍有几个开放的研究方向。

首先，关于在交换要约期间管理最大可售金额存在未解决的设计问题。在当前规范中，保证可用出售金额的公共保密额度只能使用一次。未解决的问题是设计一种更robust的方法来动态更新公共额度金额，提供在不损害剩余额度资金保密性的情况下实施多次填充要约的能力。

其次，当前解决方案对要约的接受和最终确认使用多个零知识证明，这会引入显著的gas开销。在执行要约操作时，必须在单个交易中验证多个证明。例如，在要约最终确认期间，必须提供根据提供的购买金额正确计算出售金额的证明，以及publicConfidentialTransferFrom和confidentialTransferFrom函数调用的两个证明。尽管这种方法在代币批准模型使用方面看似一致，但它极大地增加了交换的整体成本。一种潜在的补救方法是将证明聚合委托给可信的协调器合约。然而，这引入了新的信任假设并扩大了潜在的攻击面。

第三，可以扩展ZEX协议以隐藏初始要约的价格，最终增加交换的隐私性，但会迫使发起者和接受者讨价还价。

参考文献

以太坊隐私：通向自主权的道路
保密包装的以太坊