개인정보 보호 DeFi의 가능성을 열어드립니다. 프로토콜 수준의 수정이나 ZEX 작동을 위한 보조 프로세서가 필요하지 않습니다. UX 측면(및 가스 비용)이 매우 중요하지만, 이는 초기 PoC 초안입니다. 여러분의 피드백은 매우 소중합니다!

ZEX 프로토콜은 cWETH 기밀 토큰 모델을 기반으로 구축되었습니다. 진행하기 전에 먼저 확인해 주세요.

1. 서론

이더리움의 투명성은 가장 중요한 장점 중 하나이지만, 실제 금융 도입의 장벽이 되었습니다. 퍼블릭 블록체인은 기본적으로 잔액, 승인, 거래 상대방, 심지어 토큰 취득까지 공개합니다.

이 제안은 cWETH를 기밀 토큰 모델로 사용하는 허가가 필요 없고 기밀성이 보장되는 P2P(Peer-to-Peer) 탈중앙화 거래소(DEX) 메커니즘인 ZEX를 소개합니다. ZEX는 기밀 허용을 통해 토큰 기능을 확장하여 숨겨진 P2P(Peer-to-Peer) 상호작용을 가능하게 합니다. cWETH 프로토콜과 유사하게, ZEX 로직은 타원 곡선(EC) 트위스티드 엘가말(Twisted ElGamal) 기반 커밋먼트 체계를 활용하여 기밀성을 보장하고, EC 디피-헬만(DH)을 통해 가치 접근성을 제공하며, zk-SNARK를 통해 토큰 승인 및 이체 시 실제 거래 금액을 공개하지 않고 잔액 업데이트의 정확성을 검증합니다.

ZEX 프로토콜은 스왑 오퍼를 위한 마켓플레이스 역할을 합니다. 3단계 상호작용 방식으로 거래가 이루어지고, 동일 거래 내에서 여러 ZK 증명을 검증해야 합니다. ZEX가 공개하는 유일한 정보는 가격과 초기 매수 허용량(Initial Offer Allowance)으로, 이는 특정 거래소에서 사용 가능한 최대 토큰 수량을 나타냅니다.

프로토콜을 수정하면 개인정보 보호 가정을 높이기 위해 스왑 가격이 숨겨질 수도 있습니다.

2. 기밀 토큰 허용 모델

기밀 P2P 스왑을 수행하려면 기밀 토큰에 대해 approve 및 transferFrom 흐름을 정의해야 합니다.

이러한 흐름은 총 6개의 새로운 기능에 의해 관리됩니다.

1. confidentialApprove는 승인된 금액을 공개하지 않고 기존 암호화 키를 사용하여 EOA에 토큰을 승인하는 것을 의미합니다.
2. confidentialTransferFrom 은 이체 금액을 공개하지 않고 승인된 토큰을 기밀로 이체합니다.
3. publicConfidentialApprove 는 스마트 계약에 토큰을 한 번만 승인하고 승인된 금액을 공개합니다.
4. publicConfidentialTransferFrom은 전송 금액을 공개하지 않고 공개적으로 승인된 토큰을 전송합니다.
5. cancelConfidentialApprove는 취소 금액을 공개하지 않고 기밀 승인을 취소합니다.
6. cancelPublicConfidentialApprove를 클릭하면 공개 승인을 취소하고 취소 금액을 공개합니다.

이러한 함수에서 사용되는 암호화에 대한 심층적인 사양은 원본 cWETH 논문을 참조하세요.

2.1. 기밀 승인 및 전송

일반적인 ERC-20 승인 로직과 달리, 기밀 승인은 승인자의 잔액 감소로 이어집니다. 기밀 전송 과정에서는 잔액이 암호화되어 있어, 지출자가 승인자의 잔액이 충분한지 확인할 수 없기 때문입니다.

