Mở khóa DeFi bảo vệ quyền riêng tư. Không cần sửa đổi ở cấp độ giao thức, không cần bộ đồng xử lý để ZEX hoạt động. Mặc dù khá nặng về mặt UX (và gas), đây là bản thảo PoC đầu tiên. Mọi phản hồi đều vô cùng quý giá!

Giao thức ZEX được xây dựng dựa trên mô hình token bảo mật cWETH . Vui lòng kiểm tra kỹ trước khi tiếp tục.

1. Giới thiệu

Tính minh bạch của Ethereum, mặc dù là một trong những lợi thế giá trị nhất của nó, đã trở thành rào cản đối với việc áp dụng tài chính trong thế giới thực. Các blockchain công khai mặc định sẽ tiết lộ số dư, phê duyệt, đối tác và thậm chí cả việc mua lại token.

Đề xuất này giới thiệu ZEX, một cơ chế cho Sàn giao dịch phi tập trung (DEX) ngang hàng (DEX) không cần cấp phép và bảo mật, sử dụng cWETH làm mô hình cho các token bảo mật. Nó mở rộng chức năng token với các khoản cho phép bảo mật, cho phép các tương tác ngang hàng ẩn. Tương tự như giao thức cWETH, logic ZEX sử dụng lược đồ cam kết dựa trên Twisted ElGamal của Đường cong Elliptic (EC) để đảm bảo tính bảo mật, EC Diffie-Hellman (DH) để giới thiệu khả năng truy cập giá trị, và zk-SNARK để xác minh tính chính xác của việc cập nhật số dư trong quá trình phê duyệt và chuyển token mà không tiết lộ số tiền thực tế được trao đổi.

Giao thức ZEX hoạt động như một thị trường cho các giao dịch hoán đổi, nơi các giao dịch diễn ra theo mô hình tương tác ba bước và yêu cầu xác minh nhiều bằng chứng ZK trong cùng một giao dịch. Thông tin duy nhất được ZEX tiết lộ là giá và hạn mức chào bán ban đầu, cho biết số lượng token tối đa có sẵn cho từng sàn giao dịch cụ thể.

Việc sửa đổi giao thức cũng có thể che giấu giá hoán đổi để tăng giả định về quyền riêng tư.

2. Mô hình cấp phép mã thông báo bí mật

Để thực hiện hoán đổi ngang hàng bí mật, các luồng phê duyệt và chuyển từ phải được xác định qua mã thông báo bí mật.

Các luồng này sẽ được quản lý bởi tổng cộng sáu chức năng mới:

1. confidentialPhê duyệt để phê duyệt mã thông báo cho EOA với khóa mã hóa hiện có mà không tiết lộ số tiền đã phê duyệt.
2. confidentialTransferFrom để chuyển các mã thông báo đã được chấp thuận một cách bí mật mà không tiết lộ số tiền đã chuyển.
3. publicConfidentialApprove để phê duyệt một lần mã thông báo cho hợp đồng thông minh, tiết lộ số tiền đã được phê duyệt.
4. publicConfidentialTransferFrom để chuyển các mã thông báo được công khai chấp thuận mà không tiết lộ số tiền được chuyển.
5. cancelConfidentialApprove để hủy bỏ phê duyệt bí mật mà không tiết lộ số tiền đã hủy.
6. cancelPublicConfidentialApprove để hủy bỏ phê duyệt công khai, tiết lộ số tiền đã hủy.

Để biết thông số kỹ thuật chi tiết về mật mã được sử dụng bởi các chức năng này, vui lòng tham khảo bài báo cWETH gốc.

2.1. Phê duyệt và chuyển giao bí mật

Trái ngược với logic phê duyệt ERC-20 thông thường, phê duyệt bí mật sẽ làm giảm số dư của người phê duyệt. Điều này là do trong quá trình chuyển tiền bí mật, người chi tiêu không thể xác minh xem người phê duyệt có đủ số dư hay không, vì số dư đã được mã hóa.

Ngoài ra, thao tác phê duyệt bí mật yêu cầu phải cung cấp địa chỉ của người vận hành, bổ sung cho địa chỉ và số tiền được phép thông thường của người chi tiêu ERC-20. Nếu địa chỉ của người vận hành được chỉ định, người chi tiêu không thể gọi confidentialTransferFrom để nhận token; chỉ người vận hành mới đủ điều kiện. Ràng buộc này rất quan trọng đối với tính bảo mật và tùy chỉnh của transferFrom bí mật, vì nó cho phép người phê duyệt chỉ định một hợp đồng thông minh làm người vận hành để thực thi xác thực chuyển khoản bổ sung.

