Vitalik khuyên bạn nên sử dụng zk-SNARK để tách tài khoản logic giao dịch khỏi tài khoản nắm giữ tài sản. Điều này cải thiện quyền riêng tư, trải nghiệm người dùng và khả năng phục hồi xã hội chỉ bằng một cú nhấp chuột. Nhà nghiên cứu Ethereum Toni Wahrstätter cung cấp phân tích chi tiết về nguyên mẫu ví này, bao gồm quy trình làm việc và các lợi thế.
Cảm ơn Matt rất nhiều vì những cuộc thảo luận thú vị về chủ đề này và đã phát triển công cụ này để phân tích từng hợp đồng và đưa nó vào cây Merkle thưa thớt giúp đơn giản hóa việc tạo nguyên mẫu bằng cách loại bỏ nhu cầu chứng minh zk trên cây patricia . Ngoài ra, xin cảm ơn Vitalik vì những đóng góp tuyệt vời của anh ấy.
Việc quản lý nhiều tài khoản có thể gặp khó khăn vì nhiều lý do, bao gồm các vấn đề về khôi phục xã hội, quyền riêng tư, L2 và trải nghiệm người dùng tổng thể. Việc sử dụng địa chỉ ẩn khiến mọi việc trở nên phức tạp hơn vì mỗi lần tương tác đều yêu cầu một tài khoản mới. Vitalik khuyên bạn nên sử dụng zk-SNARK để tách tài khoản logic giao dịch khỏi tài khoản nắm giữ tài sản. Điều này cải thiện quyền riêng tư, trải nghiệm người dùng và khả năng phục hồi xã hội chỉ bằng một cú nhấp chuột.
Đối với những điều sau đây, trước tiên tôi khuyên bạn nên xem bài đăng "Ba lần chuyển đổi" của Vitalik để biết thông tin cơ bản.
Tóm lại, những gì chúng tôi đang cố gắng đạt được là:
**Khôi phục xã hội một lần mà không ảnh hưởng đến quyền riêng tư. **
1. Phương pháp truyền thống
Cách triển khai đơn giản nhưng ảnh hưởng đến quyền riêng tư trông như thế này:
Người dùng cung cấp chữ ký và một số ý định/lệnh đối với tài khoản nắm giữ tài sản.
Tài khoản nắm giữ tài sản chuyển chữ ký sang tài khoản nắm giữ hợp lý.
Tài khoản nắm giữ logic lấy khóa chung từ chữ ký và so sánh nó với khóa chung được lưu trữ.
Nếu quá trình xác minh được thông qua, tài khoản logic sẽ thông báo cho tài khoản nắm giữ tài sản để tiếp tục hoạt động.
Tài khoản nắm giữ tài sản thực hiện lệnh của người dùng.
Điểm bất lợi là điều này liên kết công khai các tài khoản logic và tài khoản nắm giữ tài sản, do đó ảnh hưởng đến quyền riêng tư.
2. Sử dụng ZK-SNARK
Bằng cách sử dụng zk-SNARK, người dùng có thể chứng minh rằng họ được phép chi tiêu mà không tiết lộ mối liên hệ giữa tài khoản nắm giữ hợp lý và tài khoản nắm giữ tài sản.
Quy trình làm việc như sau:
Người dùng xây dựng cây Merkle cục bộ và xác định các lá chứa hợp đồng của mình.
1.1. Cây Merkle về cơ bản chứa các giá trị slot0 và slot1 của từng hợp đồng hiện có được sắp xếp theo ngày hoặc tên.
1.2. Mỗi người dùng có thể xây dựng cây Merkle cục bộ dựa trên trạng thái mới nhất.
Người dùng xây dựng bằng chứng zk để chứng minh rằng anh ta biết bí mật trong tài khoản nắm giữ hợp lý. Chứng minh chi tiết sau.
Người dùng gửi bằng chứng zk đến tài khoản nắm giữ tài sản.
Giấy xác nhận tài khoản nắm giữ tài sản, xác nhận các nội dung sau:
4.1 Người dùng biết logic ở đâu.
4.2 Người dùng biết giá trị bí mật được băm và ánh xạ tới giá trị được lưu trữ trong tài khoản lưu trữ logic.
4.3 Người dùng có thể xây dựng lại trạng thái tài khoản Gốc cây Merkle được duy trì trong chuỗi chuẩn (ví dụ: được biên dịch trước)
4.4 Sử dụng đúng số ngẫu nhiên (dùng để đổi chìa khóa trong tài khoản giữ logic).
Về cơ bản, người dùng có thể nói: "Tôi có sự cho phép có thể chứng minh được từ tài khoản lưu trữ logic để thực hiện hành động này và tôi biết vị trí của tài khoản logic đó".
lợi thế
Trải nghiệm người dùng: Một khóa riêng hoặc một thiết lập đa chữ ký có thể kiểm soát nhiều tài khoản, ngay cả khi chúng ở các L2 khác nhau.
Khôi phục: Tài khoản có thể được khôi phục dễ dàng hơn chỉ bằng một lần cập nhật hợp đồng.
Quyền riêng tư: Không có liên kết công khai giữa các tài khoản.
Khả năng tương thích: Điều này giúp phổ biến ví Tóm tắt tài khoản (AA) và các tính năng khác.
Ngoài ra, bằng cách thêm một hợp đồng (tổng hợp) khác giữa logic và hợp đồng nắm giữ tài sản, nhiều bằng chứng về các tài khoản nắm giữ tài sản khác nhau có thể được cung cấp trong một giao dịch, cho phép tài khoản được xử lý gần giống như UTXO. Người tổng hợp sẽ có thể nhận được nhiều chứng chỉ zk và chuyển chúng đến tài khoản nắm giữ tài sản tương ứng của họ để xác minh. Tất nhiên, một công cụ tổng hợp như vậy có thể tạo ra các liên kết – bao gồm cả quyền riêng tư – giữa các tài khoản nắm giữ tài sản riêng lẻ.
Cần lưu ý rằng không nhất thiết phải chọn một trong hai giữa việc sử dụng SNARK (và do đó dựa vào tính bảo mật của nó) và hoàn toàn không sử dụng SNARK (và do đó bỏ lỡ các đặc tính bảo mật tốt). Một thỏa hiệp có thể là sử dụng bằng chứng SNARK để mở một cửa sổ thời gian trong hợp đồng nắm giữ logic, sau đó là một khoảng thời gian trễ ngắn, sau đó chủ sở hữu hợp đồng nắm giữ logic có thể thay đổi giá trị slot0, thay vì yêu cầu bằng chứng SNARK để chi tiêu và do đó thay đổi logic tiêu dùng. Chủ sở hữu hiện tại của hợp đồng có thể sử dụng độ trễ trước khi cửa sổ thời gian mở ra để ngăn cập nhật thông tin xác thực.
chi tiết kỹ thuật
Cài đặt zk-SNARK bao gồm các phần tử riêng tư:
Key được sử dụng để xác minh.
Địa chỉ tài khoản nắm giữ hợp lý là địa chỉ được chỉ định bởi tài khoản nắm giữ tài sản.
Nhánh Merkle để xác định các giá trị trạng thái cụ thể.
Một nonce cho phép xoay phím trong khi vô hiệu hóa các phím cũ. Các phần tử riêng tư như địa chỉ hợp đồng và bí mật chứa logic văn bản gốc không được công khai mà được sử dụng để liên kết riêng tư các tài khoản nắm giữ logic và tài khoản nắm giữ tài sản. Bằng cách tạo ra bằng chứng của toàn bộ trạng thái, cơ quan trung ương không cần phải xây dựng cây Merkle để gửi bằng chứng.
1. Tài khoản nắm giữ hợp lý
Nguyên mẫu cho một tài khoản nắm giữ hợp lý có thể trông như thế này:
độ rắn pragma >=0,7,0 <0,9,0;
hợp đồng LogicHoldingAccount có thể sở hữu được { uint256 public slot0 = 0x1234; // bí mật băm uint256 public nonce = 0; // theo dõi những thay đổi quan trọng về địa chỉ của chủ sở hữu công cộng;
slot0: biến công khai ban đầu giữ giá trị băm. Chỉ có chủ sở hữu mới biết tiền tố băm.
nonce: Bộ đếm theo dõi số lần cập nhật thông tin chủ sở hữu. Điều này đảm bảo rằng các khóa cũ trở nên không hợp lệ.
updateOwner(uint256 newValue): Hàm cập nhật giá trị và thêm số ngẫu nhiên.
Hợp đồng này theo dõi logic chi tiêu hiện tại của chủ sở hữu (khe0) và cho phép cập nhật thông qua chức năng updateOwner.
2. Tài khoản nắm giữ tài khoản
độ rắn pragma >=0,7,0 <0,9,0;
hợp đồng AssetHoldingAccount { uint256 logic công khaiHoldingAccountHash = 1234...;
// Kích thước trường vô hướng, Kích thước trường cơ sở, Dữ liệu khóa xác minh, v.v. // ...
hàm verifyProof(uint [2] dữ liệu cuộc gọi _pA, uint [2] [2] dữ liệu cuộc gọi _pB, uint [2] dữ liệu cuộc gọi _pC, uint [2] calldata _pubSignals) trả về chế độ xem công khai (bool val) { // Mã lắp ráp Snarkjs để xác minh bằng chứng... // ... }
// _pubTín hiệu [0] - gốc của cây hợp đồng-slot0||nonce Merkle // _pubSignals [1] - hàm địa chỉ chứa logic hased ute(địa chỉ phải trả cho, số tiền uint256, uint [2] dữ liệu cuộc gọi _pA, uint [2] [2] dữ liệu cuộc gọi _pB, uint [2] dữ liệu cuộc gọi _pC, uint [2] calldata _pubSignals) public { ContractRootPrecompile.getRoot(block.number) uint256 được chỉ địnhLogicHolder = _pubSignals [1] ; require(specifiedLogicHolder == logicHoldingAccountHash, "Không được phép");
Tài khoản nắm giữ tài sản lưu trữ các tài sản như ETH và cho phép người dùng gửi bằng chứng rút tiền. Bằng cách xác minh rằng LogicHolder được chỉ định khớp với logicHoldingAccountHash, chủ sở hữu có thể đảm bảo rằng hợp đồng nắm giữ tài sản chỉ chấp nhận bằng chứng từ hợp đồng nắm giữ logic được ủy quyền chứ không phải bất kỳ hợp đồng tùy ý nào.
Bí mật được cung cấp dưới dạng tín hiệu riêng khi xây dựng bằng chứng đảm bảo rằng chỉ chủ sở hữu tài khoản chứa logic chi tiêu mới có thể truy cập tiền từ tài khoản nắm giữ tài sản.
3. Mạch
Mạch sau được phát triển bằng Circom, bạn có thể tìm thấy mã hoàn chỉnh tại đây.
pragma Circom 2.0.2;
bao gồm "./modules/merkleTree.circom";bao gồm "./modules/commitmentHasher.circom";
mẫu Chính (cấp độ) { gốc đầu vào tín hiệu; logic đầu vào tín hiệuHoldingAddressHash; logic đầu vào tín hiệuHoldingAddress; bí mật đầu vào tín hiệu; tín hiệu đầu vào nonce; Đường dẫn đầu vào tín hiệu [levels] ; đường dẫn tín hiệu đầu vàoChỉ số [levels] ; thành phần secretHasher = SecretHasher(); secretHasher.secret <== bí mật; máy băm thành phần = CommitmentHasher(); hasher.logicHoldingAddress <== logicHoldingAddress; hasher.secret <== secretHasher.hashedSecret; hasher.nonce <== nonce; hasher.logicHoldingAddressHash === logicHoldingAddressHash; cây thành phần = MerkleTreeChecker(levels); tree.leaf <== hasher.commitment; cây.root <== gốc; for ( i = 0; i < cấp độ; i++) { tree.pathElements [i] <== phần tử đường dẫn [i] ; tree.pathIndices [i] <== đường dẫnChỉ số [i] ;
thành phần chính {public [root,logicHoldingAddressHash]} = Main(N);
Mạch có tổng cộng 7 tín hiệu, trong đó có 2 tín hiệu công khai, đó là gốc cây Merkle và địa chỉ băm của tài khoản nắm giữ logic (phải được băm trước khi mã hóa vào hợp đồng nắm giữ tài sản để ngăn người quan sát tổng hợp tài khoản) class) dựa trên logic tương tự như tài khoản chủ sở hữu).
Tóm lại là
Trong thế giới nơi người dùng phải quản lý nhiều tài khoản, nhu cầu về chức năng khôi phục xã hội toàn diện ngày càng trở nên quan trọng. Zk-SNARK có thể được sử dụng trong các ví thực hiện phân tách logic/tài sản, cho phép người dùng sử dụng "logic" của Tài khoản A để chi tiêu từ Tài khoản B mà không cần tạo liên kết giữa hai tài khoản. Bước đầu tiên, bằng chứng SNARK có thể được sử dụng cho các hành động ít rủi ro hơn so với chi tiêu tài sản. Ví dụ: điểm khởi đầu tốt có thể là cho phép người dùng bắt đầu "yêu cầu rút tiền". Nếu chủ sở hữu hợp đồng nắm giữ logic không phản đối, người dùng có thể hoàn tất yêu cầu sau một khoảng thời gian.
Bằng cách này, chủ sở hữu hợp đồng nắm giữ hợp lý vẫn có thể can thiệp, mặc dù theo cách vi phạm quyền riêng tư, trong trường hợp có điều gì đó không mong muốn xảy ra.
Xem bản gốc
Trang này có thể chứa nội dung của bên thứ ba, được cung cấp chỉ nhằm mục đích thông tin (không phải là tuyên bố/bảo đảm) và không được coi là sự chứng thực cho quan điểm của Gate hoặc là lời khuyên về tài chính hoặc chuyên môn. Xem Tuyên bố từ chối trách nhiệm để biết chi tiết.
Cách zk-SNARK nhận ra sự tách biệt giữa logic giao dịch ví và tài sản
Tác giả: @Toni Wahrstätter Dịch: Viện DeBox
###Lời nói đầu
Vitalik khuyên bạn nên sử dụng zk-SNARK để tách tài khoản logic giao dịch khỏi tài khoản nắm giữ tài sản. Điều này cải thiện quyền riêng tư, trải nghiệm người dùng và khả năng phục hồi xã hội chỉ bằng một cú nhấp chuột. Nhà nghiên cứu Ethereum Toni Wahrstätter cung cấp phân tích chi tiết về nguyên mẫu ví này, bao gồm quy trình làm việc và các lợi thế.
Việc quản lý nhiều tài khoản có thể gặp khó khăn vì nhiều lý do, bao gồm các vấn đề về khôi phục xã hội, quyền riêng tư, L2 và trải nghiệm người dùng tổng thể. Việc sử dụng địa chỉ ẩn khiến mọi việc trở nên phức tạp hơn vì mỗi lần tương tác đều yêu cầu một tài khoản mới. Vitalik khuyên bạn nên sử dụng zk-SNARK để tách tài khoản logic giao dịch khỏi tài khoản nắm giữ tài sản. Điều này cải thiện quyền riêng tư, trải nghiệm người dùng và khả năng phục hồi xã hội chỉ bằng một cú nhấp chuột.
Tóm lại, những gì chúng tôi đang cố gắng đạt được là:
**Khôi phục xã hội một lần mà không ảnh hưởng đến quyền riêng tư. **
1. Phương pháp truyền thống
Cách triển khai đơn giản nhưng ảnh hưởng đến quyền riêng tư trông như thế này:
Điểm bất lợi là điều này liên kết công khai các tài khoản logic và tài khoản nắm giữ tài sản, do đó ảnh hưởng đến quyền riêng tư.
2. Sử dụng ZK-SNARK
Bằng cách sử dụng zk-SNARK, người dùng có thể chứng minh rằng họ được phép chi tiêu mà không tiết lộ mối liên hệ giữa tài khoản nắm giữ hợp lý và tài khoản nắm giữ tài sản.
Quy trình làm việc như sau:
1.1. Cây Merkle về cơ bản chứa các giá trị slot0 và slot1 của từng hợp đồng hiện có được sắp xếp theo ngày hoặc tên.
1.2. Mỗi người dùng có thể xây dựng cây Merkle cục bộ dựa trên trạng thái mới nhất.
Người dùng xây dựng bằng chứng zk để chứng minh rằng anh ta biết bí mật trong tài khoản nắm giữ hợp lý. Chứng minh chi tiết sau.
Người dùng gửi bằng chứng zk đến tài khoản nắm giữ tài sản.
Giấy xác nhận tài khoản nắm giữ tài sản, xác nhận các nội dung sau:
4.1 Người dùng biết logic ở đâu.
4.2 Người dùng biết giá trị bí mật được băm và ánh xạ tới giá trị được lưu trữ trong tài khoản lưu trữ logic.
4.3 Người dùng có thể xây dựng lại trạng thái tài khoản Gốc cây Merkle được duy trì trong chuỗi chuẩn (ví dụ: được biên dịch trước)
4.4 Sử dụng đúng số ngẫu nhiên (dùng để đổi chìa khóa trong tài khoản giữ logic).
Về cơ bản, người dùng có thể nói: "Tôi có sự cho phép có thể chứng minh được từ tài khoản lưu trữ logic để thực hiện hành động này và tôi biết vị trí của tài khoản logic đó".
lợi thế
Ngoài ra, bằng cách thêm một hợp đồng (tổng hợp) khác giữa logic và hợp đồng nắm giữ tài sản, nhiều bằng chứng về các tài khoản nắm giữ tài sản khác nhau có thể được cung cấp trong một giao dịch, cho phép tài khoản được xử lý gần giống như UTXO. Người tổng hợp sẽ có thể nhận được nhiều chứng chỉ zk và chuyển chúng đến tài khoản nắm giữ tài sản tương ứng của họ để xác minh. Tất nhiên, một công cụ tổng hợp như vậy có thể tạo ra các liên kết – bao gồm cả quyền riêng tư – giữa các tài khoản nắm giữ tài sản riêng lẻ.
chi tiết kỹ thuật
Cài đặt zk-SNARK bao gồm các phần tử riêng tư:
1. Tài khoản nắm giữ hợp lý
Nguyên mẫu cho một tài khoản nắm giữ hợp lý có thể trông như thế này:
độ rắn pragma >=0,7,0 <0,9,0;
hợp đồng LogicHoldingAccount có thể sở hữu được { uint256 public slot0 = 0x1234; // bí mật băm uint256 public nonce = 0; // theo dõi những thay đổi quan trọng về địa chỉ của chủ sở hữu công cộng;
hàm cập nhậtOwner(uint256 newValue) public onlyOwner { nonce += 1; slot0 = newValue;
Hợp đồng này theo dõi logic chi tiêu hiện tại của chủ sở hữu (khe0) và cho phép cập nhật thông qua chức năng updateOwner.
2. Tài khoản nắm giữ tài khoản
độ rắn pragma >=0,7,0 <0,9,0;
hợp đồng AssetHoldingAccount { uint256 logic công khaiHoldingAccountHash = 1234...;
// Kích thước trường vô hướng, Kích thước trường cơ sở, Dữ liệu khóa xác minh, v.v. // ...
hàm verifyProof(uint [2] dữ liệu cuộc gọi _pA, uint [2] [2] dữ liệu cuộc gọi _pB, uint [2] dữ liệu cuộc gọi _pC, uint [2] calldata _pubSignals) trả về chế độ xem công khai (bool val) { // Mã lắp ráp Snarkjs để xác minh bằng chứng... // ... }
// _pubTín hiệu [0] - gốc của cây hợp đồng-slot0||nonce Merkle // _pubSignals [1] - hàm địa chỉ chứa logic hased ute(địa chỉ phải trả cho, số tiền uint256, uint [2] dữ liệu cuộc gọi _pA, uint [2] [2] dữ liệu cuộc gọi _pB, uint [2] dữ liệu cuộc gọi _pC, uint [2] calldata _pubSignals) public { ContractRootPrecompile.getRoot(block.number) uint256 được chỉ địnhLogicHolder = _pubSignals [1] ; require(specifiedLogicHolder == logicHoldingAccountHash, "Không được phép");
bool validProof = verifyProof(_pA, _pB, _pC, _pubSignals) == true; if (validProof) { (bool thành công,) = to.call{value:amount}(""); yêu cầu(thành công); } }
nhận() thanh toán bên ngoài {
Tài khoản nắm giữ tài sản lưu trữ các tài sản như ETH và cho phép người dùng gửi bằng chứng rút tiền. Bằng cách xác minh rằng LogicHolder được chỉ định khớp với logicHoldingAccountHash, chủ sở hữu có thể đảm bảo rằng hợp đồng nắm giữ tài sản chỉ chấp nhận bằng chứng từ hợp đồng nắm giữ logic được ủy quyền chứ không phải bất kỳ hợp đồng tùy ý nào.
Bí mật được cung cấp dưới dạng tín hiệu riêng khi xây dựng bằng chứng đảm bảo rằng chỉ chủ sở hữu tài khoản chứa logic chi tiêu mới có thể truy cập tiền từ tài khoản nắm giữ tài sản.
3. Mạch
Mạch sau được phát triển bằng Circom, bạn có thể tìm thấy mã hoàn chỉnh tại đây.
pragma Circom 2.0.2;
bao gồm "./modules/merkleTree.circom";bao gồm "./modules/commitmentHasher.circom";
mẫu Chính (cấp độ) { gốc đầu vào tín hiệu; logic đầu vào tín hiệuHoldingAddressHash; logic đầu vào tín hiệuHoldingAddress; bí mật đầu vào tín hiệu; tín hiệu đầu vào nonce; Đường dẫn đầu vào tín hiệu [levels] ; đường dẫn tín hiệu đầu vàoChỉ số [levels] ; thành phần secretHasher = SecretHasher(); secretHasher.secret <== bí mật; máy băm thành phần = CommitmentHasher(); hasher.logicHoldingAddress <== logicHoldingAddress; hasher.secret <== secretHasher.hashedSecret; hasher.nonce <== nonce; hasher.logicHoldingAddressHash === logicHoldingAddressHash; cây thành phần = MerkleTreeChecker(levels); tree.leaf <== hasher.commitment; cây.root <== gốc; for ( i = 0; i < cấp độ; i++) { tree.pathElements [i] <== phần tử đường dẫn [i] ; tree.pathIndices [i] <== đường dẫnChỉ số [i] ;
thành phần chính {public [root,logicHoldingAddressHash]} = Main(N);
Mạch có tổng cộng 7 tín hiệu, trong đó có 2 tín hiệu công khai, đó là gốc cây Merkle và địa chỉ băm của tài khoản nắm giữ logic (phải được băm trước khi mã hóa vào hợp đồng nắm giữ tài sản để ngăn người quan sát tổng hợp tài khoản) class) dựa trên logic tương tự như tài khoản chủ sở hữu).
Tóm lại là
Trong thế giới nơi người dùng phải quản lý nhiều tài khoản, nhu cầu về chức năng khôi phục xã hội toàn diện ngày càng trở nên quan trọng. Zk-SNARK có thể được sử dụng trong các ví thực hiện phân tách logic/tài sản, cho phép người dùng sử dụng "logic" của Tài khoản A để chi tiêu từ Tài khoản B mà không cần tạo liên kết giữa hai tài khoản. Bước đầu tiên, bằng chứng SNARK có thể được sử dụng cho các hành động ít rủi ro hơn so với chi tiêu tài sản. Ví dụ: điểm khởi đầu tốt có thể là cho phép người dùng bắt đầu "yêu cầu rút tiền". Nếu chủ sở hữu hợp đồng nắm giữ logic không phản đối, người dùng có thể hoàn tất yêu cầu sau một khoảng thời gian.
Bằng cách này, chủ sở hữu hợp đồng nắm giữ hợp lý vẫn có thể can thiệp, mặc dù theo cách vi phạm quyền riêng tư, trong trường hợp có điều gì đó không mong muốn xảy ra.