또한, 기밀 승인 작업에는 운영자 주소가 필요하며, 이는 일반적인 ERC-20 지출자 주소 및 허용량에 대한 보완적인 역할을 합니다. 운영자 주소가 지정되면 지출자는 confidentialTransferFrom을 호출하여 토큰을 수신할 수 없으며, 운영자만 해당 작업을 수행할 수 있습니다. 이 제약 조건은 기밀 transferFrom의 보안 및 사용자 정의에 매우 중요한데, 승인자가 스마트 계약을 운영자로 지정하여 추가적인 전송 검증을 시행할 수 있기 때문입니다.

EOA에 대한 기밀 승인 흐름은 다음 다이어그램에 표시되어 있습니다.

그림 1: 기밀 승인 흐름 1142×758 160KB

허용량이 승인되면 사용자는 승인된 토큰을 받을 수 있습니다. 아래 그림은 기밀 전송(transferFrom) 프로세스를 보여줍니다.

그림 2: 기밀 전송 흐름 1920×1405 176KB

기밀 승인 및 전송은 5가지 다른 암호화된 금액으로 작동한다는 것을 이해하는 것이 중요합니다.

1. 허용 금액이 승인된 후 새로운 잔액을 나타내는 승인자 자체 ECDH 키입니다.
2. 승인 취소 시 승인자가 해당 금액을 사용할 수 있도록 승인자의 ElGamal 공제 약정을 설정합니다. 이 약정은 공제 승인 후 새로운 잔액을 나타내기 위해 승인자의 잔액 약정에서 차감됩니다.
3. 승인자/지출자 ECDH 공유 키로 암호화된 허용 금액은 허용 금액 가용성을 나타냅니다.
4. 지출자의 ElGamal 수당 약정은 수당 지출 시 보류 잔액에 추가됩니다.
5. 할당량을 사용한 후 새로운 지출자 잔액을 사용할 수 있도록 자체 ECDH 키로 암호화된 수신 토큰 금액입니다.

2.2. 공개 기밀 승인 및 전송

일부 시나리오에서는 암호화 키를 사용하는 EOA가 아닌 스마트 계약에 직접 토큰을 승인해야 합니다. 스마트 계약은 기밀 개인 키를 보유하지 않기 때문에 기밀 허용량 값을 해독할 수 없습니다. 더욱이, 이 경우 승인자는 수신자를 미리 알지 못하며 특정 공개 키의 값을 암호화할 수 없습니다. 따라서 스마트 계약에 대한 기밀 허용량은 승인된 금액을 공개적으로 공개해야 합니다.

아래 다이어그램은 공개 기밀 승인 흐름을 보여줍니다.

그림 3: 공개 기밀 승인 흐름 3099×1750 379KB

승인 금액이 평문으로 명시되므로, 공개 기밀 허용량은 전체 및 원자 단위로 사용되어야 하며, 이는 일회성 승인으로 간주됩니다. 다시 말해, 공개 허용량이 완전히 사용되지 않으면 개인정보 보호 가정에 따라 남은 금액은 승인자의 공개 키로 다시 암호화되어 동일한 거래에서 승인자의 보류 잔액에 다시 추가됩니다. 이는 허용량 값을 공개적으로 업데이트하면 이체되는 금액의 기밀성이 손상될 수 있기 때문입니다.

공공비밀수당의 지출흐름은 다음 다이어그램과 같습니다.

그림 4: 공개 기밀 전송 흐름 1920×681 118KB

일반적인 기밀 transferFrom과의 주요 차이점은 남은 허용액이 전용 허용액 저장소에 저장되는 대신 암호화되어 승인자의 보류 잔액에 다시 추가된다는 점입니다.

2.3. 수당 취소

이 프로토콜에는 승인자가 EOA에 암호화된 허용량으로 부여된 경우든, 계약에 대한 공개 허용량으로 부여된 경우든 기밀 허용량을 취소할 수 있는 메커니즘도 포함되어 있습니다.

비밀 수당 취소 흐름은 아래 다이어그램에 표시되어 있습니다.

그림 5: 수당 취소 흐름 1920×563 100KB