Quy trình phê duyệt bí mật cho EOA được mô tả trong sơ đồ sau:

Hình 1: Luồng phê duyệt bí mật 1142×758 160 KB

Sau khi khoản trợ cấp được cấp, người chi tiêu có thể nhận được token đã được phê duyệt. Sơ đồ bên dưới minh họa quy trình chuyển tiền bí mật:

Hình 2: Chuyển giao bí mậtTừ luồng 1920×1405 176 KB

Điều quan trọng là phải hiểu rằng việc phê duyệt và chuyển giao bí mật hoạt động trên năm số tiền được mã hóa khác nhau:

1. Khóa ECDH của người phê duyệt để thể hiện số dư mới của họ sau khi khoản trợ cấp được cấp.
2. Cam kết về hạn mức ElGamal của người phê duyệt để họ có thể truy cập vào số tiền hạn mức trong trường hợp hủy bỏ phê duyệt. Cam kết này cũng được trừ vào cam kết số dư của người phê duyệt để thể hiện số dư mới sau khi hạn mức được cấp.
3. Số tiền trợ cấp được mã hóa bằng khóa chia sẻ ECDH của người phê duyệt/người chi tiêu để biết số tiền trợ cấp có sẵn hay không.
4. Cam kết trợ cấp ElGamal của người chi tiêu được thêm vào số dư đang chờ xử lý của họ khi chi tiêu trợ cấp.
5. Số lượng mã thông báo nhận được được mã hóa bằng khóa ECDH tự động để cung cấp số dư chi tiêu mới sau khi khoản trợ cấp được chi tiêu.

2.2. Công khai bí mật phê duyệt & chuyển giaoTừ

Trong một số trường hợp, cần phải phê duyệt token không phải cho EOA bằng khóa mã hóa mà trực tiếp cho hợp đồng thông minh. Vì hợp đồng thông minh không giữ khóa riêng tư bí mật, chúng không thể giải mã các giá trị cho phép bí mật. Hơn nữa, trong trường hợp này, người phê duyệt không biết trước người nhận và không thể mã hóa giá trị cho khóa công khai cụ thể. Do đó, bất kỳ khoản cho phép bí mật nào dành cho hợp đồng thông minh đều phải công khai số tiền được phê duyệt.

Sơ đồ dưới đây mô tả luồng phê duyệt bí mật công khai:

Hình 3: Luồng phê duyệt bí mật công khai 3099×1750 379 KB

Vì số tiền được phê duyệt được chỉ định dưới dạng văn bản thuần túy, hạn mức công khai bí mật phải được chi tiêu toàn bộ và theo dạng nguyên tử, khiến nó trở thành một phê duyệt một lần. Nói cách khác, nếu hạn mức công khai không được chi tiêu hết, các giả định về quyền riêng tư yêu cầu giá trị còn lại phải được mã hóa lại bằng khóa công khai của người phê duyệt và được cộng lại vào số dư đang chờ xử lý của người phê duyệt trong cùng giao dịch. Điều này là do việc cập nhật công khai giá trị hạn mức sẽ làm giảm tính bảo mật của số tiền được chuyển.

Dòng chi tiêu của khoản trợ cấp bí mật công được mô tả trong sơ đồ sau:

Hình 4: Chuyển giao bí mật công khaiTừ luồng 1920×681 118 KB

Sự khác biệt đáng kể so với lệnh chuyển tiền bí mật thông thường là số tiền còn lại sẽ được mã hóa và thêm lại vào số dư đang chờ xử lý của người phê duyệt, thay vì nằm trong bộ lưu trữ tiền chuyên dụng.

2.3. Hủy trợ cấp

Giao thức này cũng bao gồm một cơ chế cho phép người phê duyệt hủy bỏ quyền bảo mật, cho dù quyền đó được cấp dưới dạng quyền được mã hóa cho EOA hay quyền công khai cho hợp đồng.

Quy trình hủy trợ cấp bí mật được thể hiện trong sơ đồ dưới đây:

Hình 5: Luồng hủy trợ cấp 1920×563 100 KB

Quy trình hủy bỏ khoản trợ cấp bí mật khá đơn giản vì tất cả các khoản tiền được mã hóa đều được lưu giữ trong các thao tác phê duyệt và chuyển khoản bí mật. Việc cần làm chỉ là cộng chúng trở lại số dư đang chờ xử lý của người phê duyệt.

