解鎖隱私保護的去中心化金融。ZEX執行不需要協議級修改，也不需要協處理器。儘管在使用者體驗和gas費方面都很繁重，但這是一個早期的概念驗證草案。任何反饋都將非常寶貴！
ZEX協議構建在cWETH保密代幣模型之上。請先仔細檢視它，然後再繼續。
1. 引言
以太坊的透明性，雖然是其最寶貴的優勢之一，但已成為現實世界金融採用的障礙。公共區塊鏈預設會暴露餘額、授權、交易對手方，甚至代幣獲取情況。
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承諾中使用的隨機數。
操作這些訊號，電路必須具有以下約束：
- 所提供的私鑰確實是所提供的接受者公鑰的私鑰。
- 所提供的從發起者處購買的金額是用於計算使用ElGamal承諾向發起者支付的金額。
- 所提供的從發起者處購買的金額小於或等於最大可售金額。
5.2.2. 要約最終確認電路
用於最終確認交換要約證明的電路訊號列表如下：
公共訊號：
- 接受者的公鑰；
- 發起者的公鑰；
- 匯率；
- 從接受者處購買的assetBuy金額的ElGamal承諾；
- 向接受者出售的assetSell金額的ElGamal承諾。
私有訊號：
- 發起者的私鑰；
- 向接受者出售的金額；
- 用於出售金額的ElGamal承諾的隨機數。
操作這些訊號，電路必須具有以下約束：
- 所提供的私鑰確實是所提供的發起者公鑰的私鑰。
- 所提供的向接受者出售的金額是從解密的從接受者處購買的金額計算得出的。
- 所提供的向接受者出售的金額是使用ElGamal承諾提交的。
6. 安全考慮
ZEX協議存在幾個必須強調的現有安全挑戰。
- 初始要約額度可能被用於推斷實際交換的代幣數量。如果要約發起者不小心處理公開批准，他們可能會洩露關於之前交換的資訊。
- 交換要約可能會被以少量購買代幣接受而被篡改。一種潛在的緩解方法是讓要約發起者指定他們可接受的購買代幣範圍，但這可能會導致洩露更多關於交換的資訊。
7. 未來工作
儘管本文概述了ZEX協議和保密額度的主要功能概念，但仍有幾個開放的研究方向。
首先，關於在交換要約期間管理最大可售金額存在未解決的設計問題。在當前規範中，保證可用出售金額的公共保密額度只能使用一次。未解決的問題是設計一種更robust的方法來動態更新公共額度金額，提供在不損害剩餘額度資金保密性的情況下實施多次填充要約的能力。
其次，當前解決方案對要約的接受和最終確認使用多個零知識證明，這會引入顯著的gas開銷。在執行要約操作時，必須在單個交易中驗證多個證明。例如，在要約最終確認期間，必須提供根據提供的購買金額正確計算出售金額的證明，以及publicConfidentialTransferFrom和confidentialTransferFrom函式呼叫的兩個證明。儘管這種方法在代幣批准模型使用方面看似一致，但它極大地增加了交換的整體成本。一種潛在的補救方法是將證明聚合委託給可信的協調器合約。然而，這引入了新的信任假設並擴大了潛在的攻擊面。
第三，可以擴充套件ZEX協議以隱藏初始要約的價格，最終增加交換的隱私性，但會迫使發起者和接受者討價還價。