기밀 허용 취소 절차는 모든 암호화된 금액이 기밀 승인 및 전송 작업에 저장되므로 매우 간단합니다. 필요한 작업은 해당 금액을 승인자의 보류 잔액에 다시 추가하는 것뿐입니다.

하지만 공개 취소에는 남은 수당의 암호화를 검증하기 위한 ZK 증명도 필요합니다.

3. ZEX 프로토콜 개요

3.1. 전제 조건

DEX가 올바르게 작동하려면 스왑 프로세스가 원활하고 일관되게 유지되도록 몇 가지 조건이 충족되어야 합니다.

• 모든 참여 당사자는 기밀 공개 키를 공개해야 합니다. 이 키는 기반 기밀 토큰에 사용되는 체계에 따라 EC ElGamal 커밋과 ECDH 암호화에 모두 사용됩니다.
• 제안 개시자는 제안에서 제공하려는 최대 금액을 충당하기 위해 판매 자산에 충분한 기밀 토큰을 보유해야 합니다.
• 제안 수락자는 지정된 환율에 따라 합의된 금액을 지불하기 위해 매수 자산에 충분한 기밀 토큰을 보유해야 합니다.
• 제안 수락자는 스왑 거래의 자기 부분을 준비하기 전에 제안 세부 정보에 접근해야 합니다. 구체적으로, 제안 개시자는 환율과 자산의 최대 매도 가능 금액을 공개적으로 공시해야 합니다.

3.2. 피어투피어 스왑 흐름

다음 섹션에서는 이전에 정의된 기밀 허용 모델을 기반으로 하는 기밀 P2P 스왑의 실행 흐름을 설명합니다. 교환 프로세스는 상호작용적이며, 제안 제출 , 제안 수락 , 스왑 완료의 세 단계로 구성됩니다.

전체 스왑 흐름은 아래 다이어그램에 표시되어 있습니다.

그림 6: 기밀 스왑 흐름 4724×3600 435KB

3.2.1. 제안 배치

스왑 개시자는 공개적으로 제안 구성을 정의하고 게시합니다. 여기에는 환율 r r (자산 매수 대 자산 매도)과 교환 가능한 자산 매도의 최대 금액 M M 이 포함됩니다.

스왑을 위한 판매 토큰의 가용성은 publicConfidentialApprove 함수를 호출하여 지정된 ZEX 계약에 M M 토큰을 승인함으로써 보장됩니다.

3.2.2. 제안 수락

제안을 수락하기 전에 상대방은 먼저 해당 제안에 대한 공적 허용이 있는지, 그리고 제안이 이미 수락되지 않았는지 확인해야 합니다.

그런 다음 수락자는 스왑 동안 수신할 assetSell의 금액 b b (b \le M) ( b ≤ M ) 을 선택하고 합의된 비율 r r 에 따라 제안 개시자에게 지불할 assetBuy a a 의 해당 금액을 계산합니다. 이때 a=bra = b r 이 됩니다.

그 후, 수락자는 confidentialApprove를 통해 자산 매수 토큰 을 승인해야 하며, 이때 ZEX 계약을 운영자로, 제안 개시자를 지출자로 지정해야 합니다. 또한, 수락자는 선택된 금액이 개시자가 게시한 최대 사용 가능 금액 (b b ) 을 초과하지 않음을 증명하는 ZK 증명을 제공해야 합니다.

3.2.3. 스왑 완료

스왑을 마무리하려면 제안 개시자는 먼저 상대방의 비밀 허용 한도가 특정 제안에 충분한지 확인해야 합니다.

이후, 제안 개시자는 제안 수락자에게 판매할 자산(assetSell)의 정확한 금액을 계산해야 합니다. 이는 기밀 승인(confidentialApprove) 과정에서 제공된 자산 (a ) 을 복호화하고 판매 금액 (b= b = a \over r a r ) 을 계산함으로써 수행됩니다. .

그런 다음 개시자는 수락자의 공개 키로 암호화하고 남은 assetSell 허용량 l=Mb l = M − b 를 계산하여 assetSell의 b b 토큰 전송을 준비합니다.