Tuy nhiên, việc hủy bỏ công khai cũng yêu cầu phải có bằng chứng ZK để xác minh việc mã hóa phần trợ cấp còn lại.

3. Tổng quan về giao thức ZEX

3.1. Điều kiện tiên quyết

Để DEX hoạt động chính xác, một số điều kiện phải được đáp ứng để quá trình hoán đổi diễn ra suôn sẻ và nhất quán:

• Tất cả các bên tham gia phải công bố khóa công khai bí mật của mình. Các khóa này được sử dụng cho cả cam kết EC ElGamal và mã hóa ECDH, theo sơ đồ được sử dụng trong các mã thông báo bí mật cơ bản.
• Người khởi xướng chào hàng phải nắm giữ đủ số token bí mật trong tài sản bán để trang trải số tiền tối đa mà họ dự định cung cấp trong chào hàng.
• Người chấp nhận đề nghị phải nắm giữ đủ số mã thông báo bí mật trong tài sản mua để thanh toán số tiền đã thỏa thuận theo tỷ lệ quy định.
• Bên chấp nhận đề nghị phải có quyền truy cập vào thông tin chi tiết về đề nghị trước khi chuẩn bị phần của mình trong giao dịch hoán đổi. Cụ thể, bên khởi xướng đề nghị phải công bố tỷ giá hối đoái và số lượng tài sản tối đa có thể bán.

3.2. Luồng trao đổi ngang hàng

Phần sau đây mô tả quy trình thực hiện hoán đổi ngang hàng bí mật được hỗ trợ bởi mô hình cho phép bí mật đã được định nghĩa trước đó. Quy trình trao đổi mang tính tương tác và bao gồm ba giai đoạn: đặt lệnh chào mua , chấp nhận lệnh chào mua và hoàn tất hoán đổi .

Luồng hoán đổi đầy đủ được mô tả trong sơ đồ bên dưới:

Hình 6: Luồng hoán đổi bí mật 4724×3600 435 KB

3.2.1. Vị trí chào hàng

Người khởi xướng hoán đổi xác định và công bố cấu hình chào hàng một cách công khai: tỷ giá hối đoái r r (assetBuy trên assetSell) và số lượng tối đa M M của assetSell có sẵn để trao đổi.

Tính khả dụng của mã thông báo bán để hoán đổi được đảm bảo thông qua việc phê duyệt mã thông báo M M cho hợp đồng ZEX được chỉ định bằng cách gọi hàm publicConfidentialApprove.

3.2.2. Chấp nhận đề nghị

Trước khi chấp nhận lời đề nghị, bên đối tác phải xác minh xem có sự cho phép công khai đối với lời đề nghị cụ thể đó hay không và lời đề nghị đó vẫn chưa được chấp nhận.

Sau đó, người chấp nhận chọn số lượng b b ( b \le M) ( b ≤ M ) của tài sản Bán để nhận trong quá trình hoán đổi và tính toán số lượng tài sản Mua a tương ứng để trả cho người khởi xướng chào hàng theo tỷ giá đã thỏa thuận r r , lấy a = br a = br .

Sau đó, bên chấp nhận phải phê duyệt token AssetBuy thông qua confidentialApprove, chỉ định hợp đồng ZEX là bên vận hành và bên khởi tạo chào hàng là bên chi tiêu. Ngoài ra, bên chấp nhận phải cung cấp bằng chứng ZK chứng minh rằng số tiền đã chọn không vượt quá số tiền tối đa khả dụng do bên khởi tạo công bố.

3.2.3. Hoàn tất hoán đổi

Để hoàn tất việc hoán đổi, người khởi xướng đề nghị trước tiên phải xác minh rằng quyền bảo mật của bên đối tác là đủ cho đề nghị cụ thể đó.

Sau đó , người khởi tạo đề nghị cần tính toán chính xác số lượng tài sản cần bán cho người chấp nhận đề nghị. Việc này được thực hiện bằng cách giải mã a được cung cấp trong quá trình xác thực bí mật và tính toán số lượng bán b = b = a \over r a r .

Người khởi tạo sau đó chuẩn bị chuyển giao b b token của assetSell bằng cách mã hóa chúng bằng khóa công khai của người chấp nhận và tính toán hạn mức assetSell còn lại l=Mb l = M − b .

