EIP-7503: Lỗ sâu không kiến thức cho các giao dịch Ethereum riêng tư

EIP-7503: Zero-Knowledge Wormholes là một Đề xuất cải tiến Ethereum (EIP) giới thiệu một cơ chế để thực hiện chuyển tiền bảo vệ quyền riêng tư trên Ethereum. Mặc dù chúng tôi đã thấy nhiều nỗ lực để thực hiện chuyển tiền trên chuỗi riêng tư, bao gồm cả các bộ trộn tiền điện tử như Tornado Cash, EIP-7503 là một giải pháp lớp giao thức giúp Ethereum trở nên riêng tư theo mặc định .

Đây là một cân nhắc quan trọng: các phương pháp tiếp cận quyền riêng tư ở lớp ứng dụng như Tornado Cash là "tùy chọn tham gia", thường có tác động tiêu cực đến người dùng. Các ứng dụng tập trung vào quyền riêng tư cũng dễ bị kiểm duyệt hơn; ví dụ, nhiều người dùng (đặc biệt là công dân Hoa Kỳ) đã không thể tương tác với Tornado Cash sau khi Văn phòng Kiểm soát Tài sản Nước ngoài (OFAC) đưa các địa chỉ hợp đồng của giao thức vào danh sách đen vào năm 2022 .

Bất chấp lệnh trừng phạt của OFAC, Tornado Cash vẫn tiếp tục hoạt động vì một số lý do:

1. Các hợp đồng cốt lõi thực hiện chức năng trộn tài sản của Tornado Cash là không thể thay đổi và được lưu trữ vĩnh viễn trên chuỗi. Vì chính tornado.cash trang web đã ngừng hoạt động, các dự án độc lập đã sử dụng lại mã hợp đồng từ bản triển khai Tornado Cash ban đầu để tạo ra các biến thể mới như Tiền mặt Tornado Nova .
2. Giao thức Tornado Cash phần lớn là "không thể quản lý được". Nhóm sáng lập Tornado Cash đã xóa bỏ các biện pháp kiểm soát hành chính sau thực hiện nâng cấp khẩn cấp để vá một lỗi cho phép kẻ tấn công tạo ra bằng chứng hợp lệ cho các khoản tiền gửi giả và rút tiền (được gửi hợp pháp). Do đó, nhóm sáng lập không thể đơn phương kích hoạt công tắc tắt và bị ép buộc "tắt" giao thức mặc dù bắt giữ năm 2023 .

Các yếu tố đã đề cập ở trên có nghĩa là mọi người vẫn có thể sử dụng Tornado Cash ngày nay, ngay cả khi các phân tích cho thấy các nhà sản xuất khối trên Ethereum đang loại bỏ các giao dịch tương tác với các hợp đồng của giao thức . Tuy nhiên, giống như trong những ngày trước lệnh trừng phạt của OFAC, không phải mọi giao dịch được định tuyến qua giao thức trộn Tornado Cash đều hợp pháp. Để minh họa, một bài viết của Arkham Intelligence cho rằng ít nhất hai cuộc tấn công nổi cộm vào năm 2023 (vụ khai thác 197 triệu đô la của Euler Finance và vụ kéo thảm 60 triệu đô la của Anubis DAO) được tài trợ bằng tiền rút từ Tornado Cash hoặc sử dụng máy trộn để rửa tiền bị đánh cắp và che giấu các khoản chuyển tiền ra.

Với việc Tornado Cash vẫn chưa giải quyết được vấn đề về những kẻ xấu lợi dụng quyền riêng tư trên chuỗi, tại sao chúng ta lại muốn triển khai một tính năng để thực hiện chuyển tiền riêng tư ở cấp độ giao thức? Điều đó không phải là rủi ro sao? Tại sao ngay từ đầu lại cần phải có các giao dịch riêng tư? Các blockchain như Ethereum không phải đã ẩn danh và "không thể theo dõi" rồi sao?

Đây đều là những câu hỏi chính đáng, tất cả chúng ta sẽ thảo luận trong bài viết này. Chúng tôi sẽ cung cấp tổng quan cấp cao về tầm quan trọng của quyền riêng tư tài chính và khám phá lý do tại sao các blockchain công khai như Ethereum không thể đảm bảo quyền riêng tư mà không thực hiện thay đổi. Sau đó, chúng tôi sẽ phân tích cách tiếp cận của EIP-7503 để cho phép thanh toán riêng tư trên Ethereum và thảo luận về những lợi thế và hạn chế tiềm ẩn của việc áp dụng EIP-7503.

Hãy cùng khám phá nhé!

Chuẩn bị bối cảnh: Tại sao chúng ta nên quan tâm đến quyền riêng tư trên chuỗi?

Khi chúng ta nói về “giao dịch riêng tư” hoặc “giao dịch ẩn danh” trong bối cảnh thanh toán ngang hàng điện tử (P2P), chúng ta đang mô tả hai phẩm chất: không thể theo dõi và không thể liên kết . Cả hai phẩm chất đều được Nicolas van Saberhagen nêu trong sách trắng CryptoNote :

• Không thể theo dõi : Một giao dịch không thể theo dõi nếu người gửi không thể được xác định một cách đáng tin cậy bởi một người quan sát bên ngoài. Giả sử Alice là bạn của Bob và Carol và Alice nhận được hai mã thông báo thông qua một lần chuyển giao—không thể theo dõi có nghĩa là không ai có thể biết ai (Bob hoặc Carol) đã gửi mã thông báo cho Alice.

• Không thể liên kết : Một giao dịch không thể liên kết nếu người nhận không thể được xác định một cách đáng tin cậy bởi một người quan sát bên ngoài. Nếu Bob và Carol gửi mã thông báo cho Alice trong các giao dịch riêng biệt, thì tính không thể liên kết có nghĩa là không ai có thể biết được liệu Bob và Carol có gửi mã thông báo cho cùng một người hay không.

  
  

Hầu hết (nếu không muốn nói là tất cả) các giải pháp bảo mật trên chuỗi có thể được phân loại dựa trên các yêu cầu đã đề cập ở trên mà chúng đáp ứng. Các máy trộn tiền điện tử , CoinJoin và chữ ký vòng chủ yếu liên quan đến việc che giấu thông tin về địa chỉ gửi và khiến tiền không thể theo dõi được. Danh tính của người gửi được bảo vệ bằng các cơ chế khác nhau, nhưng bất kỳ ai cũng có thể biết ai đã nhận tiền.

Trong khi đó, các giao thức tập trung vào quyền riêng tư như Monero , Zcash , Liquid Network và Aztec v1 cung cấp các biến thể của giao dịch "được bảo vệ" hoặc "bí mật" và đảm bảo tính không liên kết của giao dịch. Giao dịch được bảo vệ hoặc bí mật khó có thể liên kết với một người nhận cụ thể vì thông tin chi tiết về địa chỉ của người nhận (cũng như số lượng và loại mã thông báo được chuyển) được giữ bí mật. Địa chỉ ẩn là một cách tiếp cận khác để duy trì tính không liên kết: người dùng tạo một địa chỉ tạm thời (tồn tại trong thời gian ngắn) cho một khoản tiền gửi, chặn các nỗ lực liên kết hai giao dịch chuyển tiền đến cùng một địa chỉ.

Các cách tiếp cận đã đề cập ở trên để cải thiện quyền riêng tư của giao dịch có những điểm mạnh và điểm yếu riêng, chúng ta sẽ khám phá ngắn gọn sau. Nhưng hiện tại, chúng ta sẽ chuyển sự chú ý của mình sang một câu hỏi cơ bản: "Tại sao quyền riêng tư về tài chính lại quan trọng?" Vì chúng ta đang dành thời gian và công sức để phân tích đề xuất đưa các giao dịch riêng tư và ẩn danh vào Ethereum, chúng ta cũng có thể trình bày lý do cho việc cho phép quyền riêng tư của giao dịch trên Ethereum.

Quyền riêng tư về tài chính rất quan trọng vì quyền riêng tư là quyền cơ bản của con người . Quyền riêng tư trao cho mỗi cá nhân quyền quyết định thông tin nào họ muốn chia sẻ công khai và giữ quyền kiểm soát cách thức, thời điểm và địa điểm chia sẻ thông tin nhận dạng cá nhân (PII). “Thông tin nhận dạng cá nhân” là một phạm trù rộng bao gồm bất kỳ thông tin nào có thể được sử dụng để khám phá danh tính của một cá nhân—bao gồm thông tin chi tiết về hoạt động tài chính (ví dụ: lịch sử mua hàng, chuyển khoản điện tử và thu nhập).

Dưới đây là một số ví dụ về cách cá nhân có thể thực hiện quyền riêng tư (tài chính) của mình:

• Mua thuốc tránh thai trực tuyến mà không cần gia đình hỏi tại sao bạn không muốn tăng số lượng vào Lễ Tạ ơn năm sau. Hãy tưởng tượng các ngân hàng công bố thông tin về các giao dịch trực tuyến để bà Beth biết Cheryl đang tích cực tước đoạt cháu của bà. Mọi chuyện sẽ trở nên khó xử đến mức nào?
• Quyên góp cho tổ chức từ thiện mà không tiết lộ chi tiết về số tiền bạn đã quyên góp hoặc liệu bạn có quyên góp hay không. Điều này rất quan trọng nếu bạn quyên góp cho một mục đích từ thiện mà vẫn có thể gây chú ý trong một số nhóm nhất định—hoặc bạn ghét phải trình diễn và thu hút sự chú ý (không cần thiết) vào các hoạt động từ thiện của mình.
• Quyên góp cho một mục đích chính trị mà bạn không muốn công khai liên quan. Ví dụ, Vitalik Buterin (người gốc Nga) quyên góp cho lực lượng Ukraine chống lại cuộc xâm lược của Nga—với quốc tịch của Vitalik, một khoản quyên góp công khai có thể gây ra một cuộc khủng hoảng quan hệ công chúng không cần thiết, vì vậy , tiền đã được gửi qua Tornado Cash .
• Thực hiện thanh toán mà không tiết lộ thông tin chi tiết về tình hình tài chính của bạn cho những kẻ xấu. Bạn không muốn ai đó biết bạn đã kiếm được $X tổng thu nhập vào năm ngoái, điều này cung cấp cho họ đủ thông tin để lập kế hoạch đánh cắp số tiền đó (ví dụ, thông qua lừa đảo và các chiến thuật kỹ thuật xã hội khác).
• Trả lương cho nhân viên mà không tiết lộ thông tin về thu nhập của nhân viên. Có thể bạn muốn giữ bí mật thông tin về hoạt động tài chính của công ty hoặc nhân viên của bạn muốn giữ bí mật thông tin đó.

Những ví dụ này cung cấp các trường hợp sử dụng thực tế cho quyền riêng tư tài chính, nhưng cũng làm nổi bật một chi tiết mà những người chỉ trích quyền riêng tư thường không thừa nhận: quyền riêng tư không phải là thứ chúng ta tin rằng mình cần cho đến khi quá muộn. Câu trả lời thường gặp "bạn đang che giấu điều gì?" không thừa nhận một số tình huống mà các bên liên quan muốn tiết lộ ít hoặc không tiết lộ thông tin về giao dịch tài chính. Và ngay cả khi mọi người muốn che giấu mọi thứ vì lý do tùy ý, tại sao lại làm phiền họ, miễn là mong muốn giữ bí mật của họ không gây nguy hiểm cho sức khỏe và sự an toàn của công chúng?

Thà có mà không cần còn hơn là cần mà không có. ― Franz Kafka

Giải quyết vấn đề riêng tư của Ethereum với EIP-7503

Trái ngược với những mô tả ban đầu của cả những người ủng hộ và chỉ trích, các blockchain công khai như Ethereum và Bitcoin không hề ẩn danh hay riêng tư. Hai thuật ngữ này thường bị gộp chung, nhưng chúng có nghĩa là hai điều khác nhau:

• Quyền riêng tư có nghĩa là các hành động bí mật của bạn có thể truy xuất đến danh tính công khai của bạn, nhưng các chi tiết về hành động của bạn được ẩn. Giả sử bạn gửi một email được mã hóa bằng công cụ PGP ( Quyền riêng tư khá tốt ): máy chủ thư biết bạn đã gửi email cho một bên khác (có thể nhận dạng được), nhưng không thể đọc nội dung email. Đây là một hành động bí mật vì không ai khác biết bạn đã gửi email, ngoại trừ người nhận.

