Quyền riêng tư rất quan trọng đối với khả năng tồn tại và hoạt động lâu dài của Ethereum.
Theo lộ trình tuyệt vờiEthereum Privacy: The Road to Self-Sovereignty , chúng tôi đã đưa ra khái niệm về WETH bí mật, có thể phát triển thành Tiêu chuẩn token bí mật (Đề xuất cải tiến Ethereum (EIP)) hoàn chỉnh trong tương lai.
Rất muốn nghe suy nghĩ của bạn về bản dự thảo!
1. Giới thiệu
Tính minh bạch là một trong những lợi ích chính của blockchain công khai. Tuy nhiên, khả năng hiển thị công khai các giao dịch có khả năng xâm phạm quyền riêng tư của người dùng. Thách thức cơ bản là cân bằng các lợi ích nội tại của tính công khai của blockchain với nhu cầu thiết yếu về tính bảo mật của cá nhân.
Mục tiêu là tạo ra một giao thức công cộng Không cần cho phép, có thể che giấu hoạt động tài chính của người dùng trong các token ETH bằng cách mã hóa số dư và số tiền chuyển của họ. Điều này sẽ cho phép thanh toán ngang hàng, quyên góp và mua lại ETH một cách bảo mật mà không cần dựa vào các thực thể tập trung.
Đề xuất này gợi ý tạo ra một phiên bản bảo mật của Ethereum được gói (cWETH) hoàn toàn trong lớp ứng dụng. Giải pháp kết hợp lược đồ cam kết dựa trên Elliptic Curve (EC) Twisted ElGamal để bảo toàn tính bảo mật và giao thức EC Diffie-Hellman (DH) để giới thiệu khả năng truy cập bị giới hạn bởi lược đồ cam kết. Để thực thi việc tạo ra các cam kết, mã hóa và giải mã chính xác, zk-SNARK được sử dụng.
1.1. Sự khác biệt so với các giao thức hiện có
Có ít nhất hai giải pháp đã biết không yêu cầu sửa đổi lớp giao thức và có thể triển khai ngay.
Thoạt nhìn, các phương pháp Solana và Zether có vẻ rất giống nhau vì chúng cũng sử dụng các cam kết ElGamal. Tuy nhiên, yếu tố phân biệt chính là nhu cầu giải quyết vấn đề logarit rời rạc để truy cập vào số dư được mã hóa.
Solana giảm nhẹ một phần điều này bằng cách duy trì một số dư có thể giải mã riêng biệt. Nhưng sự khác biệt chính là lược đồ mã hóa được sử dụng không hỗ trợ tổng hợp và số dư như vậy chủ yếu hoạt động như một bộ nhớ đệm, được cập nhật khi số tiền đang chờ xử lý được chuyển đến số tiền thực tế. Tuy nhiên, vẫn cần phải giải mã số dư được biểu thị dưới dạng cam kết ElGamal, điều này tái khẳng định sự cần thiết phải giải quyết vấn đề logarit rời rạc. Mặc dù quá trình này có thể được đơn giản hóa bằng cách chia giá trị thành các phần, giao thức cWETH đề xuất một lược đồ mã hóa có thể tổng hợp và được quản lý cùng với cam kết ElGamal để tránh tính toán logarit rời rạc.
Một sự khác biệt nữa nằm ở các bằng chứng ZK được cWETH sử dụng. Cả hai phương pháp Solana và Zether đều dựa trên các giao thức Sigma và bulletproof, trong khi đề xuất này dựa trên zk-SNARK. Sự đánh đổi ở đây là nhu cầu về một thiết lập đáng tin cậy, nhưng điều này có thể được giảm thiểu bằng cách sử dụng các thiết lập đáng tin cậy hiện có, chẳng hạn như thiết lập phổ quát của Plonk, đã được chứng minh là an toàn theo thời gian.
2. Tổng quan về cWETH
2.1. Gói ETH
Quá trình thiết lập tài khoản bí mật được coi là một phần của hoạt động đóng gói ETH . Cùng với logic đóng gói thông thường, khi gửi tiền lần đầu vào hợp đồng cWETH, mỗi người dùng cung cấp một khóa công khai babyJubJub sẽ được sử dụng để quản lý số dư.
Khóa công khai này được sử dụng trong cam kết và mã hóa số lượng Token và tính toán số dư. Quá trình tạo cặp khóa và luồng tiền gửi ban đầu được mô tả trong sơ đồ sau:
Sau lần gửi tiền đầu tiên vào hợp đồng cWETH, số dư ban đầu được cập nhật với các giá trị được tính theo cùng công thức được sử dụng cho chuyển khoản bí mật, với điều kiện người dùng vừa là người gửi vừa là người nhận. Các chi tiết kỹ thuật liên quan đến các giá trị này và quy trình tạo cặp khóa được cung cấp trong các phần tiếp theo của đề xuất này.
Về mặt khái niệm, hoạt động mở gói rất giống nhau nên sẽ không được đề cập trong phần này.
2.2. Quản lý cân bằng
Để tránh việc tính toán logarit rời rạc để tính số dư ẩn bằng ElGamal, hai biểu diễn số dư song song được duy trì:
- Cam kết ElGamal chỉ cần thiết cho việc xác minh bằng chứng ZK về kiến thức cân bằng.
- Số dư được mã hóa bằng khóa chia sẻ DH cho phép người dùng giải mã dữ liệu số dư thực tế của họ. Cần phải truy cập vào mảng khóa công khai của người gửi và mảng nonces mã hóa để thực hiện giải mã.
Vì bằng chứng ZK được tạo ra từ số dư hiện tại của người dùng, việc thay đổi nó trước khi thực hiện giao dịch có thể làm mất hiệu lực bằng chứng. Để giải quyết vấn đề này, cả hai loại số dư (cam kết ElGamal và DH-encrypted) phải được trình bày ở hai trạng thái riêng biệt:
- Số dư đang chờ để nhận mã thông báo.
- Số dư thực tế để chi tiêu token.
Người dùng có thể di chuyển token từ số dư đang chờ xử lý sang số dư thực tế bất kỳ lúc nào. Ngoài ra, có thể thực hiện vào cuối mỗi lần chuyển tiền do người dùng khởi tạo. Cách tiếp cận này sẽ hợp nhất việc cập nhật số dư thành một hoạt động duy nhất, giảm lượng gas sử dụng so với hai giao dịch riêng biệt.
2.3. Chuyển giao bí mật
Để bắt đầu chuyển tiền bí mật, cần cung cấp số tiền Token được thể hiện dưới bốn hình thức khác nhau:
- Ẩn bên trong cam kết ElGamal dựa trên khóa công khai của người nhận.
- Ẩn bên trong cam kết ElGamal dựa trên khóa công khai của người gửi.
- Được mã hóa bằng khóa chung DH dựa trên khóa công khai của người nhận để tăng số dư của người nhận.
- Được mã hóa bằng khóa chung DH dựa trên khóa công khai của người gửi cho số dư của người gửi mới.
Sơ đồ dưới đây minh họa quá trình chuyển giao thông tin bảo mật:
Trong quá trình chuyển tiền, cả hai loại số dư và số tiền liên quan đều được cập nhật để đảm bảo tính nhất quán giữa các biểu diễn số dư khác nhau.
Lưu ý rằng có hai phiên bản riêng biệt của cùng một giá trị cho cả hai được mã hóa bằng khóa chia sẻ DH và biểu diễn cam kết ElGamal: dựa trên khóa công khai của người gửi và dựa trên khóa công khai của người nhận. Điều này là do các phương pháp tiếp cận khác nhau được sử dụng trong quá trình mã hóa và tạo cam kết, các chi tiết kỹ thuật được cung cấp trong các phần tiếp theo của đề xuất.
3. Toán bảo mật
3.1. KDF cho cặp khóa bí mật
Giao thức sử dụng phương pháp KDF xác định để tạo cặp khóa bảo mật. Người dùng phải ký tin nhắn có cấu trúc Đề xuất cải tiến Ethereum (EIP)-712 bằng khóa riêng Ethereum (ECDSA) của họ. Hash của chữ ký là khóa riêng babyJubJub.
Tin nhắn Đề xuất cải tiến Ethereum (EIP)-712 được lấy như sau:
bytes32 KDF_MSG_TYPEHASH = keccak256(“KDF(address cWETHAddress)”); bytes32 kdfStructHash = keccak256(abi.encode(KDF_MSG_TYPEHASH, cWETHAddress));Khóa riêng tư babyJubJub được lấy như sau:
signature = eth_signTypedData_v4(kdfStructHash) ; privateKey = keccak256(keccak256(signature)) ;Lưu ý rằng điều quan trọng là không bao giờ tiết lộ chữ ký vì khóa riêng được lấy trực tiếp từ chữ ký đó.
Cặp khóa phải đáp ứng các yêu cầu sau:
3.2. Chương trình cam kết dựa trên EC ElGamal
Cam kết dựa trên sơ đồ EC ElGamal cho phép biểu diễn ngắn gọn phù hợp với các bằng chứng ZK. Nó cũng tạo điều kiện quản lý cân bằng liền mạch thông qua các thuộc tính đồng hình cộng tính của nó.
Cam kết về số dư bao gồm hai phần và được xây dựng theo công thức:
Để chứng minh hiệu quả cam kết về số dư thông qua bằng chứng ZK, người dùng phải sử dụng khóa riêng để bù đắp cho việc thiếu kiến thức về Nonce ngẫu nhiên tổng hợp:
Cam kết về số tiền chuyển được tính toán khác nhau cho người gửi và người nhận. Cam kết về số tiền của người nhận được tính như sau:
Cam kết số tiền chuyển khoản được sử dụng trong việc tổng hợp cam kết số dư của người gửi được tính như sau:
Cam kết số dư được tính theo phương pháp cộng như được nêu dưới đây:
3.3. Mã hóa bằng khóa chia sẻ EC DH
Vì các cam kết ElGamal không cung cấp phương tiện thuận tiện cho người dùng truy cập vào số dư đã giải mã, đòi hỏi phải giải quyết bài toán logarit rời rạc, nên một hình thức ẩn số tiền bổ sung thông qua mã hóa được sử dụng bằng cách sử dụng khóa chia sẻ EC DH.
Khóa chia sẻ DH được lấy như sau:
Lượng chuyển tiền được mã hóa dựa trên DH được thực hiện khác nhau đối với người gửi và người nhận.
Mã hóa số tiền chuyển khoản được sử dụng để tổng hợp số dư của người nhận được tính theo công thức:
Việc sử dụng Nonce ngẫu nhiên là cần thiết để giải quyết vấn đề rò rỉ dữ liệu chuyển giao tiềm ẩn do thiếu tính ngẫu nhiên trong sơ đồ mã hóa, điều này có thể đặc biệt đáng chú ý trong các khoản thanh toán định kỳ. Các giá trị Nonce này phải được lưu trữ cùng với khóa công khai của người gửi để người dùng có thể giải mã số dư của họ.
Số tiền được mã hóa sẽ được sử dụng để tổng hợp số dư của người nhận được mã hóa:
Theo công thức, người nhận có thể giải mã số dư của mình như sau:
Về phía người gửi, việc sử dụng phương pháp này để mã hóa số tiền chuyển có thể dẫn đến việc quản lý vô số khóa công khai và nonce ngẫu nhiên cần thiết cho việc giải mã số dư. Để giải quyết vấn đề này, mỗi lần người dùng chuyển token, danh sách khóa công khai và nonce ngẫu nhiên của người gửi hiện tại sẽ được đặt lại. Điều này được thực hiện bằng cách tính toán số dư của người gửi được mã hóa mới, như được nêu dưới đây:
Sau khi cập nhật số dư được mã hóa, người gửi chỉ cần quản lý khóa công khai và Nonce ngẫu nhiên của riêng họ dưới dạng một mục nhập duy nhất để giải mã tổng số lượng mã thông báo sở hữu.
Có thể sử dụng logic giống hệt để tính toán số dư mới để mở khóa token cWETH.
4. Hợp đồng thông minh Solidity
4.1. Biến trạng thái
4.1.1. Khóa công khai
Trước hết, mỗi người dùng được liên kết với khóa công khai tương ứng được tạo ra trong lần gửi tiền đầu tiên vào hợp đồng cWETH. Điều này được quản lý trong một mapping(address => uint256[2]) .
4.1.2. Cân bằng
Số dư của mỗi người dùng được thể hiện trong biểu mẫu cam kết ElGamal:
struct Commitment {uint256 [2] C;uint256 [2] D;}Để giải mã số dư được mã hóa bằng khóa chia sẻ DH, cùng với số dư DH, một mảng khóa công khai của người gửi và một mảng nonce mã hóa cần được lưu trữ:
struct DHBalance {uint256 encryptedBalance;uint256 [] [2] sendersPublicKeys;uint256 [] encryptionNonces;}Vì cả hai loại số dư đều phải được cung cấp dưới dạng số dư đang chờ xử lý và số dư thực tế nên việc lưu trữ số dư cuối cùng trông như thế này:
struct Balance {Commitment elGamalCommitmentPending;Commitment elGamalCommitmentActual;DHBalance dhEncryptedPending;DHBalance dhEncryptedActual;}mapping(uint256 => Balance) internal balances;Lưu ý rằng việc hạch toán số dư nội bộ được thực hiện bằng cách sử dụng tọa độ x của khóa công khai của người dùng làm khóa trong ánh xạ số dư.
4.2. Chức năng
4.2.1. Gửi tiền vào cWETH
Để tạo tài khoản bảo mật chính xác, cần cung cấp chức năng deposit :
function deposit(uint256[ 2 ] publicKey, bytes calldata amountCommitmentData, bytes calldata balanceEncryptionData, bytes calldata proofData) external payable; Cùng với bằng chứng ZK thông thường, proofData là cần thiết để đảm bảo rằng người dùng thực sự sở hữu khóa riêng cho Khóa công khai.
amountCommitmentData được giải mã thêm như sau:
(uint256[2] commitmentC, uint256[2] commitmentD) = abi.decode(amountCommitmentData, (uint256[2], uint256[2])); balanceEncryptionData được giải mã như sau:
(uint256 encryptedBalance, uint256 encryptionNonce) = abi.decode(balanceEncryptionData, (uint256, uint256));4.2.2. Chuyển giao bí mật
Khi hiểu rõ về các chương trình cam kết và mã hóa, hàm transfer có thể được chỉ định như sau:
function transfer(address receiver, bytes calldata amountCommitmentData, bytes calldata amountEncryptionData, bytes calldata proofData) external; amountCommitmentData được giải mã thêm như sau:
(uint256[2] senderCommitmentC, uint256[2] senderCommitmentD, uint256[2] receiverCommitmentC, uint256[2] receiverCommitmentD) = abi.decode(amountCommitmentData, (uint256[2], uint256[2], uint256[2], uint256[2])); amountEncryptionData được giải mã như sau:
(uint256 newEncryptedBalance, uint256 senderEncryptionNonce, uint256 receiverEncryptedAmount, uint256 receiverEncryptionNonce) = abi.decode(amountEncryptionData, (uint256, uint256, uint256, uint256));4.2.3. Rút cWETH
Để mở gói mã thông báo cWETH, chức năng withdraw sẽ được cung cấp:
function withdraw(uint256 amount, bytes calldata amountCommitmentData, bytes calldata balanceEncryptionData, bytes calldata proofData) external; amountCommitmentData được giải mã thêm như sau:
(uint256[2] commitmentC, uint256[2] commitmentD) = abi.decode(amountCommitmentData, (uint256[2], uint256[2])); balanceEncryptionData được giải mã như sau:
(uint256 newEncryptedBalance, uint256 encryptionNonce) = abi.decode(balanceEncryptionData, (uint256, uint256));5. Mạch điện Circom
Mỗi tham số được mô tả trong đề xuất này được thiết kế để có thể xác minh on-chain và tương thích với mạch không cần kiến thức.
5.1. Gửi tiền vào mạch cWETH
Danh sách các tín hiệu mạch để gửi vào bản chứng minh cWETH như sau:
Tín hiệu công cộng:
- Khóa công khai của người dùng;
- Số tiền ký quỹ;
- Cam kết ElGamal về số dư của người dùng;
- Cam kết của ElGamal về số tiền ký quỹ;
- Số dư của người dùng sau khi gửi tiền được mã hóa bằng khóa DH dựa trên khóa công khai của người dùng;
- Mã hóa Nonce ngẫu nhiên.
Tín hiệu riêng tư:
- Khóa riêng tư của người dù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:
- Khóa riêng được cung cấp thực chất là khóa riêng của Khóa công khai.
- Số tiền ký quỹ được cung cấp phải được chứng minh là số tiền đã cam kết sử dụng cam kết dựa trên ElGamal.
- Số dư của người dùng sau khi gửi tiền sẽ được chứng minh là số dư được mã hóa bằng khóa chia sẻ DH.
5.2. Mạch chuyển giao bí mật
Danh sách các tín hiệu mạch cho bằng chứng chuyển giao bí mật như sau:
Tín hiệu công cộng:
- Khóa công khai của người gửi;
- Khóa công khai của người nhận;
- Cam kết ElGamal về số dư của người gửi;
- 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 gửi;
- 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 nhận;
- Số dư của người gửi mới được mã hóa bằng khóa chia sẻ DH dựa trên khóa công khai của người gửi;
- Nonce ngẫu nhiên được sử dụng trong mã hóa số dư mới của người gửi;
- 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 nhận;
- Nonce ngẫu nhiên được sử dụng trong quá trình mã hóa số tiền chuyển của người nhận.
Tín hiệu riêng tư:
- Khóa riêng của người gửi;
- Số dư của người gửi;
- 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 gửi;
- Nonce ngẫu nhiên được sử dụng trong cam kết ElGamal của người nhận;
Để vận hành các tín hiệu này, mạch phải có những hạn chế sau:
- Khóa riêng được cung cấp thực chất là khóa riêng của Khóa công khai.
- Số dư của người gửi đượ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 chuyển.
- Cam kết ElGamal của người gửi về số tiền chuyển khoản đã được tạo chính xác.
- Cam kết ElGamal của người nhận về số tiền chuyển khoản đã được tạo chính xác.
- Số dư của người gửi mớ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 gửi.
- 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 nhận
5.3. Rút khỏi mạch cWETH
Danh sách các tín hiệu mạch để rút bằng chứng cWETH như sau:
Tín hiệu công cộng:
- Khóa công khai của người dùng;
- Địa chỉ người nhận;
- Số tiền rút ra;
- Cam kết ElGamal về số dư của người dùng;
- Cam kết của ElGamal về số tiền rút dựa trên khóa công khai của người dùng;
- Số dư sau khi rút tiền được mã hóa bằng khóa chung DH dựa trên khóa công khai của người dùng;
- Nonce ngẫu nhiên được sử dụng trong quá trình mã hóa số dư mới.
Tín hiệu riêng tư:
- Khóa riêng tư của người dùng;
- Số dư người dù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:
- Khóa riêng được cung cấp thực chất là khóa riêng của Khóa công khai.
- Số dư của người gửi đượ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 rút.
- Cam kết ElGamal về số tiền rút đã được tạo chính xác.
- Số dư mới (sau khi rút tiền) đã đượ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 dùng.
Tài liệu tham khảo
Quỹ Solana . Gia hạn Token bảo mật. 2022.
Benedikt B¨unz và cộng sự. Zether: Hướng tới quyền riêng tư trong thế giới hợp đồng thông minh. 2020.