Để chuyển số tiền AssetSell đã thỏa thuận, hợp đồng ZEX gọi publicConfidentialTransferFrom, lệnh này sẽ thêm b token vào số dư của bên chấp nhận, trong khi số tiền còn lại được tự mã hóa l l được cộng trở lại số dư đang chờ xử lý của bên khởi tạo. Cuối cùng, trong cùng giao dịch, bên khởi tạo nhận được khoản thanh toán a a trong assetBuy thông qua confidentialTransferFrom được kích hoạt bởi hợp đồng ZEX bằng cách chi tiêu khoản tiền được cấp cho bên chấp nhận trong quá trình chấp nhận chào hàng.

Tóm lại, người dùng có thể hoàn tất việc hoán đổi và trao đổi token theo tỷ giá quy định hoặc hủy bỏ phê duyệt bất cứ lúc nào để dừng quá trình hoán đổi. DEX không bao giờ công bố số tiền thực tế đã trao đổi, mà chỉ hoạt động công khai với tỷ giá hối đoái và số tiền chào bán ban đầu.

4. Hợp đồng thông minh Solidity

4.1. Biến trạng thái mã thông báo bí mật

4.1.1. Cho phép bảo mật

Dữ liệu cho phép bí mật được lưu trữ trong cấu trúc sau:

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

Lưu ý rằng dữ liệu mã hóa và cam kết sẽ được giải mã thêm theo thông số kỹ thuật mã thông báo bí mật.

Các khoản trợ cấp được lưu trữ trong một ánh xạ:

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

4.1.2. Cho phép bí mật công khai

Khoản trợ cấp bí mật được cấp cho hợp đồng được lưu trữ trong một bản đồ, trong đó số tiền được chấp thuận được cung cấp dưới dạng văn bản thuần túy:

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

4.2. Biến trạng thái ZEX

4.2.1. Dữ liệu cung cấp

Đề nghị hoán đổi được định nghĩa theo cấu trúc bên dưới:

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

Các ưu đãi được lưu trữ trong một ánh xạ đơn giản:

 mapping(uint256 offerId => Offer); 

4.3. Chức năng mã thông báo bí mật

4.3.1. Cấp phép bảo mật

Để cấp quyền bảo mật cho EOA đã đăng ký, phải sử dụng hàm confidentialApprove:

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

Các tham số dữ liệu mã hóa và cam kết lưu trữ các giá trị được mã hóa bằng khóa công khai của cả người phê duyệt và người chi tiêu, tương tự như hàm truyền từ giao thức cWETH.

4.3.2. Cấp phép bí mật công cộng

Để cấp quyền cho hợp đồng, hàm publicConfidentialApprove được cung cấp:

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

Các tham số dữ liệu mã hóa và cam kết trong chức năng này dùng để lưu trữ số dư và giá trị số tiền mới được mã hóa bằng khóa công khai của người phê duyệt để cập nhật số dư sau khi phê duyệt.

4.3.3. Chi tiêu khoản dự phòng bí mật

Để sử dụng quyền phê duyệt bảo mật, người vận hành phải gọi hàm sau:

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

Các tham số dữ liệu mã hóa và cam kết lưu trữ số tiền chuyển được mã hóa bằng khóa công khai của người chi tiêu và số tiền cho phép còn lại sau khi chuyển, được mã hóa bằng khóa công khai của người phê duyệt.

4.3.4. Chi tiêu khoản dự phòng công khai

Để chi tiêu khoản trợ cấp bí mật công khai, hợp đồng chi tiêu sẽ sử dụng chức năng dưới đây:

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

Các tham số dữ liệu mã hóa và cam kết bao gồm số tiền chuyển được mã hóa bằng khóa công khai của người nhận và số tiền cho phép còn lại được tự mã hóa bằng khóa công khai của người phê duyệt.

4.3.5. Hủy bỏ trợ cấp bí mật

Để hủy bỏ quyền bảo mật được cấp cho EOA, người phê duyệt phải sử dụng chức năng bên dưới:

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

Trong trường hợp người phê duyệt không phải là msg.sender, proofData sẽ chứa bằng chứng ZK để xác minh quyền sở hữu khóa riêng của người phê duyệt.

4.3.6. Hủy bỏ chế độ mật công khai

Việc hủy bỏ trợ cấp công cộng được cấp cho hợp đồng phải được thực hiện thông qua chức năng sau:

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

balanceEncryptionData được sử dụng để lưu trữ số dư được mã hóa DH mới của người phê duyệt sau khi hoàn tiền, trong khi amountCommitmentData thể hiện cam kết ElGamal về số tiền hoàn lại thực tế.