합의된 자산 매도 금액을 이체하기 위해 ZEX 계약은 publicConfidentialTransferFrom을 호출합니다. 이 함수는 수락자의 잔액에 b b 토큰을 추가하고, 자체 암호화된 할당량 잔액 l l 은 개시자의 보류 잔액에 다시 추가됩니다. 마지막으로, 동일한 거래 내에서 개시자는 ZEX 계약에서 호출한 confidentialTransferFrom을 통해 assetBuy에서 a a 를 지급받습니다. 이 지급은 제안 수락 시 부여된 수락자의 기밀 할당량을 사용하여 이루어집니다.

요약하자면, 사용자는 지정된 환율에 따라 스왑 및 토큰 교환을 완료하거나, 언제든지 승인을 취소하여 스왑 프로세스를 중단할 수 있습니다. DEX는 실제 교환 금액을 공개하지 않으며, 환율과 최초 매수 매수 금액만을 기준으로 공개적으로 운영됩니다.

4. Solidity 스마트 계약

4.1. 기밀 토큰 상태 변수

4.1.1. 비밀 허용

기밀 수당 데이터는 다음 구조에 저장됩니다.

 struct ConfidentialAllowance {address operator;bytes amountEncryptionData;bytes amountCommitmentData;}

암호화 및 커밋 데이터는 기밀 토큰 사양에 따라 추가로 디코딩됩니다.

허용량은 매핑에 저장됩니다.

 mapping(address approver => mapping(address spender => ConfidentialAllowance)); 

4.1.2. 공공 비밀 허용

계약에 부여된 기밀 허용량은 매핑에 저장되며, 승인된 금액은 일반 텍스트로 제공됩니다.

 mapping(address approver => mapping(address spender => uint256));

4.2. ZEX 상태 변수

4.2.1. 제안 데이터

스왑 제안은 아래 구조로 정의됩니다.

 struct Offer {address initiator;address acceptor;address assetBuy;address assetSell;uint256 rate;uint256 maxAmountToSell;bytes amountToBuyEncryptionData;bytes amountToBuyCommitmentData;}

제안은 간단한 매핑에 저장됩니다.

 mapping(uint256 offerId => Offer); 

4.3. 기밀 토큰 함수

4.3.1. 비밀 허용 허용

등록된 EOA에 기밀 허용을 부여하려면 confidentialApprove 함수를 호출해야 합니다.

 function confidentialApprove(address approver,address spender,address operator,bytes calldata amountEncryptionData,bytes calldata amountCommitmentData,bytes calldata proofData) external;

암호화 및 약정 데이터 매개변수는 cWETH 프로토콜의 전송 함수와 유사하게 승인자와 지출자의 공개 키로 암호화된 값을 저장합니다.

4.3.2. 공공 기밀 허용

계약에 대한 허용을 부여하기 위해 publicConfidentialApprove 함수가 제공됩니다.

 function publicConfidentialApprove(address approver,address spender,uint256 amount,bytes calldata newBalanceEncryptionData,bytes calldata amountCommitmentData,bytes calldata proofData) external;

이 기능의 암호화 및 약정 데이터 매개변수는 승인자의 공개 키로 암호화된 새 잔액 및 금액 값을 저장하여 승인 후 잔액을 업데이트하기 위한 것입니다.

4.3.3. 비밀수당 지출

기밀 승인을 수행하려면 운영자가 다음 함수를 호출해야 합니다.

 function confidentialTransferFrom(address approver,address spender,bytes calldata amountEncryptionData,bytes calldata amountCommitmentData,bytes calldata proofData) external;

암호화 및 약정 데이터 매개변수는 지출자의 공개 키로 암호화된 이체 금액과 이체 후 남은 허용 금액을 승인자의 공개 키로 암호화하여 저장합니다.

4.3.4. 공공비밀수당 지출

공개 기밀 수당을 사용하려면 지출자 계약에서 아래 함수를 호출해야 합니다.

 function publicConfidentialTransferFrom(address approver,address receiver,bytes calldata amountEncryptionData,bytes calldata amountCommitmentData,bytes calldata proofData) external;