• Tính ẩn danh có nghĩa là các hành động công khai của bạn được tách khỏi danh tính công khai của bạn. Để sử dụng ví dụ trước: một dịch vụ email ẩn danh ngang hàng giả định có thể che giấu nguồn gốc và đích đến của một email được mã hóa, trong khi vẫn duy trì hồ sơ công khai của tất cả các email được định tuyến qua mạng. Đây là một hành động công khai vì hồ sơ của một người gửi email có thể được mọi người tham gia trên mạng nhìn thấy, nhưng địa chỉ email là chuỗi băm ( 0xdeadbeef ) chứ không phải tên ( [email protected] ).

  
  

Ethereum không phải là riêng tư vì blockchain duy trì một bản ghi cho mỗi giao dịch, bao gồm số tiền đã được chuyển và các hành động trên chuỗi mà giao dịch thực hiện. Ethereum cũng không ẩn danh vì thông tin về các tài khoản giao dịch trên blockchain (được xác định theo địa chỉ ) là công khai. Bạn không được sử dụng tên thật như "Alice Hopkins" cho tài khoản Ethereum của mình, nhưng việc sử dụng cùng một địa chỉ cho mọi giao dịch cho phép pháp y blockchain liên kết các giao dịch với danh tính ngoài đời thực của bạn—sử dụng các kỹ thuật như giám sát địa chỉ IP , phân cụm địa chỉ và phân tích đồ thị .

Ethereum do đó được mô tả chính xác là ẩn danh và không thể đảm bảo tính ẩn danh hoặc quyền riêng tư. Điều này không tốt cho một nền tảng được kỳ vọng sẽ trở thành lớp thanh toán cho Internet of Value trong tương lai. Để hiểu rõ hơn, các ngân hàng đã cung cấp một số mức độ riêng tư cho người dùng bằng cách lưu trữ dữ liệu tài chính trong các cơ sở dữ liệu tập trung với các cơ chế kiểm soát truy cập nghiêm ngặt để ngăn chặn truy cập trái phép.

Đây là “quyền riêng tư giả” vì ngân hàng và nhà cung cấp cơ sở hạ tầng cơ sở dữ liệu có quyền truy cập vào thông tin này và có thể làm bất cứ điều gì họ muốn với thông tin đó (ví dụ: đóng băng các khoản thanh toán đến một số quốc gia nhất định để tuân thủ lệnh trừng phạt dựa trên phân tích về đích đến của giao dịch chuyển tiền). Nhưng trong trường hợp kinh điển của “lựa chọn giữa quỷ dữ và biển xanh thẳm”, một cá nhân trung bình có thể sẽ chọn một số quyền riêng tư hơn là không có quyền riêng tư, điều này loại trừ việc mở tài khoản Ethereum và để mọi hành động trên chuỗi được thế giới nhìn thấy.

Nhiều người đã nhận ra vấn đề này, đặc biệt là vì nó khiến người dùng tránh xa các công nghệ phi tập trung như Ethereum để chuyển sang các giải pháp tập trung cung cấp bảo đảm quyền riêng tư tốt hơn một chút với cái giá phải trả là sự phản kháng với kiểm duyệt và tính minh bạch (cùng nhiều thứ khác). Ví dụ, The Three Transitions của Vitalik đưa ra một lập luận tuyệt vời về tầm quan trọng của quyền riêng tư đối với triển vọng áp dụng rộng rãi của Ethereum:

Nếu không có bước thứ ba [chuyển sang chuyển tiền bảo vệ quyền riêng tư], Ethereum sẽ thất bại vì việc công khai tất cả các giao dịch (và POAP, v.v.) để bất kỳ ai cũng có thể xem là sự đánh đổi quyền riêng tư quá lớn đối với nhiều người dùng và mọi người sẽ chuyển sang các giải pháp tập trung ít nhất là ẩn phần nào dữ liệu của bạn. — Vitalik Buterin

EIP-7503 là nỗ lực khắc phục một số vấn đề đã mô tả trước đó, đặc biệt là việc thiếu tính ẩn danh đối với người gửi giao dịch. Đề xuất này giới thiệu một phương tiện để các địa chỉ cố tình phá hủy Ether (ETH) bằng cách gửi tiền đến một địa chỉ không thể chi tiêu và tạo bằng chứng ZK-SNARK để xác thực khoản tiền gửi đến địa chỉ không thể chi tiêu đó. Nếu bằng chứng này vượt qua quá trình xác minh, một lượng token ETH (bằng với số dư của địa chỉ không thể chi tiêu) sẽ được đúc thành một địa chỉ mới do người dùng lựa chọn—phá vỡ liên kết giữa địa chỉ gửi và địa chỉ nhận liên quan đến việc chuyển tiền.

EIP-7503 mượn ý tưởng từ các giao thức bảo mật hiện có để hỗ trợ các giao dịch bảo vệ quyền riêng tư trên Ethereum. Ví dụ, đề xuất này khiến việc theo dõi các khoản tiền nhận được trong giao dịch đúc tiền đến một nguồn cụ thể trở nên khó khăn bằng cách biến toàn bộ tập hợp các địa chỉ Ethereum có số dư ETH và không có giao dịch nào được gửi đi thành một tập hợp ẩn danh . Bạn không thể dễ dàng xác định địa chỉ A chịu trách nhiệm đốt ETH mà địa chỉ B đã đúc lại trong giao dịch tiếp theo: A có thể là một trong hàng triệu địa chỉ có số dư khác không nhưng chưa bắt đầu giao dịch Ethereum.

Điều này tương tự như ý tưởng trộn tiền từ nhiều nguồn khác nhau vào một nhóm duy nhất và cho phép người gửi tiền rút tiền từ nhóm bằng một địa chỉ khác. Tuy nhiên, EIP-7503 so sánh thuận lợi với các công cụ trộn tiền điện tử như Tornado Cash vì nó cung cấp khả năng phủ nhận hợp lý . Khả năng phủ nhận hợp lý là một khái niệm mà chúng ta sẽ khám phá sau, nhưng tất cả những gì bạn cần biết bây giờ là nó cho phép bạn (một người dùng thực hiện chuyển khoản riêng tư EIP-7503) có thể phủ nhận việc thực hiện giao dịch riêng tư.

Khả năng phủ nhận hợp lý là một tính năng quan trọng của EIP-7503 giúp ngăn chặn những người quan sát bên ngoài không ẩn danh người gửi các giao dịch riêng tư. Điều này có thể ngăn chặn sự lặp lại của thảm họa Tornado Cash trong đó một số địa chỉ nhất định bị đưa vào danh sách đen và bị hạn chế truy cập vào các ứng dụng phi tập trung, sàn giao dịch và giao thức DeFi vì giám định trên chuỗi đã tiết lộ các tương tác trong quá khứ với Tornado Cash—ngay cả khi một số tài khoản đó đã tương tác với Tornado Cash vì lý do vô hại (ví dụ: thực hiện các khoản quyên góp riêng tư).

EIP-7503 cũng vay mượn từ các giao thức tập trung vào quyền riêng tư khác như Zcash và Aztec v1 bằng cách sử dụng bằng chứng mật mã để xác thực giao dịch mà không tiết lộ chi tiết giao dịch. Xác thực giao dịch theo cách bảo vệ quyền riêng tư đảm bảo Ethereum có thể hỗ trợ an toàn cho các giao dịch chuyển tiền riêng tư mà không làm suy yếu mô hình bảo mật hiện có phụ thuộc vào mạng lưới các nút phân tán thực hiện lại từng giao dịch để xác nhận tính chính xác của giao dịch. Chúng ta sẽ khám phá chi tiết về cách EIP-7503 sử dụng ZK-SNARKs để hỗ trợ thực hiện an toàn các giao dịch chuyển tiền riêng tư trên Ethereum trong các phần tiếp theo (cùng với những nội dung khác).

Lưu ý *: Mặc dù phân biệt quyền riêng tư với ẩn danh, tôi sẽ sử dụng “riêng tư” và “ẩn danh” thay thế cho nhau trong suốt bài viết này để giữ mọi thứ đơn giản và tránh gây nhầm lẫn cho độc giả vốn quen nghĩ hai khái niệm này là một và giống nhau. Hơn nữa, EIP-7503 bao gồm các yếu tố ẩn danh (phá vỡ liên kết giữa người gửi và người nhận) và quyền riêng tư (một phần mở rộng được đề xuất cho đề xuất hiện tại sẽ cho phép người dùng che giấu số tiền gửi và rút).*

Tổng quan về EIP-7503: Lỗ sâu không có kiến thức

Ở cấp độ cao, EIP-7503 hoạt động như sau:

1. Người dùng “đốt” ETH bằng cách gửi nó đến một địa chỉ có số dư không thể chi tiêu

Một địa chỉ không thể chi tiêu nếu không ai có quyền truy cập vào khóa riêng cần thiết để ký một giao dịch (hợp lệ) chi tiêu từ số dư. Điều này tương tự như việc gửi tiền đến địa chỉ số không : tài khoản không có khóa riêng, khiến bất kỳ tài sản nào nhận được đều không thể hủy ngang hoặc "bị đốt cháy".

Địa chỉ số không là tài khoản giàu có nhất trong Ethereum với hơn 280 triệu đô la tiền nắm giữ token. Ngoại trừ một số ít người dùng không may gửi tiền đến địa chỉ số không một cách tình cờ, phần lớn người dùng gửi token đến địa chỉ số không đều đang tạo hợp đồng (yêu cầu đặt địa chỉ số không làm người nhận) hoặc cố tình đưa những token đó ra khỏi lưu thông.

Tiêu chuẩn token ERC-20 ban đầu không chỉ định các chức năng để giảm nguồn cung token, điều này có nghĩa là các token cũ hơn như WETH (Ether được gói) không có cách nào đảm bảo rằng người dùng rút tài sản được gói ra khỏi lưu thông trước khi rút khoản tiền gửi ban đầu. Tuy nhiên, việc gửi token WETH đến địa chỉ số không khiến chúng không thể chi tiêu được và mô phỏng việc giảm nguồn cung WETH đang lưu thông mỗi khi ETH được rút khỏi hợp đồng gói WETH. Nếu bạn tự hỏi làm thế nào WETH duy trì tỷ lệ 1:1 với ETH gốc, thì đây là câu trả lời dành cho bạn.

EIP-7503 sử dụng một cơ chế tương tự để cho phép người dùng đốt ETH và đúc token vào một địa chỉ khác trên Ethereum với một thay đổi nhỏ. Thay vì yêu cầu người dùng gửi tiền đến một địa chỉ đốt duy nhất, EIP-7503 yêu cầu người dùng tạo một địa chỉ đốt duy nhất cho mọi giao dịch trước khi đúc ETH vào một địa chỉ khác.

2. Người dùng tạo bằng chứng đốt riêng tư hoặc “biên lai đốt” chứng minh rằng họ đã đốt một số lượng ETH nhất định trong giao dịch trước đó bằng cách gửi đến địa chỉ đốt

Gửi tiền đến một địa chỉ ghi (được tạo theo thông số kỹ thuật EIP-7503) tương đương với việc ném tiền mặt vào một lỗ sâu—không bao giờ có thể lấy lại được. Nhưng bạn có thể chứng minh kiến thức về thứ gì đó đã được gửi đến lỗ sâu bằng cách sử dụng ZK-SNARK ( Zero - K nowledge Succinct A rgument of K nowledge); do đó có thuật ngữ “lỗ sâu không kiến thức”.

Bằng chứng ghi là riêng tư vì người dùng chỉ phải chứng minh rằng họ đã gửi token đến một địa chỉ không thể chi tiêu A mà không tiết lộ A dưới dạng văn bản thuần túy. Việc tạo bằng chứng ghi đòi hỏi phải chứng minh rằng địa chỉ ghi thực sự không thể chi tiêu. Tại sao? Yêu cầu người dùng ghi ETH gốc trước khi đúc token ETH mới vào địa chỉ người nhận đảm bảo tính ngang bằng (về giá trị và khả năng thay thế) của cả hai loại tài sản, nếu sau này người dùng có thể rút tiền từ địa chỉ ghi, thì tỷ lệ chốt 1:1 giữa ETH gốc và token ETH đã đúc sẽ không còn tồn tại.