4.4. Chức năng ZEX

4.4.1. Khởi tạo một đề nghị hoán đổi

Để tạo một đề nghị hoán đổi, người khởi tạo cần gọi hàm sau:

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

approveData bao gồm các tham số và bằng chứng ZK cần thiết cho publicConfidentialApprove được gọi trong hàm initiateOffer.

4.4.2. Chấp nhận lời đề nghị

Để chấp nhận lời đề nghị hiện có, hàm acceptOffer được cung cấp:

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

approveData lưu trữ dữ liệu cần thiết cho lệnh confidentialApprove được gọi trong hàm acceptOffer. Nó cũng bao gồm số lượng assetSell được mã hóa để mua từ người khởi tạo. proofData đại diện cho bằng chứng ZK chứng minh rằng số lượng này nằm trong phạm vi số lượng tối đa khả dụng đã xác định của lời đề nghị.

4.4.3. Hoàn tất việc hoán đổi

Để hoàn tất giao dịch hoán đổi ngang hàng bí mật, người khởi tạo lời đề nghị cần gọi hàm bên dưới:

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

transferFromData bao gồm các giá trị cần thiết cho các hàm \newline publicConfidentialTransferFrom và confidentialTransferFrom được gọi trong quá trình hoàn tất hoán đổi. Tham số proofData là một bằng chứng ZK được sử dụng để xác minh việc giải mã chính xác số tiền mua của bên chấp nhận và tính toán số tiền bán của bên khởi tạo.

5. Mạch ZK

Tất cả các thông số được nêu trong đề xuất này đều được thiết kế để có thể xác minh trên chuỗi và tương thích với mạch không kiến thức.

5.1. Mạch mã thông báo bí mật

5.1.1. Mạch phê duyệt bí mật

Danh sách các tín hiệu mạch để phê duyệt bản gốc bí mật như sau:

Tín hiệu công cộng:

• Khóa công khai của người phê duyệt;
• Khóa công khai của Spender;
• Cam kết ElGamal về số dư của người phê duyệt;
• Cam kết ElGamal về số tiền trợ cấp dựa trên khóa công khai của người phê duyệt;
• Cam kết ElGamal về số tiền trợ cấp dựa trên khóa công khai của người chi tiêu;
• Số dư của người phê duyệt mới được mã hóa bằng khóa tự động DH của người phê duyệt;
• Nonce ngẫu nhiên được sử dụng trong mã hóa số dư mới của người phê duyệt;
• Số tiền trợ cấp được mã hóa bằng khóa chung DH dựa trên khóa công khai của người chi tiêu;
• Nonce ngẫu nhiên được sử dụng trong quá trình mã hóa số tiền được phép chi tiêu.

Tín hiệu riêng tư:

• Khóa riêng của người phê duyệt;
• Số dư của người phê duyệt;
• Số tiền trợ cấp;
• Nonce ngẫu nhiên được sử dụng trong cam kết ElGamal của người phê duyệt;
• Nonce ngẫu nhiên được sử dụng trong cam kết ElGamal của người chi tiêu.

Để vận hành các tín hiệu này, mạch phải có những hạn chế sau:

1. Khóa riêng được cung cấp thực chất là khóa riêng của khóa công khai của người phê duyệt được cung cấp.
2. Số dư của người phê duyệt được cung cấp phải được chứng minh là số dư đã cam kết sử dụng cam kết ElGamal và lớn hơn hoặc bằng số tiền cho phép.
3. Cam kết ElGamal của người phê duyệt về số tiền trợ cấp đã được tạo chính xác.
4. Cam kết ElGamal của người chi tiêu về số tiền trợ cấp đã được tạo ra một cách chính xác.
5. Số dư mới của người phê duyệt đã được mã hóa chính xác bằng khóa chia sẻ DH dựa trên khóa công khai của người phê duyệt.
6. Số tiền trợ cấp đã được mã hóa chính xác bằng khóa chia sẻ DH dựa trên khóa công khai của người chi tiêu.

5.1.2. Mạch phê duyệt bí mật công khai

Danh sách các tín hiệu mạch để công khai bí mật phê duyệt bằng chứng như sau:

Tín hiệu công cộng:

• Khóa công khai của người phê duyệt;
• Số tiền trợ cấp;
• Cam kết ElGamal về số dư của người phê duyệt;
• Cam kết ElGamal về số tiền trợ cấp dựa trên khóa công khai của người phê duyệt;
• Số dư của người phê duyệt mới được mã hóa bằng khóa tự động DH của người phê duyệt;
• Nonce ngẫu nhiên được sử dụng trong mã hóa số dư mới của người phê duyệt.