암호화 및 커밋 데이터 매개변수에는 수신자의 공개 키로 암호화된 이체 금액과 승인자의 공개 키로 자체 암호화된 잔여 허용 금액이 포함됩니다.

4.3.5. 비밀 수당 취소

EOA에 부여된 기밀 허용을 취소하려면 승인자는 아래 기능을 사용해야 합니다.

 function cancelConfidentialAllowance(address approver,address spender,bytes calldata proofData) external;

승인자가 msg.sender와 같지 않은 경우, proofData에는 승인자의 개인 키 소유를 검증하는 ZK 증명이 포함됩니다.

4.3.6. 공공비밀 허용 취소

계약에 부여된 공공 수당을 취소하려면 다음 기능을 사용해야 합니다.

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

balanceEncryptionData는 환불 후 승인자의 새로운 DH 암호화 잔액을 저장하는 데 사용되고, amountCommitmentData는 실제 수당 환불 금액에 대한 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에 필요한 매개변수와 ZK 증명으로 구성됩니다.

4.4.2. 제안 수락

기존 제안을 수락하려면 acceptOffer 함수가 제공됩니다.

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

approveData는 acceptOffer 함수 내에서 호출되는 confidentialApprove에 필요한 데이터를 저장합니다. 또한 개시자로부터 구매할 assetSell의 암호화된 금액도 포함합니다. proofData는 이 금액이 제안의 정의된 최대 사용 가능 금액 범위 내에 있음을 증명하는 ZK 증명을 나타냅니다.

4.4.3. 스왑 마무리하기

P2P 기밀 스왑을 마무리하려면 제안 개시자가 아래 함수를 호출해야 합니다.

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

transferFromData는 스왑 완료 과정에서 호출되는 \newline publicConfidentialTransferFrom 및 confidentialTransferFrom 함수에 필요한 값으로 구성됩니다. proofData 매개변수는 수락자의 매수 금액과 개시자의 매도 금액의 정확한 복호화를 검증하는 데 사용되는 ZK 증명입니다.

5. ZK 회로

이 제안서에 설명된 모든 매개변수는 체인상에서 검증 가능하고 제로 지식 회로와 호환되도록 설계되었습니다.

5.1. 기밀 토큰 회로

5.1.1. 기밀 승인 회로

기밀 승인 증명을 위한 회로 신호 목록은 다음과 같습니다.

공공 신호:

• 승인자의 공개 키
• 스펜더의 공개 키;
• ElGamal은 승인자의 잔액에 대한 약속을 합니다.
• ElGamal은 승인자의 공개 키에 따라 허용 금액을 확정합니다.
• ElGamal은 지출자의 공개 키에 따라 허용 금액을 약속합니다.
• 새로운 승인자의 잔액은 승인자의 DH 자체 키로 암호화됩니다.
• 승인자의 새로운 잔액 암호화에 사용되는 무작위 nonce
• 지출자의 공개 키 기반 DH 공유 키로 암호화된 허용 금액
• 지출자의 허용 금액을 암호화하는 동안 사용되는 무작위 nonce입니다.

개인 신호:

• 승인자의 개인 키
• 승인자의 잔액;
• 허용 금액
• 승인자의 ElGamal 약속에 사용되는 무작위 nonce.
• 지출자의 ElGamal 약속에 사용되는 무작위 nonce입니다.

이러한 신호를 작동시키려면 회로에 다음과 같은 제약 조건이 있어야 합니다.

1. 제공된 개인 키는 실제로 제공된 승인자의 공개 키의 개인 키입니다.
2. 제공된 승인자의 잔액은 ElGamal 약정을 사용하여 약정된 잔액이며 허용 금액보다 크거나 같은 것으로 입증됩니다.
3. 승인자의 ElGamal 공제 금액 약정이 올바르게 생성되었습니다.
4. 지출자의 허용 금액에 대한 ElGamal 약정이 올바르게 생성되었습니다.
5. 승인자의 새로운 잔액은 승인자의 공개 키 기반 DH 공유 키로 올바르게 암호화되었습니다.
6. 허용 금액은 지출자의 공개 키 기반 DH 공유 키로 올바르게 암호화되었습니다.