3. Người dùng đúc token ETH bằng cách gửi bằng chứng đốt riêng tư đến một nút đầy đủ để ghi có cho người dùng một số tiền tương đương với khoản tiền gửi được chuyển đến địa chỉ đốt

EIP-7503 giới thiệu một loại giao dịch mới trong EVM (Máy ảo Ethereum) chấp nhận bằng chứng ghi và người nhận làm đầu vào và đúc token ETH mới vào địa chỉ gửi nếu bằng chứng được xác minh thành công. Để ngăn chặn việc đúc ETH hai lần cho cùng một giao dịch ghi, một giá trị "nullifier" đặc biệt được đính kèm vào mọi bằng chứng ghi để theo dõi việc sử dụng địa chỉ.

Nếu ETH được gửi đến một địa chỉ không thể chi tiêu được đúc lại thành công, trình hủy sẽ ngăn người dùng không trung thực tạo ra bằng chứng đốt mới hợp lệ cho các khoản tiền đã gửi trước đó đến địa chỉ đó (tức là các cuộc tấn công đúc lại hai lần). Quan trọng là trình hủy xác định một địa chỉ đã sử dụng mà không làm rò rỉ thông tin về địa chỉ đó dưới dạng văn bản thuần túy.

Với phần giới thiệu cấp cao đó, giờ đây chúng ta có thể đi sâu vào các chi tiết cấp thấp về việc triển khai EIP-7503. Các phần tiếp theo sẽ thảo luận về các chi tiết chính của việc triển khai EIP-7503 như:

• Tạo địa chỉ không thể chi tiêu
• Tạo ra các bằng chứng ghi chép riêng tư
• Xác minh bằng chứng ghi chép riêng tư
• Đúc ETH cho người nhận chuyển nhượng riêng tư

Tạo địa chỉ không thể chi tiêu

Địa chỉ Ethereum thông thường là 20 byte đầu tiên của hàm băm Keccak256 của khóa công khai được tạo từ khóa riêng của tài khoản (khóa riêng là số nguyên được tạo từ cụm từ gợi nhớ hoặc cụm từ hạt giống). Cả khóa riêng và khóa công khai đều được tạo bằng Thuật toán chữ ký số Elliptic Curve (ECDSA). ECDSA là một chủ đề phức tạp (“phức tạp” là cách nói giảm nói tránh ưa thích của tôi cho “có nhiều toán học”), nhưng sau đây là một số tài nguyên—được xếp hạng từ người mới bắt đầu đến chuyên gia về chủ đề này:

• Một (Tương đối dễ hiểu) Sách nhập môn về mật mã đường cong Elliptic (Blog của Cloudflare)
• Thuật toán chữ ký số đường cong Elliptic (Wikipedia)
• Thuật toán chữ ký số đường cong Elliptic (Wiki Bitcoin)
• ECDSA: Chữ ký đường cong Elliptic (Mật mã thực tế dành cho nhà phát triển)

Khóa công khai được tạo ra bằng cách nhân khóa riêng (gọi là khóa bí mật hoặc viết tắt là s ) với giá trị "trình tạo" đặc biệt G để tạo ra giá trị mới có dạng pubKey = privKey * G Địa chỉ được tạo ra bằng cách chạy khóa công khai thông qua hàm băm Keccak256 và lấy 20 byte đầu tiên của chuỗi băm. Trong ký hiệu toán học giả, phép toán trông như sau: A = K(s * G) , trong đó A là địa chỉ, s là khóa bí mật hoặc khóa riêng và G là điểm trình tạo trên đường cong elliptic.

Địa chỉ, khóa công khai và khóa riêng có mục đích rất khác nhau:

• Địa chỉ được chia sẻ công khai và xác định tài khoản nhận tiền chuyển trong giao dịch.
• Khóa riêng được sử dụng để ký một thông điệp hướng dẫn mạng chuyển mã thông báo ra khỏi số dư của một địa chỉ và phải được giữ bí mật.
• Khóa công khai cho phép xác minh rằng chữ ký của giao dịch được tạo bởi khóa riêng tương ứng.

Mục cuối cùng trong danh sách chỉ ra một chi tiết tinh tế: chỉ có thể chi tiêu tiền được gửi đến một địa chỉ nếu bạn kiểm soát được khóa riêng tư—tức là bạn biết khóa riêng tư được sử dụng để tạo khóa công khai, từ đó địa chỉ được lấy ra. Nếu bạn không biết khóa riêng tư cho một địa chỉ hoặc khóa riêng tư được người khác kiểm soát, bạn không thể chi tiêu tiền từ địa chỉ đó.

Làm sao chúng ta biết được số dư của một địa chỉ A là không thể chi tiêu? Chúng ta có thể bắt đầu bằng cách chọn ngẫu nhiên một giá trị 20 byte ngẫu nhiên cho A và tận dụng một thuộc tính đặc biệt của các hàm băm mật mã** được gọi là khả năng chống ảnh trước . Nói một cách đơn giản, khả năng chống ảnh trước có nghĩa là chúng ta không thể tìm thấy giá trị x sao cho H(x) (băm của x ) giống với A nếu A được chọn ngẫu nhiên. Trong ký hiệu toán học giả, tuyên bố này có dạng: H(x) ≠ A

A là ảnh của hàm băm (đầu ra của hàm băm) và x là ảnh trước của hàm băm (đầu vào của hàm băm). Việc tìm giá trị x cho H(x) = A rất khó do (a) số lượng lớn các số nguyên có thể có (b) cách các đầu vào được thao tác bởi hàm băm để tạo ra đầu ra. Do đó, cách duy nhất bạn có thể "đoán" được giá trị x tạo ra A là nếu bạn có một lượng lớn sức mạnh tính toán và đủ thời gian để thực hiện một số lượng lớn các phép tính để tìm H(x) = A