Tín hiệu riêng tư:

• Khóa riêng của người phê duyệt;
• Số dư của người phê duyệt;
• Số tiền chuyển khoản;
• Nonce ngẫu nhiên được sử dụng trong cam kết ElGamal của người phê duyệt.

Để vận hành các tín hiệu này, mạch phải có những hạn chế sau:

1. Khóa riêng được cung cấp thực chất là khóa riêng của khóa công khai của người phê duyệt được cung cấp.
2. Số dư của người phê duyệt được cung cấp phải được chứng minh là số dư đã cam kết sử dụng cam kết ElGamal và lớn hơn hoặc bằng số tiền cho phép.
3. Cam kết ElGamal của người phê duyệt về số tiền trợ cấp đã được tạo chính xác.
4. Số dư mới của người phê duyệt đã được mã hóa chính xác bằng khóa chia sẻ DH dựa trên khóa công khai của người phê duyệt.

5.1.3. Chuyển giao bí mậtTừ mạch

Danh sách các tín hiệu mạch để chi tiêu bằng chứng trợ cấp bí mật như sau:

Tín hiệu công cộng:

• Khóa công khai của người phê duyệt;
• Khóa công khai của Spender;
• Cam kết ElGamal của Spender về khoản trợ cấp;
• Cam kết ElGamal về số tiền cần chuyển dựa trên khóa công khai của người chi tiêu;
• Cam kết ElGamal về số tiền chuyển khoản dựa trên khóa công khai của người phê duyệt;
• Số tiền chuyển được mã hóa bằng khóa tự động DH của người chi tiêu;
• Số tiền chuyển được mã hóa bằng khóa chung DH dựa trên khóa công khai của người phê duyệt;
• Nonce ngẫu nhiên được sử dụng trong mã hóa số tiền chuyển khoản của người chi tiêu;
• Nonce ngẫu nhiên được sử dụng trong mã hóa số tiền chuyển khoản của người phê duyệt.

Tín hiệu riêng tư:

• Khóa riêng của người chi tiêu;
• Số tiền trợ cấp;
• Số tiền chuyển khoản;
• Nonce ngẫu nhiên được sử dụng trong cam kết ElGamal của người chi tiêu;
• Nonce ngẫu nhiên được sử dụng trong cam kết ElGamal của người phê duyệt.

Để vận hành các tín hiệu này, mạch phải có những hạn chế sau:

1. Khóa riêng được cung cấp thực chất là khóa riêng của khóa công khai của người chi tiêu được cung cấp.
2. Số tiền trợ cấp được cung cấp phải được chứng minh là số tiền đã cam kết sử dụng cam kết ElGamal.
3. Số tiền chuyển khoản được cung cấp được chứng minh là số tiền đã cam kết sử dụng
   Cam kết của ElGamal phải lớn hơn hoặc bằng số tiền cho phép.
4. Số tiền chuyển khoản đã được mã hóa chính xác bằng khóa chung DH dựa trên khóa công khai của người chi tiêu.
5. Số tiền chuyển khoản đã được mã hóa chính xác bằng khóa chung DH dựa trên khóa công khai của người phê duyệt.

5.1.4. Chuyển giao bí mật công khaiTừ mạch

Danh sách tín hiệu mạch để chi tiêu bằng chứng cho phép bí mật công khai như sau:

Tín hiệu công cộng:

• Khóa công khai của người phê duyệt;
• Khóa công khai của Spender;
• Số tiền trợ cấp;
• Cam kết ElGamal về số tiền cần chuyển dựa trên khóa công khai của người chi tiêu;
• Cam kết ElGamal về số tiền trợ cấp còn lại sau khi chuyển dựa trên khóa công khai của người phê duyệt;
• Số tiền chuyển được mã hóa bằng khóa chung DH dựa trên khóa công khai của người chi tiêu;
• Số tiền trợ cấp còn lại sau khi chuyển được mã hóa bằng khóa tự động DH của người phê duyệt;
• Nonce ngẫu nhiên được sử dụng trong mã hóa số tiền chuyển khoản của người chi tiêu;
• Nonce ngẫu nhiên được sử dụng trong mã hóa số tiền trợ cấp còn lại của người phê duyệt.

Tín hiệu riêng tư:

• Khóa riêng của người chi tiêu;
• Số tiền chuyển khoản;
• Nonce ngẫu nhiên được sử dụng trong cam kết ElGamal của người chi tiêu;
• Nonce ngẫu nhiên được sử dụng trong cam kết ElGamal của người phê duyệt.

Để vận hành các tín hiệu này, mạch phải có những hạn chế sau:

1. Khóa riêng được cung cấp thực chất là khóa riêng của khóa công khai của người chi tiêu được cung cấp.
2. Số tiền chuyển nhượng được cung cấp phải được chứng minh là số tiền đã cam kết sử dụng cam kết ElGamal và lớn hơn hoặc bằng số tiền cho phép.
3. Số tiền trợ cấp còn lại sau khi chuyển nhượng được chứng minh là số tiền đã cam kết sử dụng cam kết ElGamal.
4. Số tiền chuyển khoản đã được mã hóa chính xác bằng khóa chung DH dựa trên khóa công khai của người chi tiêu.
5. Số tiền trợ cấp còn lại đã được mã hóa chính xác bằng khóa chia sẻ DH dựa trên khóa công khai của người phê duyệt.

5.1.5. Mạch hủy bỏ trợ cấp bí mật

Danh sách các tín hiệu mạch để hủy bỏ bằng chứng cho phép bí mật như sau:

Tín hiệu công cộng:

• Khóa công khai của người phê duyệt.

Tín hiệu riêng tư:

• Khóa riêng của người phê duyệt.

Để vận hành các tín hiệu này, mạch phải có những hạn chế sau:

1. Khóa riêng được cung cấp thực chất là khóa riêng của khóa công khai được cung cấp.

5.1.6. Mạch hủy bỏ trợ cấp bí mật công khai

Danh sách các tín hiệu mạch để hủy bỏ bằng chứng cho phép bí mật công khai như sau:

Tín hiệu công cộng:

• Khóa công khai của người phê duyệt;
• Số tiền trợ cấp;
• Cam kết ElGamal về số dư của người phê duyệt;
• Cam kết của ElGamal về số tiền hoàn lại dựa trên khóa công khai của người phê duyệt;
• Số dư mới của người phê duyệt sau khi hoàn tiền, được mã hóa bằng khóa tự động DH của người phê duyệt;
• Nonce ngẫu nhiên được sử dụng trong mã hóa số dư mới của người phê duyệt.

Tín hiệu riêng tư:

• Khóa riêng của người phê duyệt;
• Số dư của người phê duyệt;
• Nonce ngẫu nhiên được sử dụng trong cam kết ElGamal của người phê duyệt.

Để vận hành các tín hiệu này, mạch phải có những hạn chế sau:

1. Khóa riêng được cung cấp thực chất là khóa riêng của khóa công khai được cung cấp.
2. Số dư của người phê duyệt được cung cấp được chứng minh là số dư đã cam kết bằng cách sử dụng cam kết ElGamal.
3. Số tiền hoàn trả trợ cấp được cung cấp phải được chứng minh là số tiền đã cam kết sử dụng cam kết ElGamal.
4. Số dư mới của người phê duyệt đã được mã hóa chính xác bằng khóa chia sẻ DH dựa trên khóa công khai của người phê duyệt.

5.2. Mạch ZEX

5.2.1. Mạch chấp nhận chào hàng

Danh sách các tín hiệu mạch để chấp nhận bằng chứng đề nghị hoán đổi như sau:

Tín hiệu công cộng:

• Khóa công khai của người chấp nhận;
• Khóa công khai của người khởi tạo;
• Số lượng bán tối đa;
• Tỷ giá hối đoái;
• Cam kết ElGamal về tài sảnMua số tiền phải trả cho người khởi tạo.

Tín hiệu riêng tư:

• Khóa riêng của người chấp nhận;
• Số tiền được chọn để mua từ người khởi xướng;
• Nonce ngẫu nhiên được sử dụng trong cam kết ElGamal.

Để vận hành các tín hiệu này, mạch phải có những hạn chế sau:

1. Khóa riêng được cung cấp thực chất là khóa riêng của khóa công khai của người chấp nhận được cung cấp.
2. Số tiền được cung cấp để mua từ người khởi xướng là số tiền được sử dụng để tính toán số tiền phải trả cho người khởi xướng đã cam kết bằng cam kết ElGamal.
3. Số tiền được cung cấp để mua từ người khởi xướng phải nhỏ hơn hoặc bằng số tiền tối đa được bán.