5.1.2. 공개 기밀 승인 회로

공개 기밀 승인 증명을 위한 회로 신호 목록은 다음과 같습니다.

공공 신호:

• 승인자의 공개 키
• 허용 금액
• ElGamal은 승인자의 잔액에 대한 약속을 합니다.
• ElGamal은 승인자의 공개 키에 따라 허용 금액을 확정합니다.
• 새로운 승인자의 잔액은 승인자의 DH 자체 키로 암호화됩니다.
• 승인자의 새로운 잔액 암호화에 사용되는 무작위 nonce입니다.

개인 신호:

• 승인자의 개인 키
• 승인자의 잔액;
• 이체 금액;
• 승인자의 ElGamal 약속에 사용되는 무작위 nonce입니다.

이러한 신호를 작동시키려면 회로에 다음과 같은 제약 조건이 있어야 합니다.

1. 제공된 개인 키는 실제로 제공된 승인자의 공개 키의 개인 키입니다.
2. 제공된 승인자의 잔액은 ElGamal 약정을 사용하여 약정된 잔액이며 허용 금액보다 크거나 같은 것으로 입증됩니다.
3. 승인자의 ElGamal 공제 금액 약정이 올바르게 생성되었습니다.
4. 승인자의 새로운 잔액은 승인자의 공개 키 기반 DH 공유 키로 올바르게 암호화되었습니다.

5.1.3. 기밀 전송 회로

기밀수당 증명을 위한 회로신호 목록은 다음과 같습니다.

공공 신호:

• 승인자의 공개 키
• 스펜더의 공개 키;
• 스펜더의 엘가말 수당 공약;
• ElGamal은 지출자의 공개 키에 따라 이체 금액을 약속합니다.
• ElGamal은 승인자의 공개 키를 기반으로 이체 금액을 확정합니다.
• 지출자의 DH 자체 키로 암호화된 이체 금액;
• 승인자의 공개 키 기반 DH 공유 키로 암호화된 이체 금액;
• 지출자의 이체 금액 암호화에 사용되는 무작위 nonce;
• 승인자의 이체 금액 암호화에 사용되는 무작위 nonce입니다.

개인 신호:

• 스펜더의 개인 키;
• 허용 금액
• 이체 금액;
• 지출자의 ElGamal 약속에 사용되는 무작위 nonce.
• 승인자의 ElGamal 약속에 사용되는 무작위 nonce입니다.

이러한 신호를 작동시키려면 회로에 다음과 같은 제약 조건이 있어야 합니다.

1. 제공된 개인 키는 실제로 제공된 지출자의 공개 키의 개인 키입니다.
2. 제공된 허용 금액은 ElGamal 약정을 사용하여 약정된 금액임이 입증됩니다.
3. 제공된 이체 금액은 다음을 사용하여 약정된 금액임이 입증됩니다.
   ElGamal의 약속은 허용 금액보다 크거나 같아야 합니다.
4. 이체 금액은 지출자의 공개 키 기반 DH 공유 키로 올바르게 암호화되었습니다.
5. 이체 금액은 승인자의 공개 키 기반 DH 공유 키로 올바르게 암호화되었습니다.

5.1.4. 공개 기밀 전송 회로에서

공공비밀수당증명을 위한 회로신호 목록은 다음과 같습니다.

공공 신호:

• 승인자의 공개 키
• 스펜더의 공개 키;
• 허용 금액
• ElGamal은 지출자의 공개 키에 따라 이체 금액을 약속합니다.
• ElGamal은 승인자의 공개키를 기준으로 이체 후 남은 허용금액을 확정합니다.
• 지출자의 공개 키 기반 DH 공유 키로 암호화된 이체 금액;
• 승인자의 DH 자체 키로 암호화되어 전송 후 남은 허용 금액입니다.
• 지출자의 이체 금액 암호화에 사용되는 무작위 nonce;
• 승인자의 남은 허용 금액을 암호화하는 데 사용되는 무작위 nonce입니다.