Mặc dù đây không phải là lớp học Mật mã học 101 của bạn, nhưng lời giải thích trước đó nắm bắt được một thuộc tính quan trọng của các hệ thống mật mã hiện đại. Thuộc tính kháng ảnh trước của các hàm băm cũng đóng vai trò quan trọng trong EIP-7503: nếu A là giá trị ngẫu nhiên 20 byte, chúng tôi có sự tin tưởng hợp lý rằng người dùng không thể suy ra khóa riêng s không có cách nào để chi tiền từ địa chỉ. Nghĩa là, không thể tính toán A = H(h(s * G) , trong đó A là địa chỉ ghi, s là khóa riêng hoặc bí mật và G là điểm tạo (lưu ý nhỏ: k(s * G) tương đương với x từ đoạn trước).

Nhưng, chiến lược này không hoàn toàn chắc chắn. Ví dụ, làm sao chúng ta có thể xác định rằng A thực sự là ngẫu nhiên và không phải là kết quả của việc tính toán s * G ? Nếu người dùng chọn A một cách độc lập, chúng ta cần tin tưởng người dùng đó hoặc xây dựng các quy trình phức tạp để xác minh rằng A được chọn ngẫu nhiên; nếu chúng ta chọn A , chúng ta không cần tin tưởng người dùng—nhưng có một xác suất không thể bỏ qua là ai đó có thể may mắn và đoán đúng x . Vì x = s * G , kiến thức này có thể cho phép người dùng suy ra khóa riêng s và chi tiêu từ địa chỉ được cho là không thể chi tiêu.

Điều này rõ ràng là không tối ưu và làm nổi bật nhu cầu về một cơ chế an toàn hơn để tạo ra các địa chỉ không thể chi tiêu. May mắn thay, các hàm băm mật mã có một thuộc tính khác mà chúng ta có thể khai thác: khả năng chống va chạm . Nói một cách đơn giản, khả năng chống va chạm có nghĩa là bạn không thể tìm thấy H(x) = H(y) , trong đó x và y là các đầu vào khác nhau—tức là, phép tính băm cho các giá trị đầu vào khác nhau không thể “va chạm” và tạo ra cùng một kết quả.

Tính chống va chạm rất quan trọng để ngăn ngừa giả mạo (cùng với những thứ khác): hai người băm hai đầu vào khác nhau sẽ luôn có các chuỗi băm khác nhau và một người không thể tuyên bố sở hữu đầu vào mà chỉ người kia biết. Một phiên bản khác của tính chống va chạm là bạn không thể tìm thấy H1(x) = H2(x) , trong đó H1 và H2 thuộc các họ hàm băm khác nhau. Nói cách khác, phép tính băm của x sử dụng các thuật toán băm khác nhau không thể "va chạm" và đưa ra cùng một đầu ra.

Để hiểu tại sao điều này có thể xảy ra, tiếp theo chúng ta sẽ đưa ra một ví dụ giả định để giải thích cách thức hoạt động của hàm băm.

Interlude: Hàm băm mật mã cho người mới bắt đầu

Chúng tôi sẽ sử dụng một ví dụ được tạo ra để giải thích cách thức hoạt động của hàm băm mật mã và cách các thuộc tính quan trọng như khả năng chống va chạm và khả năng chống lại các cuộc tấn công tiền ảnh được đảm bảo. Tuy nhiên, lời giải thích này đơn giản hóa quá mức một số khái niệm vì mục đích ngắn gọn và dễ tiếp cận (hãy đọc một bài báo về hàm băm nếu bạn là một nhà mật mã học đầy tham vọng):

Alice, Bob, Cheryl và Max thuộc về các đảng phái chính trị đối địch: Alice và Bob là thành viên của Đảng Xanh, trong khi Cheryl và Max thuộc về Đảng Đỏ. Những người trung thành với Đảng Xanh và Đảng Đỏ muốn chia sẻ thông tin giữa họ mà không tiết lộ thông tin nhạy cảm cho các thành viên của đảng đối địch và tự đưa ra các mã khác nhau để mã hóa tin nhắn.

Mã của Blue Party được gọi là thuật toán Double Letter, trong khi Red Party sử dụng một biến thể gọi là Thuật toán Triple Letter. Mã này rất đơn giản: chúng ta thay thế chữ cái bằng số khi viết tin nhắn—mỗi số trong chuỗi tin nhắn tham chiếu đến một chữ cái ở một vị trí cụ thể của bảng chữ cái. Bit "mã hóa" xuất phát từ cách chúng ta chọn số để biểu diễn chữ cái:

• Trong mã “Double Letter” của Blue Party, chúng ta chia mỗi số cho hai và sử dụng số kết quả (n) để tìm chữ cái ở vị trí thứ n của bảng chữ cái. Ví dụ, chúng ta có thể mã hóa “BOY” thành 4-30-50 : 4/2 = 2 (“B” là chữ cái thứ 2 của bảng chữ cái); 30/2 = 15 (“O” là chữ cái thứ 15 của bảng chữ cái); 50/2 là 25 (“Y” là chữ cái thứ 25 của bảng chữ cái).
• Trong mã “Triple Letter” của Red Party, chúng ta chia mỗi số cho ba và sử dụng số kết quả (n) để tìm chữ cái ở vị trí thứ n của bảng chữ cái. Ví dụ, chúng ta có thể mã hóa “BOY” thành 6-45-=75 : 6/3 = 2 (“B” là chữ cái thứ 2 của bảng chữ cái); 45/3 = 15 (“O” là chữ cái thứ 15 của bảng chữ cái); 75/3 = 25 (“Y” là chữ cái thứ 25 của bảng chữ cái).

Ví dụ này sử dụng mã hóa cho cùng một thông điệp, nhưng chúng ta có thể mong đợi rằng những người của Đảng Xanh và Đảng Đỏ sẽ trao đổi những thông điệp khác nhau trong thực tế (ví dụ: "Max là một thằng ngốc" (Alice → Bob) và "Những thành viên của Đảng Xanh là những kẻ thua cuộc" (Cheryl → Max), v.v.). Tuy nhiên, việc mã hóa cùng một thông điệp bằng các mã khác nhau rất hữu ích để giải thích khả năng chống va chạm trong các hàm băm mật mã:

Khi “BOY” được mã hóa bằng thuật toán “Double Letter” của Blue Party và thuật toán “Triple Letter” của Red Party, kết quả rất khác nhau (lần lượt là 4-30-50 và 6-45-75 ). Một thành viên của Blue Party không thể tạo ra 6-45-75 , trừ khi sử dụng thuật toán mã hóa của Red Party; cũng như một thành viên của Red Party không thể tạo ra 4-30-50 dưới dạng chuỗi tin nhắn, trừ khi sử dụng thuật toán mã hóa của Blue Party. Vì mỗi bên đều bảo vệ thông tin chi tiết của thuật toán mã hóa, chúng ta biết rằng một thành viên của bên đối thủ không thể giải mã một tin nhắn không dành cho họ.

Các hàm băm mật mã khác với các thuật toán mã hóa: các hàm băm là một chiều và không có cách nào để suy ra đầu vào từ đầu ra, trong khi các thuật toán mã hóa như các thuật toán trong ví dụ có một khóa để giải mã các đầu vào thành hàm mã hóa. Nhưng các hàm băm và các thuật toán mã hóa có điểm tương đồng, đặc biệt là trong lĩnh vực chống va chạm. Giống như chúng ta không thể tìm thấy cùng một đầu ra (một thông điệp được mã hóa) cho một đầu vào duy nhất khi sử dụng các thuật toán mã hóa khác nhau, chúng ta không thể tìm thấy cùng một đầu ra (một hàm băm) cho một đầu vào duy nhất khi sử dụng các hàm băm khác nhau.

Chúng ta có thể khai thác khả năng chống va chạm của các hàm băm để tạo ra các địa chỉ không thể chi tiêu được chứng minh để đốt tài sản theo yêu cầu của EIP-7503. Đầu tiên, chúng tôi yêu cầu người dùng chọn một giá trị bí mật s (khóa riêng cho tài khoản Ethereum), tính toán hàm băm Keccak256 của s * G để suy ra khóa công khai và băm khóa công khai để suy ra địa chỉ A. Sau đó, chúng tôi yêu cầu người dùng tạo một địa chỉ B mới bằng cách băm giá trị bí mật s với một hàm băm khác được ký hiệu là H và lấy 20 byte đầu tiên của đầu ra làm địa chỉ.

Mục tiêu của chúng ta? Chúng ta muốn kết thúc với K(x) ≠ H(x) , trong đó K biểu diễn hàm băm Keccak256 và H biểu diễn hàm băm từ một họ hàm băm khác. Vì lý do hiệu suất, chúng ta muốn H “thân thiện với ZK” (tức là, việc xác minh kết quả của H(x) bên trong mạch phải rẻ và nhanh).

Chúng ta không thể biết khóa công khai cho B vì địa chỉ được tạo ngẫu nhiên thay vì tính toán hàm băm Keccak256 của s * G (khóa riêng nhân với trình tạo), điều đó có nghĩa là khóa riêng cho B cũng không thể biết được. Nếu chúng ta không biết khóa riêng cho B , chúng ta không thể tạo chữ ký hợp lệ cho một thông điệp chi tiêu số dư của B. Với quy trình ngẫu nhiên có thể chứng minh được để tạo địa chỉ không thể chi tiêu, giờ đây chúng ta có cách để người dùng đốt ETH trước khi đúc lại tài sản.

Tạo bằng chứng ghi chép riêng tư

Làm sao chúng ta chứng minh được rằng một người dùng cụ thể đã gửi ETH đến một địa chỉ không thể chi tiêu và địa chỉ không thể chi tiêu đó được người dùng đó tạo ra? Kiểm tra đầu tiên là cần thiết để tránh việc đúc ETH gian lận (chúng tôi không đúc token ETH mới trừ khi chúng tôi có bằng chứng cho thấy người dùng đã đốt ETH trước đó), nhưng kiểm tra thứ hai cũng quan trọng: chúng tôi cần biết địa chỉ được người dùng tạo ra—nếu không, chúng tôi sẽ yêu cầu một thông tin (ví dụ: hàm băm của giao dịch đốt) để xác nhận rằng người dùng không cố gắng yêu cầu tiền gửi của người khác.

Vì chúng tôi muốn tránh rò rỉ thông tin về sự tham gia của người dùng vào giao thức bảo mật, chúng tôi cho phép người dùng thay vào đó tạo bằng chứng không kiến thức chứng minh kiến thức về s (giá trị bí mật được băm để suy ra địa chỉ ghi) mà không công khai s . Bằng chứng không kiến thức khẳng định kiến thức của người dùng về địa chỉ B được suy ra từ kết quả của H(s) : vì s được chọn một cách bí mật, nên người khác không thể tính toán một giá trị H(x) khác sao cho H(s) = H(s) . Điều này là do tính chất chống va chạm của các hàm băm được mô tả trước đó.

Ẩn s ngăn chặn những kẻ xấu chuộc lại tiền gửi của người dùng bằng cách gửi bằng chứng xác nhận kiến thức về bí mật s (được sử dụng để tạo địa chỉ không thể chi tiêu) cho trình xác minh EIP-7503. Phần này sẽ bỏ qua lý do tại sao chúng ta có thể tạo bằng chứng không kiến thức chứng minh H(s) = A mà không yêu cầu trình xác minh tính toán H(s) độc lập. Nhưng bạn có thể đọc Chương trình số học bậc hai của Vitalik: Zero To Hero và bài viết của tôi về ZK-EVM để biết thêm thông tin cơ bản về việc sử dụng ZK-SNARK để chứng minh tính hợp lệ của phép tính mà không tiết lộ đầu vào.

Chúng tôi mô tả bằng chứng không kiến thức xác thực việc chuyển tiền của người dùng đến một địa chỉ không thể chi tiêu (hay còn gọi là địa chỉ burn ) là “bằng chứng burn” hoặc “biên lai burn”. Bằng chứng burn chứng minh các tuyên bố sau:

• Người dùng biết một địa chỉ A và giá trị bí mật s đã được băm để suy ra A (tức là H(s) = A ). Điều này kiểm tra xem địa chỉ có thể chi tiêu được hay không bằng cách xác nhận A là kết quả của việc băm s bằng hàm băm (thân thiện với ZK) khác với hàm băm Keccak256 được sử dụng để tạo các địa chỉ Ethereum có thể chi tiêu được.

• Địa chỉ A có số dư ETH dương bằng hoặc lớn hơn b ( b ≥ b' ). Điều này kiểm tra xem số tiền mà người dùng đang cố gắng đúc vào địa chỉ nhận có giống với số tiền được gửi vào địa chỉ không thể chi tiêu hay không.

  
  

Trong khi chứng minh #1 tương đối đơn giản, chứng minh #2 đòi hỏi phải khẳng định một số điều nhất định về trạng thái của Ethereum. Cụ thể, chúng ta phải chứng minh rằng (a) địa chỉ không thể chi tiêu tồn tại trong trie trạng thái Ethereum chuẩn và (b) số dư được yêu cầu của địa chỉ không thể chi tiêu khớp với số dư được liên kết với địa chỉ trong trie trạng thái. Điều này đòi hỏi phải truyền một bằng chứng Merkle cho địa chỉ A làm đầu vào cho mạch tạo ra bằng chứng về việc đốt.

Bằng chứng Merkle bao gồm các lá của Merkle Patricia Trie (MPT) cần thiết để tính toán đường dẫn từ lá mà chúng ta đang cố gắng chứng minh (địa chỉ A ) đến gốc của Merkle trie (gốc trie cũng là một phần của bằng chứng Merkle). Chúng ta cần bằng chứng cho thấy gốc trạng thái—được sử dụng để xác minh bằng chứng Merkle—cũng là chuẩn, vì vậy chúng ta yêu cầu người dùng chuyển một tiêu đề khối B làm đầu vào bổ sung cho mạch. Bộ thông tin này cho phép trình xác minh bị hạn chế về tài nguyên xác minh hiệu quả việc bao gồm địa chỉ A trong trạng thái trie và xác thực số dư b của A.

Lưu ý *: Đặc tả EIP-7503 khuyến nghị nên suy ra bằng chứng Merkle cần thiết để chứng minh việc bao gồm địa chỉ ghi trong trạng thái trie và xác thực số dư của địa chỉ thông qua phương pháp JSON-RPC eth_getProof được giới thiệu trong EIP-1186 .

Tạo ra các bộ hủy cho địa chỉ

Một đầu vào khác cho mạch ZK-SNARK tạo ra bằng chứng gửi tiền vào một địa chỉ không thể chi tiêu là một nullifier . Nullifier là một giá trị ngăn người dùng sử dụng cùng một bằng chứng đốt để đúc ETH hai lần . Nếu không có nullifier, không có gì ngăn cản người dùng thông minh sử dụng lại bằng chứng đốt để rút ETH nhiều lần: theo quan điểm của một nút xử lý các giao dịch chuyển tiền riêng tư EIP-7503, những lần rút tiền này là hợp lệ vì số dư của địa chỉ không thể chi tiêu không bao giờ giảm (nó chỉ có thể tăng).

Nullifier được truyền làm đầu vào cho mạch chứng minh ZK-SNARK để một proof-of-burn trở nên không hợp lệ sau khi được xác minh thành công. Chúng tôi đạt được tính chất này bằng cách trích xuất nullifier (đã sử dụng) từ một proof và lưu trữ nó trong một Sparse Merkle Tree (SMT). Không giống như các cây Merkle thông thường có thể chứng minh hiệu quả việc bao gồm các phần tử, Sparse Merkle Tree hiệu quả trong việc chứng minh việc không bao gồm các phần tử. Việc thảo luận về SMT nằm ngoài phạm vi, nhưng bài viết được liên kết trước đó cung cấp một bản tổng quan tuyệt vời cho những độc giả quan tâm.

SMT hữu ích trong trường hợp này vì quy trình xác minh ZK-SNARK chỉ phải kiểm tra xem SMT có loại trừ nullifier được đính kèm vào bằng chứng mới được gửi hay không. Nếu nullifier không có trong Cây Merkle thưa thớt, chúng tôi biết rằng người dùng chưa sử dụng bằng chứng đốt này trước đó và đang rút một khoản tiền gửi mới có thể chứng minh được. Chúng tôi thêm nullifier đã sử dụng vào SMT để theo dõi địa chỉ đốt được sử dụng để đúc lại ETH mà không công khai địa chỉ đốt.

Điều gì sẽ xảy ra nếu chúng ta chỉ lưu trữ các địa chỉ ghi trong cây Merkle và kiểm tra xem địa chỉ từ bằng chứng ghi mới có phải là một phần của cây đó không khi xử lý lệnh rút tiền mới?

Sử dụng địa chỉ burn đơn giản làm trình hủy cho phép người quan sát bên ngoài có khả năng phát hiện người gửi giao dịch burn bằng cách kiểm tra chéo lịch sử giao dịch của địa chỉ với danh sách các địa chỉ burn được lưu trữ trên chuỗi. Khi địa chỉ burn (không thể tránh khỏi) xuất hiện dưới dạng người nhận trong một trong các giao dịch do người gửi khởi tạo, bất kỳ ai cũng có thể chứng minh người kiểm soát tài khoản đã burn và đúc lại ETH.

Sử dụng hàm băm của địa chỉ burn (không thể chi tiêu) khiến việc biết được số tiền đã chuyển một cách riêng tư trở nên khó khăn, nhưng không phải là không khả thi. Điều này đòi hỏi một cuộc tấn công brute-force tính toán hàm băm của mọi địa chỉ Ethereum hiện đang tồn tại cho đến khi một trong các hàm băm khớp với một nullifier được lưu trữ trong SMT. Khi hình ảnh trước của hàm băm nullifier được phát hiện (tức là địa chỉ không thể chi tiêu), các bước được mô tả trước đó có thể được thực hiện để theo dõi tài khoản đã gửi tiền đến địa chỉ không thể chi tiêu đang được đề cập.

Chúng ta có thể giải quyết vấn đề này bằng cách tìm một cơ chế an toàn hơn để tạo ra các bộ hủy. Chiến lược được áp dụng trong đặc tả EIP-7503 hiện tại là sử dụng cùng một hàm băm (thân thiện với ZK) để tạo ra một bộ hủy N bằng cách băm địa chỉ ghi với giá trị bí mật s . Trong ký hiệu toán học giả, điều này trông giống như sau: N = H(A,s) , trong đó A là địa chỉ không thể chi tiêu và s là giá trị bí mật tạo ra A ban đầu.

Giá trị bí mật s được mô tả như một salt trong trường hợp này. Giá trị salt này về cơ bản làm tăng độ khó của việc trích xuất thông tin về địa chỉ burn từ các nullifier: nếu s được biết, người quan sát có thể thực hiện một cuộc tấn công brute-force và chạy tất cả các kết hợp có thể của hash(burnaddress,secret) tạo ra một nullifier N được lưu trữ trên chuỗi. Nhưng s được người dùng giữ bí mật, về cơ bản loại bỏ khả năng tìm thấy địa chỉ burn tương ứng cho một nullifier đã sử dụng.

Xác minh bằng chứng ghi chép riêng tư

Bây giờ chúng ta đã biết những tuyên bố mà bằng chứng ghi đang cố gắng chứng minh, chúng ta có một ý tưởng khá rõ ràng về cách xác minh bằng chứng hoạt động. Đối với tuyên bố đầu tiên ( h(s) = A ), trình xác minh cần "hiểu" logic của hàm băm được sử dụng để tạo địa chỉ A —do đó, nó biết rằng H(s) thực sự bằng A . Mã hóa logic của hàm băm trong mạch xác minh cũng thực thi yêu cầu rằng A không thể được tạo bằng hàm băm Keccak256.

Đối với câu lệnh thứ hai ( A có số dư dương b của ETH), người xác minh phải xác minh bằng chứng Merkle chứng minh việc bao gồm A trong trạng thái của Ethereum và xác thực dữ liệu của tài khoản. Người xác minh mạch cũng kiểm tra xem tiêu đề khối B có phải từ chuỗi chuẩn hay không—trước khi trích xuất gốc trạng thái—bằng cách gọi mã lệnh BLOCKHASH với đầu vào block.blockHash(blockNumber) , trong đó blockNumber tham chiếu đến tiêu đề khối B. Nếu B là một phần của chuỗi Ethereum chuẩn, thì hash do mã lệnh BLOCKHASH trả về phải khớp với hàm băm của tiêu đề khối B.

Ngoài ra, mạch xác minh xác thực nullifier có trong bằng chứng ZK-SNARK của người dùng và xác nhận rằng nullifier chưa từng được sử dụng trước đó. Tính chống va chạm của các hàm băm đóng vai trò hỗ trợ ở đây bằng cách ngăn chặn các nỗ lực tạo ra hai hàm băm nullifier khác nhau N1 và N2 cho cùng một burn address <> secret value . Nếu người dùng có thể tạo ra các nullifier khác nhau cho cùng một địa chỉ, thì có thể đúc ETH hai lần—bất kể Cây Merkle thưa thớt có lưu trữ nullifier cho địa chỉ đó hay không.

Để đảm bảo các bằng chứng ghi có thể được xác minh bởi những người đề xuất khối, EIP-7503 đề xuất một sửa đổi cho EVM để triển khai xác minh hỗ trợ cho các bằng chứng ZK-SNARK. Các tác giả của EIP-7503 đã kiểm tra tính khả thi của việc triển khai xác minh bằng chứng ghi trong EVM bằng cách tạo phiên bản EVM hỗ trợ EIP7503 bằng cách sử dụng khuôn khổ Polaris EVM . Bạn có thể truy cập kho lưu trữ GitHub dành riêng cho dự án để biết thêm chi tiết về thiết kế của giao thức.

Đúc ETH vào địa chỉ người nhận

EIP-7503 giới thiệu một loại giao dịch mới, đúc ETH cho người dùng chứng minh thành công rằng họ đã gửi một số tiền cụ thể vào một địa chỉ không thể chi tiêu. Người gửi giao dịch gửi bằng chứng ZK-SNARK (cùng với một trình hủy) và mạng thực hiện chuyển đổi trạng thái để cập nhật số dư của địa chỉ rút tiền (sau khi xác minh bằng chứng đốt).

Mặc dù EIP-7503 cung cấp khả năng phủ nhận hợp lý, người dùng được khuyến khích tránh trả tiền cho các giao dịch đúc tiền bằng tiền từ cùng một địa chỉ đã gửi ETH đến địa chỉ đốt. Nếu Alice gửi ETH đến một địa chỉ không thể chi tiêu 0xm00la và sau đó gửi một giao dịch trả tiền cho cùng một lượng ETH để đúc vào một tài khoản riêng, Bob không cần phải là Jimmy Neutron để liên kết Alice với giao dịch đốt ban đầu.

Các phần trước không đề cập đến điều này, nhưng chúng tôi cần người dùng đưa địa chỉ B thứ hai (sẽ nhận ETH từ giao dịch đúc) làm đầu vào công khai cho mạch chứng minh ZK-SNARK. Điều này ngăn chặn các trường hợp ngoại lệ tiềm ẩn từ người dùng trung thực bị chạy trước trong khi các giao dịch đúc đang chờ trong mempool.

Hãy nhớ rằng trình xác minh không kiểm tra danh tính của địa chỉ gửi và cố tình tránh yêu cầu phải biết liệu cùng một địa chỉ đã đốt ETH cũng đang đổi ETH trong giao dịch đúc hay không. Điều này rất tuyệt vời về mặt quyền riêng tư vì nó có nghĩa là người dùng có thể đúc lại ETH bằng một địa chỉ mới được tạo—nhưng nó làm tăng nguy cơ bị tấn công trước. Vì bằng chứng mã hóa tất cả thông tin cần thiết để vượt qua xác minh (bao gồm cả kiến thức về giá trị bí mật s ), bất kỳ ai cũng có thể gửi một giao dịch đúc sao chép có cùng bằng chứng nhưng có địa chỉ khác để nhận ETH đã đúc.

May mắn thay, chúng ta có thể yêu cầu proof-of-burn tham chiếu đến địa chỉ rút tiền B và thực thi một quy tắc có dạng: "giao dịch đúc chỉ có thể đúc ETH vào địa chỉ được trích xuất từ proof-of-burn". Sự tương đương giữa địa chỉ được truyền dưới dạng đầu vào công khai cho mạch ZK-SNARK và địa chỉ được chỉ định trong giao dịch đúc được kiểm tra bởi trình xác minh. Theo cách đó, mọi người dùng đều chắc chắn rằng không ai có thể lấy giao dịch mang bằng chứng của họ từ mempool và đánh cắp khoản tiền rút của họ.

Tại sao lại là EIP-7503? Trường hợp chuyển tiền riêng tư trên Ethereum

Chuyển khoản và thanh toán riêng tư

EIP-7503 cung cấp một cách đơn giản cho người dùng Ethereum để chuyển tiền mà không (vô tình) tạo ra liên kết giữa địa chỉ gửi và nhận. Bạn có thể gửi ETH từ một ví đến một địa chỉ không thể chi tiêu mới được tạo và rút tiền đến một ví khác bằng cách cung cấp bằng chứng đốt và trình hủy để xác minh. Đối với người quan sát bên ngoài, không có mối tương quan nào giữa tài khoản đốt ETH và tài khoản đúc ETH.

Một trường hợp ngoại lệ có thể xuất hiện nếu người dùng đốt ETH trong một giao dịch và ngay lập tức đúc ETH vào một địa chỉ mới: một chuyên gia phân tích chuỗi có thể nhanh chóng nhận ra cùng một người phải kiểm soát cả hai địa chỉ. Tuy nhiên, EIP-7503 có một tính năng mạnh mẽ để ngăn chặn việc xóa ẩn danh: khả năng phủ nhận hợp lý . Sau đây là định nghĩa về khả năng phủ nhận hợp lý từ Political Dictionary :

Khả năng phủ nhận hợp lý là khả năng phủ nhận bất kỳ sự tham gia nào vào các hoạt động bất hợp pháp hoặc phi đạo đức, vì không có bằng chứng rõ ràng nào chứng minh sự tham gia. Việc thiếu bằng chứng khiến cho sự phủ nhận trở nên đáng tin cậy hoặc hợp lý. — Từ điển chính trị

Sự phủ nhận hợp lý bắt nguồn từ thế giới mờ ám của các hoạt động CIA, nơi các quan chức sẽ phủ nhận việc biết trước các hành động do cấp dưới thực hiện. Việc thiếu dấu vết giấy tờ—một hồ sơ sự kiện có thể truy cập công khai—có nghĩa là các quan chức cấp cao có thể từ chối các đặc vụ thực địa và tránh trách nhiệm đối với kết quả hành động của các đặc vụ (tránh thảm họa quan hệ công chúng lớn).

Khả năng phủ nhận hợp lý có ý nghĩa tương tự trong bối cảnh thực hiện chuyển tiền riêng tư bằng EIP-7503. Giả sử "ví chính" của bạn đốt 1,365 ETH và "ví phụ" của bạn đúc 1,365 ETH ngay sau đó. Nếu hoạt động của bạn thu hút sự chú ý của những thám tử quá háo hức trên chuỗi, bạn có thể chỉ cần tuyên bố rằng người khác đã đúc 1,365 ETH để làm cho nó trông giống như bạn đang hoàn thành một chuyển tiền riêng tư.

Và nếu bạn được hỏi một câu hỏi như: "Tại sao bạn lại gửi ETH đến một địa chỉ ghi mà không có ý định chuyển tiền một cách bí mật?" Bạn có thể khẳng định giao dịch đó xảy ra do nhầm lẫn—suy cho cùng, không ai có thể phủ nhận một lượng ETH khủng khiếp đã bị mất do mọi người đánh máy sai địa chỉ người nhận (kể cả tôi cũng mắc lỗi đó). Điều này đảo ngược toàn bộ cuộc trò chuyện vì, còn ai ngoài một cá nhân lạnh lùng sẽ không đồng cảm với việc mất một lượng lớn ETH?

Đây là một ví dụ khá tầm thường thể hiện tầm quan trọng của EIP-7503: khả năng phủ nhận hợp lý đảm bảo người dùng Ethereum thường xuyên có thể thực hiện chuyển khoản riêng tư mà không tiết lộ bất kỳ thông tin cụ thể nào có thể gợi ý sự tham gia vào giao thức bảo mật. Không giống như các giao thức bảo mật ở lớp ứng dụng, EIP-7503 tránh lưu trữ dấu vết giao dịch trên chuỗi và khiến việc liên kết các giao dịch đốt và đúc với danh tính trong thế giới thực trở nên khó khăn.

EIP-7503 không cung cấp tính ẩn danh và riêng tư hoàn toàn vì thông tin về việc chuyển tiền đến địa chỉ ghi—bao gồm cả số tiền được chuyển—được ghi lại trên chuỗi. Nhưng khả năng phá vỡ liên kết giữa địa chỉ gửi và nhận trong giao dịch khá mạnh mẽ và làm giảm mối lo ngại về việc sử dụng lại địa chỉ.

Thay vì sử dụng cùng một địa chỉ để nhận thanh toán, người dùng có thể tạo một địa chỉ đốt mới và yêu cầu gửi tiền đến địa chỉ này. Vì người dùng biết giá trị bí mật s , nên có thể tạo bằng chứng đốt hợp lệ chứng minh quyền kiểm soát đối với việc tạo địa chỉ đốt cho trình xác minh trên chuỗi và "rút" tiền gửi bằng cách đúc ETH vào một địa chỉ khác. Điều này khá giống với khái niệm tạo địa chỉ ẩn để nhận chuyển khoản và giảm khả năng liên kết các giao dịch khác nhau với cùng một thực thể.

Chúng ta có thể thấy cách chuyển giao riêng tư theo kiểu EIP7503 có thể có lợi trong các tình huống khác:

• Thương nhân : Bằng cách chấp nhận thanh toán tại các địa chỉ burn và sau đó đúc ETH vào các địa chỉ rút tiền không thể liên kết, thương nhân có thể tránh tiết lộ thông tin tài chính. Tính năng giao dịch riêng tư của EIP-7503 còn ngăn chặn những người quan sát bên ngoài lấy cắp thông tin chi tiết, chẳng hạn như số tiền thương nhân nhận được cho các sản phẩm hoặc quy mô cơ sở khách hàng của thương nhân.
• Người mua : Bằng cách thanh toán đến địa chỉ ghi do thương gia cung cấp (thay vì gửi đến địa chỉ có thể nhận dạng công khai của thương gia), người mua tránh được việc rò rỉ thông tin liên quan đến lịch sử mua hàng. Địa chỉ ghi không thể được liên kết với tài khoản "thực" của thương gia, cản trở nỗ lực tìm hiểu những gì bạn đã mua và từ ai.
• Hoạt động từ thiện : Các tổ chức từ thiện và chính trị có thể nhận tiền mà không cần ghi lại danh tính người gửi vĩnh viễn trên chuỗi. Cá nhân có thể quyên góp cho một số mục đích nhất định mà không làm ảnh hưởng đến danh tiếng công khai của họ.

EIP-7503 cũng có thể được sử dụng cho mục đích không liên quan đến quyền riêng tư :

1. Hiện tại, các sàn giao dịch tập trung (CEX) phải tạo một địa chỉ duy nhất để nhận tiền gửi từ người dùng và cần gửi các giao dịch chuyển số dư của mỗi địa chỉ đến một hoặc nhiều ví lạnh như một phần của quy trình bảo mật hoạt động. Với EIP-7503, một nhà điều hành CEX có thể tạo một địa chỉ ghi duy nhất để nhận tiền gửi từ một nhóm người dùng và tạo bằng chứng ghi để rút tất cả tiền gửi tích lũy trong địa chỉ ghi vào ví lạnh trong một giao dịch duy nhất. Việc giảm số lượng giao dịch cần thiết để hợp nhất tiền gửi CEX trong ví lạnh có lợi cho nhà điều hành CEX (giảm chi phí hoạt động) và mạng lưới (giảm số lượng giao dịch trên chuỗi).
2. Bất kỳ thực thể nào xử lý một lượng lớn thanh toán trên chuỗi đều có thể tận dụng EIP-7503 để cải thiện hiệu quả hoạt động—do đó, CEX không phải là bên hưởng lợi duy nhất. Các thương gia, tổ chức từ thiện và đường ray thanh toán gốc tiền điện tử là một số ví dụ về các tổ chức sử dụng EIP-7503 để giảm chi phí hoạt động bằng cách tập hợp các khoản tiền gửi vào các địa chỉ đốt và phân bổ chi phí giao dịch trên nhiều khoản tiền gửi. Khía cạnh này của EIP-7503 có tác dụng phụ mong muốn là tạo ra các động cơ tài chính để tham gia vào nhóm ẩn danh và tăng quyền riêng tư tổng thể cho các tài khoản thực hiện chuyển khoản riêng tư.

Cân bằng quyền riêng tư với tiện ích và tuân thủ quy định

EIP-7503 cung cấp một con đường đơn giản để bảo vệ quyền riêng tư của giao dịch trên Ethereum mà không cần phải sửa đổi nhiều giao thức. Đặc biệt, EIP-7503 sẽ cho phép Ethereum cung cấp quyền riêng tư cho giao dịch mà không gặp phải vấn đề khi đối đầu với các blockchain tập trung vào quyền riêng tư khác như Zcash và Monero.

Mặc dù tôi đã viết để bảo vệ các đồng tiền riêng tư trước đây , nhưng không cần phải nói nhiều để thấy rằng các đồng tiền riêng tư như ZEC (Zcash) và MNR (Monero) không thể đạt được mục tiêu đưa tiền phi tập trung, riêng tư và có thể sử dụng vào nền kinh tế toàn cầu. Với áp lực pháp lý buộc các sàn giao dịch phải hủy niêm yết các đồng tiền riêng tư, chủ sở hữu sẽ thấy ngày càng khó tận dụng được quyền riêng tư do Zcash, Monero và các giao thức khác được thiết kế rõ ràng để che giấu thông tin giao dịch trong bối cảnh thực tế cung cấp. Trích đoạn này từ bài viếtWhy Privacy Coins Haven't Taken Off của Haseeb Qureshi cung cấp phần giới thiệu hay về những thách thức mà các dự án riêng tư "cứng rắn" phải đối mặt hiện nay:

Tiền riêng tư luôn là mục tiêu đầu tiên của các cuộc điều tra về quy định. Khi các cơ quan quản lý được giao nhiệm vụ "đừng chỉ đứng đó, hãy làm gì đó", thì con quỷ dễ bị bắt nạt nhất chính là tiền riêng tư mờ ám. Về mặt quy định, chúng ta đã chứng kiến một loạt các vụ hủy niêm yết tiền riêng tư ở Hàn Quốc , Nhật Bản , Vương quốc Anh và Hoa Kỳ . Các chính phủ liên tục cố gắng thắt chặt vòng vây đối với tiền riêng tư (xem tại đây , tại đây và tại đây ).

Các nhóm vận động hành lang tiền điện tử đã phát triển lớn hơn; các nhóm bán lẻ lớn và nhiều tổ chức hiện sở hữu BTC và ETH. Nhưng rất ít tổ chức sẵn sàng bảo vệ các đồng tiền riêng tư. Thay vì để toàn bộ ngành công nghiệp bị vấy bẩn, nhiều tổ chức hài lòng để các đồng tiền riêng tư trở thành vật tế thần. — Haseeb Qureshi ( Tại sao các đồng tiền riêng tư chưa cất cánh )

EIP-7503 có vẻ như xuất hiện đúng vào thời điểm thích hợp trong quá trình tiến hóa của Ethereum: với nhiều người dùng hơn bất kỳ blockchain nào và rất nhiều khoản đầu tư của các tổ chức, Ethereum ít có khả năng phải chịu chung số phận như các dự án khác đã cố gắng cung cấp chức năng thanh toán riêng tư trong quá khứ. Một số sàn giao dịch có hạn chế giao dịch Ether nếu các token ETH do tư nhân đúc bắt đầu lưu hành không? Có thể. Nhưng hàng chục sàn giao dịch khác sẽ rất vui khi đảm nhận trách nhiệm đó—đây chính là những gì mà hiệu ứng mạng lưới mạnh mẽ trông như thế nào.

Tại sao tôi lại nói EIP-7503 đến đúng lúc? Có một thời điểm trong lịch sử Ethereum, khi mà việc hỗ trợ quyền riêng tư ở lớp cơ sở là điều mà mọi người đều cảm thấy nên được thực hiện ngay lập tức . Nhưng những người khác trong cộng đồng (một cách đúng đắn) đã chỉ ra những trường hợp tiềm ẩn liên quan đến việc quảng bá Ethereum như một "công nghệ bảo mật". Sau đây là những trích đoạn từ một chủ đề cũ trên diễn đàn Ethereum Magicians thảo luận về nhu cầu tăng cường quyền riêng tư trên Ethereum:

Trực giác của Griffith phần lớn là đúng trong những năm tiếp theo, với nhiều loại tiền điện tử mặc định bảo mật phải đối mặt với viễn cảnh trở thành loại tiền tệ ngoại vi chỉ được những người theo chủ nghĩa cypherpunk cứng rắn (một nhóm chiếm chưa đến 0,00001% dân số thế giới) sử dụng. So sánh, giá trị và tính phổ biến của Ether (ETH) chỉ tăng đến mức "hướng tới công nghệ bảo mật" bằng cách áp dụng EIP-7503 ít rủi ro hơn so với năm năm trước.

Nếu triển khai nâng cấp để hỗ trợ chuyển tiền riêng tư—có lẽ để tránh việc nắm bắt quy định ngược hoặc giảm thiểu sự phức tạp của lớp cơ sở. Một giải pháp thay thế phù hợp là chuyển giao trách nhiệm triển khai EIP-7503 cho Ethereum L2 và L3. Với lộ trình tập trung vào rollup của Ethereum, việc triển khai EIP-7503 trên rollup là hợp lý và vẫn bảo toàn mục tiêu bảo vệ quyền riêng tư trong Ethereum (ví dụ, tương tự như rollup triển khai ERC-4337 để trừu tượng hóa tài khoản gốc).

Cách tiếp cận này để triển khai EIP-7503 dễ dàng hơn vì mỗi chuỗi L2 đã có một hợp đồng cầu nối đúc ETH cho người dùng trên L2. Với cơ chế đúc token ETH tại chỗ, các rollup chỉ cần thêm các thành phần để lưu trữ các nullifier trên chuỗi và tạo/xác minh bằng chứng ghi để hỗ trợ chuyển giao riêng tư theo kiểu EIP7503. Một ví dụ về chuỗi Lớp 2 (L2) có kế hoạch tích hợp EIP-7503 vào cơ sở hạ tầng của nó là Taiko như được mô tả trong Yêu cầu bình luận (RFC) này.

Ở đây, chúng ta thấy rằng một giao thức như Taiko có thể cung cấp quyền riêng tư cho giao dịch—mà không cần thực hiện các giao dịch mở rộng với cơ sở hạ tầng của nó—bằng cách áp dụng EIP-7503. Điều này có lợi ích chính cho các nhóm giao thức không muốn xây dựng một L2 tập trung vào quyền riêng tư toàn diện (a là Aztec v2 ) nhưng muốn cung cấp khả năng không theo dõi và không liên kết cơ bản cho người dùng. Đề xuất của nhóm Nethermind về việc triển khai EIP-7503 trên Taiko rất đáng để đọc để có ý tưởng về cách EIP-7503 có thể được triển khai bởi một L2 Ethereum.

EIP-7503 cũng cân bằng nhu cầu về quyền riêng tư với việc tuân thủ quy định, phù hợp với mục tiêu của phong trào “quyền riêng tư 2.0” của Ethereum: bảo vệ quyền riêng tư của người dùng, đồng thời đảm bảo những kẻ xấu không thể khai thác cơ sở hạ tầng quyền riêng tư cho mục đích xấu. Theo một triển khai của EIP-7503 được mô tả trên Ethereum Research, các bản tổng hợp áp dụng EIP-7503 có thể ngăn chặn sự cố Tornado Cash lặp lại bằng cách chọn lọc chặn những tin tặc và kẻ lừa đảo đã biết khỏi việc rửa tiền bằng cách chuyển tiền riêng tư.

Để đạt được thuộc tính này, chúng tôi yêu cầu người dùng chuyển danh sách các địa chỉ bị liệt kê đen ( blacklist[] ) làm đầu vào cho mạch tạo bằng chứng ZK-SNARK về giao dịch đốt. Mạch kiểm tra xem địa chỉ của người dùng nhận ETH có phải là một phần của các địa chỉ được lưu trữ trong danh sách đen khi tạo bằng chứng đốt hay không—việc chuyển đến địa chỉ bị liệt kê đen sẽ tự động thất bại vì mạch không thể tạo bằng chứng nếu đầu vào không đáp ứng được tất cả các điều kiện hợp lệ.

Việc duy trì sổ đăng ký các địa chỉ bị đưa vào danh sách đen sẽ tạo ra một mức độ tập trung hóa và các vectơ kiểm duyệt tiềm ẩn. Nhưng nếu chúng ta chấp nhận rằng việc tự điều chỉnh từ dưới lên do cộng đồng thúc đẩy tốt hơn là việc điều chỉnh tập trung từ trên xuống, thì những tiện ích như vậy để đảm bảo tuân thủ các quy định có thể là cần thiết.

Quản lý bảng lương riêng cho các tổ chức trong chuỗi

Tính minh bạch là một trong những nền tảng của DAO (Tổ chức tự trị phi tập trung): không giống như các tổ chức truyền thống, nơi các chi tiết về thù lao tài chính được che giấu khỏi các nhà đầu tư và bên liên quan, các khoản thanh toán của người đóng góp trong DAO được ghi lại công khai trên chuỗi. Đường dẫn kiểm toán trên chuỗi này cung cấp một lượng trách nhiệm giải trình đáng kể và làm giảm đáng kể sự bất đối xứng thông tin có thể dẫn đến việc quản lý tài chính sai trái của các quản trị viên DAO.

Tuy nhiên, DAO chắc chắn sẽ trưởng thành và bắt đầu hoạt động như các tập đoàn (dù tốt hay xấu)—tại thời điểm đó, những thứ như giữ bí mật chi tiết về tiền thù lao của người đóng góp có thể trở nên mong muốn. EIP-7503 cung cấp cơ sở hạ tầng mà DAO cần để bắt đầu thực hiện các khoản thanh toán riêng tư cho những người đóng góp cốt lõi, nhà phát triển và nhà thầu độc lập. Trong mọi trường hợp, người nhận chỉ cần tạo một địa chỉ ghi để nhận thanh toán và rút tiền về địa chỉ tùy chọn của mình.

Các thành viên DAO sẽ giữ cho các quản trị viên chịu trách nhiệm như thế nào nếu các khoản thanh toán của nhà thầu/người đóng góp tư nhân được thực hiện? Điều này phụ thuộc vào mức độ riêng tư mà DAO đang tìm kiếm và mức độ che giấu mà các thành viên DAO có thể chịu đựng được. Ví dụ, để chứng minh rằng AliceDAO thực sự đã trả 20 ETH cho Alice cho công việc của DAO và số tiền đó không được sử dụng cho các mục đích thay thế, Alice có thể cung cấp bằng chứng cho thấy cô ấy đã tạo ra địa chỉ không thể chi tiêu.

Ví dụ, Alice có thể tiết lộ khóa riêng s được sử dụng để tạo địa chỉ không thể chi tiêu. Vì địa chỉ không thể chi tiêu bị vô hiệu hóa sau hoạt động đúc, Alice có thể tiết lộ s mà không phải chịu bất kỳ rủi ro nào. Một bên xác minh thứ ba sẽ lấy được địa chỉ không thể chi tiêu bằng cách băm s bằng cùng một hàm băm mật mã mà Alice đã sử dụng ban đầu và so sánh cả hai địa chỉ. Nếu chúng khớp nhau, bên xác minh biết Alice đã truy cập vào địa chỉ ghi tại thời điểm giao dịch được gửi. Tuy nhiên, bên xác minh không biết Alice đã sử dụng địa chỉ nào để nhận mã thông báo ETH đã đúc (bảo vệ quyền riêng tư của Alice ở một mức độ nào đó).

Giảm sự phụ thuộc vào các máy trộn tiền điện tử

Sử dụng một máy trộn như Tornado Cash để phá vỡ liên kết giữa các địa chỉ ví là vấn đề vì nó tạo ra một hình thức tội lỗi do liên kết . Hãy nhớ rằng máy trộn cung cấp tính ẩn danh bằng cách trộn các khoản tiền được gửi bởi những người dùng khác nhau thành một quỹ duy nhất mà bất kỳ ai cũng có thể rút mà không cần phải cung cấp bất kỳ thông tin nào khác ngoài bằng chứng để xác thực khoản tiền gửi trong quá khứ.

Càng nhiều tiền được phân bổ vào một nhóm riêng tư, thì người quan sát bên ngoài càng khó suy luận được ai sở hữu cái gì; nếu những kẻ xấu tham gia nhóm, những người tham gia trung thực có thể vô tình hỗ trợ tội phạm rửa tiền bằng cách đóng góp vào bộ ẩn danh của giao thức. Đây có lẽ là lý do tại sao lệnh trừng phạt của OFAC được mở rộng (và vẫn mở rộng) đến các địa chỉ đã tương tác với Tornado Cash, ngay cả khi những địa chỉ đó không liên quan đến những kẻ xấu đã biết (ví dụ: băng nhóm lừa đảo, tin tặc được nhà nước tài trợ và kẻ khai thác mũ đen).

Các máy trộn như Tornado Cash cũng tạo ra vấn đề về khả năng thay thế: các token được rút ra từ một nhóm trộn có thể trở nên “bị ô nhiễm” và không thể sử dụng hoặc trao đổi 1:1 với các token “sạch” chưa qua máy trộn. Có một chủ đề tuyệt vời trên Reddit thảo luận chi tiết hơn về vấn đề tiền bị ô nhiễm, tôi khuyên bạn nên đọc. Sau đây là một số bình luận mang tính khai sáng hơn từ chủ đề đó:

Điều này có thể gây ra hậu quả thực tế: ví dụ, nhiều cá nhân nổi tiếng trong cộng đồng Ethereum thấy mình không thể tương tác với một số giao diện dapp sau khi ví của họ được gửi một lượng ETH không mong muốn từ nhóm Tornado Cash. EIP-7503 được mô tả là "bộ trộn không hợp đồng" và tránh các vấn đề đã đề cập ở trên bằng cách sử dụng các giao dịch chuyển EOA-to-EOA thông thường để đốt ETH và giới thiệu phương pháp đúc trực tiếp để tạo điều kiện rút tiền từ nhóm ẩn danh (so với việc sử dụng hợp đồng thông minh).

Một lợi ích khác của bộ trộn không hợp đồng là kích thước của bộ ẩn danh. Với Tornado Cash (và các giao thức tương tự như Railgun ), bộ ẩn danh nhỏ hơn—tương quan với số lượng người tham gia—và co lại theo thời gian. Ngược lại, EIP-7503 biến toàn bộ bộ địa chỉ có thể chi tiêu và không thể chi tiêu trên Ethereum thành một bộ ẩn danh. Với không gian địa chỉ lớn, có thể nói rằng các thám tử trên chuỗi có ý định biết ETH được gửi đến người nhận của một giao dịch chuyển tiền riêng tư đến từ đâu sẽ có một công việc khó khăn ở phía trước.

Có nhược điểm nào khi triển khai EIP-7503 không?

Dưới đây là một số nhược điểm tiềm ẩn khi triển khai EIP-7503:

Các vấn đề tuân thủ quy định

Trong khi các phân tích trước đây cho thấy Ethereum khó có thể chịu chung số phận như Monero và Zcash nếu nó bắt đầu hỗ trợ chuyển tiền riêng tư, thì không thể thực sự dự đoán được điều gì sẽ xảy ra nếu EIP-7503 được kích hoạt. Sau đây là bình luận của một người tham gia trên chủ đề Ethereum Magicians thảo luận về những tác động đối với các cơ quan quản lý:

Trong khi là giải pháp bảo mật gốc cho Ethereum, cộng đồng đang bắt đầu thừa nhận tầm quan trọng của việc đi trên dây giữa quyền riêng tư/ẩn danh và tuân thủ quy định sau hậu quả từ các lệnh trừng phạt nhắm vào Tornado Cash. Ý tưởng này đặc biệt ảnh hưởng đến việc thiết kế thế hệ giao thức bảo mật mới như Privacy Pools và Nocturne :

• Privacy Pools cho phép người dùng tạo ra "bằng chứng vô tội" chứng thực việc loại trừ tiền gửi của họ khỏi nhóm lưu trữ tiền gửi từ những kẻ xấu. Nói cách khác, người dùng có thể tương tác với một máy trộn và nói "Tôi không giúp tội phạm và khủng bố rửa tiền".

• Nocturne có kế hoạch chuyển sang giao thức bằng chứng vô tội, nhưng hiện đang triển khai một số rào cản để đảm bảo tuân thủ . Điều này bao gồm lọc tiền gửi, trì hoãn xử lý tiền gửi, giới hạn tỷ lệ cho mỗi địa chỉ và giới hạn tỷ lệ toàn cầu giới hạn tổng giá trị tiền gửi mà giao thức có thể xử lý trong một ngày.

  
  

Các giải pháp bảo mật dựa trên hợp đồng thông minh như Nocturne và Privacy Pools có khả năng triển khai các biện pháp kiểm soát chi tiết và loại trừ có chọn lọc những người dùng được cho là tham gia vào hoạt động bất hợp pháp. Các giải pháp bảo mật trong giao thức như EIP-7503 không phân biệt đối xử—một tính năng mong muốn nhưng có thể tạo ra vấn đề và mở đường cho những kẻ xấu lợi dụng chức năng giao dịch riêng tư.

Về mặt lý thuyết, có thể cải thiện EIP-7503 bằng cách thêm tiện ích danh sách đen được mô tả trước đó, nhưng điều này có thể mở ra một loạt vấn đề:

• Ai được duy trì danh sách các địa chỉ bị đưa vào danh sách đen? Chúng ta có yêu cầu OFAC cung cấp danh sách các địa chỉ bị đưa vào danh sách đen và có nguy cơ để chính phủ quyết định ai được giao dịch riêng tư trên Ethereum không? Chúng ta có nguy cơ gây ra một nhánh tranh chấp nếu một nhóm trình xác thực từ chối kiểm duyệt các giao dịch từ một hoặc nhiều tài khoản được liệt kê trong sổ đăng ký blacklistedAddresses không?
• Nếu EIP-7503 được triển khai bằng rollup, thì DAO có chịu trách nhiệm duy trì sổ đăng ký blacklistedAddresses không? Hay nhóm sáng lập có ký hợp đồng với các công ty pháp y như Chainalysis, Elliptic và TRM Labs để cung cấp thông tin về địa chỉ nào nên bị hạn chế nhận chuyển khoản riêng tư? Những vấn đề nào có thể xuất hiện nếu một công ty vì lợi nhuận quyết định những gì xảy ra ở lớp cơ sở của rollup?
• Nếu một rollup quyết định xóa các đặc quyền quản trị và khiến các hợp đồng xác minh/minter không thể nâng cấp, thì làm thế nào để đảm bảo những kẻ xấu không bắt đầu di chuyển tiền qua giao thức? Có thể xử lý việc lọc chọn lọc các giao dịch từ những kẻ khai thác đã biết ở các lớp trên của ngăn xếp (ví dụ: ở cấp trình tự hoặc trình xác thực) không? Các khâu hậu cần liên quan là gì?

Đây chỉ là một vài câu hỏi cần được trả lời trước khi Ethereum (hoặc Ethereum L2) áp dụng EIP-7503. Crypto vẫn còn là một lĩnh vực chưa được khám phá, nhưng việc thực hiện nhiều Murphyjitsu , nghĩ đến các trường hợp ngoại lệ tiềm ẩn trước, sẽ giúp ích khi đưa ra quyết định có ý nghĩa quan trọng đối với sự tồn tại lâu dài của giao thức.

Sự bất hạnh đè nặng nhất lên những ai chỉ mong đợi may mắn. — Seneca

Khả năng tập trung tiềm ẩn liên quan đến mã thông báo ERC-20

Việc triển khai EIP-7503 yêu cầu nâng cấp lên EVM để hỗ trợ loại giao dịch mới chấp nhận biên lai ghi và ghi có số dư của người nhận bằng ETH đã ghi trong giao dịch trước đó. Các máy khách thực hiện cũng sẽ cần nâng cấp để hỗ trợ Cây Merkle thưa thớt (SMT) để lưu trữ các trình hủy và triển khai các mạch ngoài chuỗi để tạo và xác minh bằng chứng ghi thay mặt cho người dùng.

Nhận ra rằng việc nâng cấp có thể không khả thi, các tác giả của EIP-7503 có một đề xuất thay thế để triển khai EIP-7503 bằng cách sử dụng hợp đồng mã thông báo ERC-20 . Người dùng giữ nguyên quy trình làm việc được mô tả trong các phần trước (gửi tiền đến một địa chỉ không thể chi tiêu và tạo ra một trình hủy bỏ), nhưng đúc mã thông báo ERC-20 sau khi gửi bằng chứng đốt thay vì nhận mã thông báo ETH. Hợp đồng ERC-20 tích hợp với hợp đồng xác minh EIP-7503 đặc biệt để xác minh bằng chứng đốt trên chuỗi (hợp đồng ERC-20 cũng có thể triển khai mạch xác minh).

Trong khi hợp đồng ERC-20 đơn giản hóa việc triển khai EIP-7503, cách tiếp cận này lại tái hiện vấn đề tập trung hóa và kiểm duyệt. Chúng ta có thể khiến token ERC-20 không thể nâng cấp và không thể quản lý như Wrapped Ether (WETH) để loại bỏ các vectơ tập trung hóa, nhưng điều đó không thể giúp giải quyết các vấn đề như sàn giao dịch hủy niêm yết token.

Ngoài ra, chúng ta nên lưu ý rằng pháp y trên chuỗi dễ dàng xác định các tài khoản tương tác với hợp đồng ERC-20 và đưa các địa chỉ đó vào danh sách đen hơn—nếu các cơ quan quản lý quyết định truy quét nhiều loại tiền điện tử bảo mật hơn đang lưu hành trên Ethereum. Vì đây là vấn đề mà EIP-7503 được thiết kế để giải quyết, nên có thể khó thấy đề xuất tạo ra "mã thông báo ERC-20 riêng tư" là một cải tiến.

Mặt khác, một mã thông báo ERC-20 sẽ giúp triển khai dễ dàng hơn tính năng sàng lọc chuyển tiền chặn chuyển tiền đến các địa chỉ bị đưa vào danh sách đen. Nhà phát triển có thể chỉ cần lưu trữ blacklist[] trong hợp đồng và sửa đổi transfer() để bao gồm kiểm tra danh tính của địa chỉ nhận mã thông báo trong giao dịch. Tuy nhiên, đây là một tính năng mà chúng tôi không thể triển khai ở cấp độ giao thức mà không đưa ra một số giả định về độ tin cậy rất mạnh.

Tăng chi phí R&D

EIP-7503 đi kèm với yêu cầu xây dựng, thử nghiệm, kiểm toán và duy trì cơ sở hạ tầng mã hóa phức tạp, tiên tiến cần thiết để hỗ trợ các giao dịch ẩn danh và riêng tư. Ít nhất, mô tả của Nethermind về triển khai L2 của EIP-7503 và bằng chứng khái niệm Chuỗi EIP-7503 của Nobitex Labs đều cho thấy một lượng lớn nỗ lực kỹ thuật sẽ hướng tới việc tạo ra các mạch ZK-SNARK để tạo và xác minh bằng chứng EIP-7503.

Điều quan trọng nữa là phải lưu ý rằng các nguyên hàm mật mã như ZK-SNARK vẫn chưa được thử nghiệm đủ để các nhà phát triển giao thức có thể triển khai chúng với sự tự tin tuyệt đối. Để minh họa, Zcash đã vá một lỗi cho phép người dùng không trung thực cung cấp bằng chứng giả về quyền sở hữu tài sản và đúc một lượng token vô hạn vào năm 2018. Tôi cũng đã thảo luận về việc nhóm Tornado Cash thoát khỏi một cuộc khai thác tiềm ẩn vào năm 2019.

Một lỗi trong quá trình triển khai EIP-7503 trên Ethereum sẽ có tác động không hề nhỏ. Ví dụ, người dùng vô tình phát hiện ra một lỗi cho phép bỏ qua các kiểm tra quan trọng do mạch thực hiện để xác minh bằng chứng đốt (ví dụ: số dư địa chỉ đốt và sử dụng các trình hủy) có thể khai thác kiến thức để đúc vô số Ether và làm sụp đổ giá trị thị trường của ETH.

Một lĩnh vực phức tạp khác xuất phát từ yêu cầu đối với trình xác minh EIP-7503 để xác minh tiêu đề khối B có trong bằng chứng do người dùng tạo. EVM lưu trữ các hàm băm của 128-256 khối cuối cùng, do đó trình xác minh trên chuỗi không thể xác minh tiêu đề khối một cách đáng tin cậy từ phạm vi xa hơn.

Để xác minh gốc trạng thái từ các khối cũ hơn, EIP-210 sẽ cần được triển khai. EIP-210 đề xuất tạo một hợp đồng thông minh cấp hệ thống lưu trữ các khối băm lịch sử và cấu trúc lại mã lệnh BLOCKHASH để cho phép khách hàng đọc hợp đồng.

EIP-210 không thực sự cần thiết vì người dùng có ít nhất một giờ ( 14 seconds * 256 blocks ) để tạo và gửi bằng chứng có thể được xác minh bằng EVM. Tuy nhiên, việc cho phép người dùng tự do trì hoãn việc hoàn trả tiền gửi được gửi đến địa chỉ ghi sẽ cải thiện UX và khiến quá trình rút tiền chống lại việc phân cụm địa chỉ và các kỹ thuật phân tích tương tự tốt hơn.

Một giải pháp thay thế là tích hợp hợp đồng oracle yêu cầu các tác nhân (được khuyến khích) gửi các tiêu đề khối lịch sử đến một hợp đồng trên chuỗi. Điều này dễ triển khai hơn là tạo hợp đồng thông minh cấp hệ thống và tái cấu trúc mã lệnh, nhưng yêu cầu các nhà điều hành oracle đáng tin cậy phải (a) công bố các tiêu đề khối chính xác (b) gửi các tiêu đề khối kịp thời. Nếu cả hai giả định này đều không đúng, người dùng trung thực có thể không thể đổi tiền gửi và các tác nhân xấu có thể công bố các tiêu đề khối không chính xác để xác minh bằng chứng Merkle cho các giao dịch đốt không tồn tại.

Giảm thiểu các tập ẩn danh

Vào thời điểm EIP-7503 được kích hoạt, bộ ẩn danh cho người dùng đúc ETH tại khối #11000 sẽ bao gồm tất cả các EOA Ethereum có số dư ETH dương và không có giao dịch nào được thực hiện. Điều này rất quan trọng đối với tính chất không thể theo dõi của các giao dịch ẩn danh: nếu một giao dịch đốt ETH, không thể nhận ra đó là giao dịch đốt vì địa chỉ không thể chi tiêu trông giống như một địa chỉ Ethereum thông thường.

Tuy nhiên, số lượng địa chỉ mà số dư tài khoản vẫn giữ nguyên và không có giao dịch nào được gửi sẽ giảm xuống mức chỉ có các địa chỉ ghi mới tạo nên bộ ẩn danh. Do đó, bộ ẩn danh bắt đầu trông giống như các bộ ẩn danh của các bộ trộn dựa trên hợp đồng như Tornado Cash và các công cụ bảo mật thế hệ mới như Privacy Pools và Railgun (ngụ ý việc giảm dần các đảm bảo về quyền riêng tư của EIP-7503).

Ngoại lệ duy nhất là những tài khoản nhận ETH vì người gửi vô tình chuyển tiền đến một địa chỉ không tồn tại, những tài khoản như vậy sẽ vẫn nằm trong bộ ẩn danh EIP-7503 mãi mãi. Chúng ta có thể muốn xem xét các địa chỉ mà chủ sở hữu mất khóa riêng tư như một phần của nhóm ẩn danh, nhưng điều này (may mắn và không may) hiếm khi xảy ra và những tài khoản đó thường có ít nhất một hoặc nhiều giao dịch đi. (Thật khó để tưởng tượng người dùng mới nhất mất khóa riêng tư trước khi thực hiện bất kỳ giao dịch nào.)

Bất chấp việc giảm bộ ẩn danh, EIP-7503 vẫn hữu ích vì khả năng phủ nhận hợp lý mà nó mang lại. Giả sử ai đó tạo ra một cơn bão trên Twitter tiền điện tử và cáo buộc Alice cố tình đốt ETH (bằng cách gửi đến một địa chỉ không thể chi tiêu) với ý định rút tiền về một địa chỉ mới sau đó. Alice có khả năng phủ nhận hợp lý và có thể phản bác cáo buộc bằng cách tuyên bố:

• “Tôi đã gửi nhầm ETH đến địa chỉ. Bạn có thể chứng minh tôi không mắc lỗi khi nhập địa chỉ vào MetaMask không?”
• “Tôi có khóa riêng cho địa chỉ nhưng không thể chia sẻ. Bạn sẽ không yêu cầu khóa riêng của tôi ngay bây giờ chứ?”
• “Tôi có khóa riêng của địa chỉ, nhưng tôi đã làm mất nó. Bạn có thể chứng minh tôi không làm mất khóa riêng của mình không?”

Những tuyên bố này có thể không thuyết phục, nhưng đó là những gì khả năng phủ nhận hợp lý trông như thế nào trong bối cảnh thực tế. Từ điển Luật pháp diễn đạt như sau:

“Có thể xảy ra không có nghĩa là đáng tin cậy, có thể xảy ra hoặc thậm chí có khả năng xảy ra. Có thể xảy ra có nghĩa là bạn có thể kết luận rằng điều gì đó có thể hoặc không thể xảy ra. Nhưng thường là về mặt lý thuyết, hời hợt hoặc đáng ngờ. Nó cũng không nhất thiết phải là một kết luận “hợp lý”. Theo nghĩa rộng nhất, thuật ngữ này thường chỉ ra sự thiếu bằng chứng. Xét cho cùng, vô tội cho đến khi được chứng minh là có tội là xương sống của hệ thống pháp luật của chúng ta.

Vì vậy, nếu không có bằng chứng, thì có thể họ sẽ phủ nhận. Về cơ bản, bất kỳ điều gì bất hợp pháp hoặc phi đạo đức có thể được giải thích theo một vỏ bọc vô tội và có thể xảy ra - đúng hay không - đều nằm trong phạm vi phủ nhận hợp lý. Ngay cả khi tính hợp lý của sự phủ nhận là đáng ngờ.

Thời điểm duy nhất người dùng có thể được kết nối chắc chắn với giao dịch chuyển tiền riêng tư EIP-7503 là tại thời điểm xử lý giao dịch chuyển tiền đến địa chỉ người nhận. Tuy nhiên, người dùng có thể thực hiện các bước để giảm hoặc loại bỏ hoàn toàn khả năng người quan sát bên ngoài kết nối giao dịch rút tiền với giao dịch ghi:

• Thay vì rút về một địa chỉ có thể chi tiêu, Alice đúc ETH vào một địa chỉ đốt khác để giữ tiền trong bộ ẩn danh. Lặp lại quá trình đốt → đúc → đốt → đúc → lặp lại nhiều lần khiến việc phát hiện địa chỉ cuối cùng có phải là tài khoản do Alice kiểm soát hay không trở nên khó khăn hơn.
• Thay vì rút toàn bộ số tiền, Alice chia số tiền rút thành hai hoặc nhiều giao dịch. Việc trì hoãn hoặc ngẫu nhiên hóa các lần rút tiền sẽ tạo ra "tiếng ồn" cản trở việc phân tích hoạt động giao dịch và khiến việc liên kết các giao dịch đốt và đúc tiền với cùng một người dùng trở nên khó khăn.

Lưu ý : Kỹ thuật thứ hai là phần mở rộng được đề xuất cho EIP-7503 và có vẻ không khả thi với thiết kế hiện tại. Để người dùng chia nhỏ các lần rút tiền, cần có một tính năng chia nhỏ các bộ hủy sao cho nullifier 1 cấp quyền đúc một phần số dư của địa chỉ ghi, nullifier 2 cấp quyền đúc một phần số dư khác, v.v.

Phần kết luận

EIP-7503 là giải pháp cho một trong những vấn đề ít được đề cập nhất của Ethereum: thiếu sự riêng tư về mặt tài chính. Nếu Ethereum sẽ thay thế các ngân hàng một ngày nào đó, nó cần cung cấp mức độ riêng tư ngang bằng với mức mà người dùng hiện đang được hưởng trong tình trạng hiện tại. Bất cứ điều gì ít hơn, và Ethereum không đạt được sự chấp nhận rộng rãi vì việc từ bỏ quyền riêng tư—kể cả để có được lợi ích tránh kiểm duyệt—là một sự hy sinh mà hầu hết các cá nhân không thể thực hiện.

EIP-7503 vẫn đang trong giai đoạn đánh giá và có thể sẽ trải qua những thay đổi và cải thiện hiệu suất. Bên cạnh việc hỗ trợ trong tương lai cho việc rút một phần số tiền, một tính năng hữu ích là cho phép người dùng kết hợp đệ quy nhiều bằng chứng ghi vào một SNARK duy nhất để xác minh tiền gửi vào các địa chỉ ghi khác nhau trong một giao dịch xác minh. Tính năng này càng làm tăng thêm sức hấp dẫn của EIP-7503 đối với các CEX và thương gia muốn duy trì một địa chỉ duy nhất cho mỗi khoản tiền gửi của người dùng mà không cần phải gửi bằng chứng ghi riêng lẻ cho (có thể là hàng trăm hoặc hàng nghìn) địa chỉ ghi.

Người dùng thông thường cũng có thể hưởng lợi bằng cách gửi token đến nhiều địa chỉ ghi (thay vì gửi đến một địa chỉ không thể chi tiêu) và gửi bằng chứng tổng hợp và bộ các trình hủy để hoàn tất chuyển khoản riêng tư. Bằng cách sử dụng nhiều hơn một địa chỉ ghi, người gửi có thể ngẫu nhiên hóa hoạt động giao dịch và ngăn chặn các nỗ lực theo dõi ngược các giao dịch ghi đến một người. Điều này bổ sung cho các lợi ích chính mà EIP-7503 đã cung cấp, chẳng hạn như tự chuyển khoản riêng tư, quyên góp/thanh toán ngang hàng riêng tư và quản lý bảng lương riêng tư cho DAO trên chuỗi.

Nếu bạn thích đọc bài viết này, hãy cân nhắc chia sẻ với người có thể thấy hữu ích và đăng ký nhận bản tin Nghiên cứu 2077 để biết thêm thông tin chi tiết về các đề xuất từ hệ sinh thái EIP. Chúng tôi sẽ tiếp tục tập trung vào các giải pháp bảo mật trong Ethereum và có kế hoạch phát hành một bài viết chi tiết về ERC-5564 (một tiêu chuẩn để tạo địa chỉ ẩn và gửi giao dịch địa chỉ ẩn trên Ethereum).

Hãy theo dõi nhé!

Lưu ý của tác giả: Bài viết này cũng được đăng ở đây .