5.2.2. Mạch hoàn thiện chào hàng

Danh sách các tín hiệu mạch để hoàn thiện bằng chứng đề nghị hoán đổi như sau:

Tín hiệu công cộng:

• Khóa công khai của người chấp nhận;
• Khóa công khai của người khởi tạo;
• Tỷ giá hối đoái;
• Cam kết ElGamal của tài sảnMua số tiền để mua từ người chấp nhận;
• Cam kết ElGamal về số lượng tài sản được bán cho người chấp nhận.

Tín hiệu riêng tư:

• Khóa riêng của người khởi tạo;
• Số tiền bán cho người chấp nhận;
• Nonce ngẫu nhiên được sử dụng trong cam kết ElGamal về số tiền bán.

Để vận hành các tín hiệu này, mạch phải có những hạn chế sau:

1. Khóa riêng được cung cấp thực chất là khóa riêng của khóa công khai của người khởi tạo được cung cấp.
2. Số tiền được cung cấp để bán cho người chấp nhận là số tiền được tính toán từ số tiền được giải mã để mua từ người chấp nhận.
3. Số tiền được cung cấp để bán cho người chấp nhận là số tiền được cam kết sử dụng cam kết ElGamal.

6. Những cân nhắc về bảo mật

Có một số thách thức bảo mật hiện có của giao thức ZEX cần được nhấn mạnh.

1. Khoản trợ cấp ban đầu có thể được sử dụng để suy ra số lượng token thực tế được hoán đổi. Nếu người khởi xướng chào hàng không cẩn thận trong việc phê duyệt công khai, họ có thể làm rò rỉ thông tin về các lần hoán đổi trước đó.
2. Đề nghị hoán đổi có thể bị phá vỡ bằng cách chấp nhận nó với một lượng nhỏ token mua. Một biện pháp giảm thiểu tiềm năng là để người khởi xướng đề nghị chỉ định phạm vi token mua mà họ có thể chấp nhận, nhưng điều này có thể dẫn đến việc tiết lộ thêm thông tin về giao dịch hoán đổi.

7. Công việc tương lai

Mặc dù bài báo này trình bày các khái niệm chức năng chính của giao thức ZEX và các khoản trợ cấp bảo mật, vẫn còn một số hướng mở cần được nghiên cứu thêm.

Thứ nhất, có một câu hỏi thiết kế chưa được giải quyết liên quan đến việc quản lý số tiền tối đa có thể bán trong quá trình chào bán hoán đổi. Trong quy định hiện hành, hạn mức bảo mật công khai, đảm bảo tính khả dụng của số tiền bán, chỉ có thể được chi tiêu một lần. Câu hỏi mở là thiết kế một phương pháp mạnh mẽ hơn để cập nhật động hạn mức bảo mật công khai, cung cấp khả năng thực hiện nhiều đề nghị mua lại mà không ảnh hưởng đến tính bảo mật của số tiền bảo lãnh còn lại.

Thứ hai, giải pháp hiện tại sử dụng nhiều bằng chứng ZK để chấp nhận và hoàn tất đề nghị, điều này gây ra chi phí gas đáng kể. Nhiều bằng chứng phải được xác minh trong một giao dịch duy nhất khi thực hiện thao túng đề nghị. Ví dụ: trong quá trình hoàn tất đề nghị, người ta phải cung cấp bằng chứng về phép tính số lượng bán chính xác theo số lượng mua được cung cấp và hai bằng chứng cho các lệnh gọi hàm publicConfidentialTransferFrom và confidentialTransferFrom. Mặc dù cách tiếp cận như vậy có vẻ nhất quán về mặt sử dụng mô hình phê duyệt mã thông báo riêng biệt với ZEX, nhưng nó làm tăng đáng kể tổng chi phí của giao dịch hoán đổi. Một giải pháp tiềm năng là ủy thác việc tổng hợp bằng chứng cho một hợp đồng điều phối đáng tin cậy. Tuy nhiên, điều này lại đặt ra các giả định mới về độ tin cậy và mở rộng bề mặt tấn công tiềm ẩn.

Thứ ba, có thể mở rộng giao thức ZEX để che giấu giá chào hàng ban đầu, cuối cùng là tăng tính riêng tư của giao dịch hoán đổi, nhưng buộc người khởi xướng và người chấp nhận phải mặc cả.

Tài liệu tham khảo

Quyền riêng tư của Ethereum: Con đường đến với chủ quyền tự chủ
Ethereum được bọc bí mật