개인 신호:

• 스펜더의 개인 키;
• 이체 금액;
• 지출자의 ElGamal 약속에 사용되는 무작위 nonce.
• 승인자의 ElGamal 약속에 사용되는 무작위 nonce입니다.

이러한 신호를 작동시키려면 회로에 다음과 같은 제약 조건이 있어야 합니다.

1. 제공된 개인 키는 실제로 제공된 지출자의 공개 키의 개인 키입니다.
2. 제공된 이체 금액은 ElGamal 약정을 사용하여 약정된 금액이며 허용 금액보다 크거나 같은 것으로 입증됩니다.
3. 이체 후 남은 허용 금액은 ElGamal 커미션을 사용하여 커미트된 금액임이 증명됩니다.
4. 이체 금액은 지출자의 공개 키 기반 DH 공유 키로 올바르게 암호화되었습니다.
5. 남은 허용 금액은 승인자의 공개 키 기반 DH 공유 키로 올바르게 암호화되었습니다.

5.1.5. 비밀 허용 취소 회로

비밀 허용 증명을 취소하기 위한 회로 신호 목록은 다음과 같습니다.

공공 신호:

• 승인자의 공개 키.

개인 신호:

• 승인자의 개인 키.

이러한 신호를 작동시키려면 회로에 다음과 같은 제약 조건이 있어야 합니다.

1. 제공된 개인 키는 실제로 제공된 공개 키의 개인 키입니다.

5.1.6. 공공비밀수당 취소 회로

공개비밀허용증명 취소를 위한 회로신호 목록은 다음과 같습니다.

공공 신호:

• 승인자의 공개 키
• 허용 금액
• ElGamal은 승인자의 잔액에 대한 약속을 합니다.
• ElGamal은 승인자의 공개 키를 기반으로 환불 금액을 약속합니다.
• 환불 후 승인자의 새로운 잔액은 승인자의 DH 자체 키로 암호화됩니다.
• 승인자의 새로운 잔액 암호화에 사용되는 무작위 nonce입니다.

개인 신호:

• 승인자의 개인 키
• 승인자의 잔액;
• 승인자의 ElGamal 약속에 사용되는 무작위 nonce입니다.

이러한 신호를 작동시키려면 회로에 다음과 같은 제약 조건이 있어야 합니다.

1. 제공된 개인 키는 실제로 제공된 공개 키의 개인 키입니다.
2. 제공된 승인자의 잔액은 ElGamal 약정을 사용하여 약정된 잔액임이 입증됩니다.
3. 제공된 환불 금액은 ElGamal 약정을 사용하여 약정된 금액임이 입증됩니다.
4. 승인자의 새로운 잔액은 승인자의 공개 키 기반 DH 공유 키로 올바르게 암호화되었습니다.

5.2. ZEX 회로

5.2.1. 제안 수락 회로

스왑 오퍼 증명을 수락하기 위한 회로 신호 목록은 다음과 같습니다.

공공 신호:

• 수락자의 공개 키;
• 개시자의 공개 키;
• 판매 가능한 최대 금액
• 환율;
• 엘가말은 자산 매수 약정 금액을 개시자에게 지불합니다.

개인 신호:

• 수락자의 개인 키;
• 개시자로부터 구매할 선택된 금액;
• ElGamal 커밋에 사용된 무작위 nonce입니다.

이러한 신호를 작동시키려면 회로에 다음과 같은 제약 조건이 있어야 합니다.

1. 제공된 개인 키는 실제로 제공된 수락자의 공개 키의 개인 키입니다.
2. 개시자에게서 구매하기 위해 제공된 금액은 ElGamal 약정을 사용하여 개시자에게 지불할 금액을 계산하는 데 사용됩니다.
3. 개시자에게 제공된 구매 금액은 판매할 수 있는 최대 금액보다 적거나 같습니다.

5.2.2. 제안 확정 회로

스왑 오퍼 증명을 마무리하기 위한 회로 신호 목록은 다음과 같습니다.

공공 신호:

• 수락자의 공개 키;
• 개시자의 공개 키;
• 환율;
• ElGamal은 수용자로부터 자산매수 금액을 매수하기로 약정합니다.
• 엘가말은 자산의 매도 약정금액을 수용자에게 매도합니다.

개인 신호:

• 개시자의 개인 키;
• 수취인에게 판매할 금액
• ElGamal이 판매할 금액에 대한 약속에 사용된 무작위 nonce입니다.

이러한 신호를 작동시키려면 회로에 다음과 같은 제약 조건이 있어야 합니다.

1. 제공된 개인 키는 실제로 제공된 개시자의 공개 키의 개인 키입니다.
2. 수락자에게 판매할 금액은 수락자로부터 구매할 복호화된 금액에서 계산된 금액입니다.
3. 수용자에게 판매하기 위해 제공된 금액은 ElGamal 약정을 사용하여 약정된 금액입니다.

6. 보안 고려 사항

ZEX 프로토콜에는 강조해야 할 몇 가지 보안 과제가 있습니다.

1. 초기 제안 허용량은 실제 스왑된 토큰 수량을 추정하는 데 사용될 수 있습니다. 제안자가 공개 승인에 신중하지 않으면 이전 스왑에 대한 정보가 유출될 수 있습니다.
2. 스왑 제안은 소량의 매수 토큰으로 수락함으로써 위태로울 수 있습니다. 한 가지 잠재적인 완화책은 제안 제안자가 수락 가능한 매수 토큰의 범위를 명시하도록 하는 것입니다. 하지만 이는 스왑에 대한 더 많은 정보를 공개하게 될 수 있습니다.

7. 향후 작업

이 논문에서는 ZEX 프로토콜의 주요 기능 개념과 기밀 허용 범위를 개략적으로 설명했지만, 추가 연구가 필요한 몇 가지 방향이 남아 있습니다.

첫째, 스왑 오퍼 기간 동안 판매 가능한 최대 금액 관리와 관련하여 해결되지 않은 설계 문제가 있습니다. 현재 사양에서는 판매 금액의 가용성을 보장하는 공개 기밀 할당량은 한 번만 사용할 수 있습니다. 미해결 문제는 공개 할당량을 동적으로 업데이트하여 남은 할당량 자금의 기밀성을 손상시키지 않으면서 다중 채우기 오퍼를 구현할 수 있는 더욱 강력한 접근 방식을 설계하는 것입니다.

둘째, 현재 솔루션은 제안 수락 및 확정을 위해 여러 개의 ZK 증명을 사용하는데, 이는 상당한 가스 오버헤드를 유발합니다. 제안 조작을 수행할 때 단일 트랜잭션에서 여러 증명을 검증해야 합니다. 예를 들어, 제안 확정 과정에서 제공된 매수 금액에 따른 정확한 매도 금액 계산 증명과 publicConfidentialTransferFrom 및 confidentialTransferFrom 함수 호출에 대한 두 개의 증명을 제공해야 합니다. 이러한 접근 방식은 ZEX와 별도로 토큰 승인 모델을 사용한다는 측면에서 일관성을 유지하는 것처럼 보일 수 있지만, 스왑의 전체 비용을 크게 증가시킵니다. 한 가지 잠재적인 해결책은 증명 집계를 신뢰할 수 있는 코디네이터 계약에 위임하는 것입니다. 그러나 이는 새로운 신뢰 가정을 도입하고 잠재적 공격 범위를 확장합니다.

셋째, ZEX 프로토콜을 확장하여 초기 제안 가격을 숨길 수 있으며, 궁극적으로 스왑의 개인 정보 보호는 증가하지만 개시자와 수락자가 협상을 하도록 강요합니다.

참고문헌

이더리움 프라이버시: 자기 주권으로 가는 길
기밀로 포장된 이더리움