Vitalik tác phẩm mới: Hướng dẫn không hoàn chỉnh về địa chỉ ẩn danh

Tiêu đề gốc: Hướng dẫn chưa hoàn chỉnh về địa chỉ ẩn danh
Tác giả: Vitalik Buterin
Biên soạn: Karen, Foresight News

Thách thức lớn nhất hiện nay trong hệ sinh thái Ethereum là quyền riêng tư. Theo mặc định, bất kỳ nội dung nào vào chuỗi khối công khai đều là công khai, điều này không chỉ có nghĩa là tài sản và hoạt động giao dịch, mà còn có tên miền ENS, POAP, NFT và token liên kết linh hồn. Việc sử dụng một loạt các ứng dụng Ethereum có nghĩa là nhiều hoạt động của bạn sẽ được công khai cho bất kỳ ai khác xem và phân tích.

Chúng ta cần cải thiện tình trạng này. Tuy nhiên, cho đến nay, cuộc thảo luận về việc cải thiện quyền riêng tư chủ yếu xoay quanh một trường hợp sử dụng cụ thể, đó là: việc chuyển nhượng bảo vệ quyền riêng tư cho ETH và các token ERC20 chính thống. Bài viết này sẽ mô tả cơ chế và trường hợp sử dụng của một loại công cụ khác nhau có thể cải thiện trạng thái quyền riêng tư của Ethereum trong nhiều trường hợp khác nhau, đó là khái niệm "địa chỉ ẩn danh" (stealth addresses).

Hệ thống địa chỉ ẩn danh là gì?

Giả sử Alice muốn chuyển tài sản cho Bob, có thể là một số lượng tiền điện tử nhất định (ví dụ 1 ETH, 500 RAI), hoặc có thể là một NFT. Khi Bob nhận được tài sản, anh ấy không muốn người khác biết rằng người nhận tài sản đó là anh. Việc ẩn đi thực tế rằng việc chuyển nhượng đã xảy ra là không thể, đặc biệt nếu việc chuyển nhượng là một NFT chỉ tồn tại một bản trên chuỗi, nhưng việc ẩn đi ai là người nhận có thể khả thi hơn.

Alice và Bob muốn có một hệ thống quy trình thanh toán như vậy, tức là, Bob gửi cho Alice (hoặc hỗ trợ tên miền ENS) một "địa chỉ" mã hóa nào đó có thể nhận thanh toán, chỉ cần thông tin này là đủ để Alice (hoặc bất kỳ ai khác) gửi tài sản cho anh ấy, và điều này gần như hoàn toàn giống với quy trình thanh toán hiện tại.

Cần lưu ý rằng quyền riêng tư này hoàn toàn khác với quyền riêng tư mà Tornado Cash cung cấp. Tornado Cash có thể ẩn đi việc chuyển nhượng các tài sản thay thế chính thống như ETH hoặc ERC-20, nhưng rất yếu trong việc thêm quyền riêng tư cho các chuyển nhượng ERC20 ít được biết đến và hoàn toàn không thể thêm quyền riêng tư cho các chuyển nhượng NFT.

Như đã đề cập ở trên, quy trình làm việc thông thường khi thanh toán bằng tiền điện tử đã tăng cường quyền riêng tư, tức là, không ai có thể biết người nhận tài sản là Bob, và quy trình làm việc không thay đổi.

Địa chỉ ẩn danh có thể được tạo ra bởi Alice hoặc Bob, nhưng chỉ có Bob kiểm soát. Bob tạo ra một khóa chi tiêu (spending key) và giữ bí mật về nó, sau đó sử dụng khóa đó để tạo ra một địa chỉ meta ẩn danh (stealth meta-address). Anh ấy sẽ truyền địa chỉ meta này cho Alice (hoặc đăng ký trên ENS). Alice có thể thực hiện các phép toán trên địa chỉ meta này để tạo ra địa chỉ ẩn danh thuộc về Bob. Sau đó, Alice có thể gửi bất kỳ tài sản nào mà cô ấy muốn đến địa chỉ này, Bob sẽ hoàn toàn kiểm soát những tài sản này. Trong quá trình chuyển nhượng, Alice công bố một số dữ liệu mã hóa bổ sung trên chuỗi (một khóa công khai tạm thời) để giúp Bob phát hiện rằng địa chỉ này thuộc về anh.

Một cách nhìn khác là: địa chỉ ẩn danh cung cấp cho Bob các thuộc tính quyền riêng tư tương tự, tạo ra một địa chỉ mới cho mỗi giao dịch, nhưng không cần bất kỳ tương tác nào từ Bob.

Quy trình làm việc hoàn chỉnh của kế hoạch địa chỉ ẩn danh được mô tả như sau:

1. Bob tạo ra khóa chi tiêu gốc của mình (m) và địa chỉ meta ẩn danh (M).

2. Bob thêm một bản ghi ENS để đăng ký (M) làm địa chỉ meta ẩn danh bob.eth.

3. Chúng ta giả định rằng Alice biết địa chỉ của Bob là bob.eth. Alice tìm kiếm địa chỉ meta ẩn danh (M) của Bob trên ENS.

4. Alice tạo ra một khóa tạm thời mà chỉ cô ấy biết, và chỉ có thể sử dụng một lần (để tạo ra địa chỉ ẩn danh cụ thể này).

5. Alice sử dụng một thuật toán để kết hợp khóa tạm thời của cô ấy và địa chỉ meta của Bob để tạo ra một địa chỉ ẩn danh. Cô ấy bây giờ có thể gửi tài sản đến địa chỉ này.

6. Alice cũng tạo ra khóa công khai tạm thời của cô ấy và công bố nó lên bảng đăng ký khóa công khai tạm thời (điều này có thể được thực hiện trong cùng một giao dịch với giao dịch đầu tiên gửi tài sản đến địa chỉ ẩn danh này).

7. Để Bob phát hiện địa chỉ ẩn danh thuộc về anh, Bob cần quét bảng đăng ký khóa công khai tạm thời để tìm danh sách toàn bộ khóa công khai tạm thời mà bất kỳ ai đã công bố kể từ lần quét cuối cùng của anh.

8. Đối với mỗi khóa công khai tạm thời, Bob cố gắng kết hợp nó với khóa chi tiêu gốc của mình để tạo ra một địa chỉ ẩn danh và kiểm tra xem có bất kỳ tài sản nào trong địa chỉ đó không. Nếu có, Bob tính toán khóa chi tiêu của địa chỉ đó và ghi nhớ nó.

Tất cả điều này phụ thuộc vào hai cách sử dụng của bí mật mã hóa. Đầu tiên, chúng ta cần một cặp thuật toán để tạo ra khóa chia sẻ (shared secret): một thuật toán sử dụng khóa tạm thời của Alice và địa chỉ meta của Bob, thuật toán còn lại sử dụng khóa chi tiêu gốc của Bob và khóa công khai tạm thời của Alice. Điều này có thể được thực hiện bằng nhiều cách; Trao đổi khóa Diffie-Hellman là một trong những thành tựu của lĩnh vực mật mã hiện đại, và nó thực hiện điều này một cách hoàn hảo.

Nhưng chỉ chia sẻ bí mật thì vẫn chưa đủ: nếu chúng ta chỉ tạo ra một khóa riêng từ bí mật chia sẻ, thì cả Alice và Bob đều có thể tiêu thụ từ địa chỉ này. Chúng ta cũng thêm một cơ chế làm mờ khóa: trong một cặp thuật toán, Bob có thể kết hợp khóa chia sẻ với khóa chi tiêu gốc của mình, trong khi Alice có thể kết hợp khóa chia sẻ với địa chỉ meta của Bob, để Alice có thể tạo ra địa chỉ ẩn danh, và Bob có thể tạo ra khóa chi tiêu cho địa chỉ ẩn danh đó, tất cả đều không cần tạo ra liên kết công khai giữa địa chỉ ẩn danh và địa chỉ meta của Bob (hoặc giữa một địa chỉ ẩn danh và một địa chỉ ẩn danh khác).

Sử dụng mật mã đường cong elip để ẩn địa chỉ

Việc sử dụng mật mã đường cong elip để ẩn địa chỉ ban đầu được Peter Todd giới thiệu vào năm 2014 trong bối cảnh Bitcoin. Cách thức hoạt động của công nghệ này như sau:

· Bob tạo ra một khóa (m) và tính toán M = G * m, trong đó G là điểm sinh công khai của đường cong elip. Địa chỉ meta ẩn danh là (M).

· Alice tạo ra một khóa tạm thời (r) và công bố khóa công khai tạm thời R = G * r.

· Alice có thể tính toán một khóa chia sẻ S = M * r, Bob cũng có thể tính toán cùng một khóa chia sẻ S = m * R.

· Nói chung, trong Bitcoin và Ethereum (bao gồm cả tài khoản ERC-4337 được thiết kế đúng), địa chỉ là một hàm băm chứa khóa công khai dùng để xác thực giao dịch từ địa chỉ đó. Do đó, nếu bạn tính toán khóa công khai, bạn có thể tính toán địa chỉ. Để tính toán khóa công khai, Alice hoặc Bob có thể tính toán P = M + G * hash(S)

· Để tính toán khóa riêng của địa chỉ đó, Bob có thể tính toán p = m + hash(S)

Điều này đáp ứng tất cả các yêu cầu ở trên và rất đơn giản.

Thậm chí có một EIP cố gắng định nghĩa một tiêu chuẩn địa chỉ ẩn danh cho Ethereum, hỗ trợ cả phương pháp này và cung cấp cho người dùng không gian để phát triển các phương pháp khác (ví dụ, hỗ trợ Bob có các khóa chi tiêu và xem riêng biệt, hoặc sử dụng mật mã khác để đạt được an toàn chống lượng tử). Bây giờ bạn có thể nghĩ: địa chỉ ẩn danh không khó lắm, kiến thức lý thuyết đã vững chắc, việc áp dụng chỉ là một chi tiết thực hiện. Tuy nhiên, vấn đề là, việc thực hiện thực sự hiệu quả vẫn cần thông qua một số chi tiết thực hiện quan trọng.

Địa chỉ ẩn danh và phí giao dịch thanh toán

Giả sử ai đó gửi cho bạn một NFT. Nếu bạn muốn đảm bảo quyền riêng tư, họ sẽ gửi nó đến địa chỉ ẩn danh mà bạn kiểm soát. Sau khi quét khóa công khai tạm thời trên chuỗi, ví của bạn sẽ tự động phát hiện địa chỉ đó. Bạn bây giờ có thể tự do chứng minh quyền sở hữu NFT hoặc chuyển nhượng nó cho người khác. Nhưng có một vấn đề là số dư ETH trong tài khoản đó là 0, vì vậy không thể thanh toán phí giao dịch. Ngay cả người thanh toán token ERC-4337 cũng không hiệu quả, vì chúng chỉ áp dụng cho các token ERC20 thay thế. Và bạn không thể gửi ETH từ ví chính của bạn đến nó, vì điều đó sẽ tạo ra một liên kết công khai, tức là không còn quyền riêng tư.

Có một cách đơn giản để giải quyết vấn đề này: chỉ cần sử dụng ZK-SNARKs để chuyển tiền để thanh toán phí. Nhưng điều này sẽ tiêu tốn rất nhiều Gas, chỉ một lần chuyển nhượng sẽ tiêu tốn hàng trăm nghìn Gas.

Một cách thông minh hơn liên quan đến việc tin tưởng vào các bộ tổng hợp giao dịch chuyên dụng (các thuật ngữ MEV gọi là searchers). Những bộ tổng hợp này sẽ cho phép người dùng thanh toán một lần để mua một nhóm "vé" có thể sử dụng để thanh toán giao dịch trên chuỗi. Khi người dùng cần chi tiêu NFT trong một địa chỉ ẩn danh không chứa bất kỳ nội dung nào khác, họ sẽ cung cấp cho bộ tổng hợp một trong những vé đó, sử dụng phương pháp mù Chaumian để mã hóa. Đây là giao thức gốc được sử dụng trong các kế hoạch tiền điện tử bảo vệ quyền riêng tư tập trung được đề xuất vào những năm 1980 và 1990. Các searchers chấp nhận vé và lặp lại việc bao gồm giao dịch miễn phí trong gói của họ cho đến khi giao dịch được chấp nhận thành công trong một khối.

Địa chỉ ẩn danh và tách khóa chi tiêu và khóa xem

Giả sử Bob không chỉ có một "khóa chi tiêu gốc" chính có thể làm mọi thứ, mà muốn có một khóa chi tiêu gốc riêng và một khóa xem riêng. Khóa xem này có thể xem tất cả các địa chỉ ẩn danh của Bob nhưng không thể thực hiện chi tiêu.

Trong thế giới đường cong elip, điều này có thể được giải quyết bằng một mẹo mật mã rất đơn giản:

· Địa chỉ meta của Bob (M) bây giờ có dạng (K, V), mã hóa G * k và G * v, trong đó k là khóa chi tiêu, v là khóa xem.

· Khóa chia sẻ bây giờ là S = V * r = v * R, trong đó r vẫn là khóa tạm thời của Alice, R vẫn là khóa công khai tạm thời mà Alice đã công bố.

· Khóa công khai của địa chỉ ẩn danh là P = K + G * hash(S), khóa riêng là p = k + hash(S).

Bước đầu tiên (tạo bí mật chia sẻ) sử dụng khóa xem, bước thứ hai (thuật toán song song của Alice và Bob tạo địa chỉ ẩn danh và khóa riêng của nó) sử dụng khóa chi tiêu gốc.

Điều này có nhiều trường hợp sử dụng. Ví dụ, nếu Bob muốn nhận POAP, thì Bob có thể cung cấp khóa xem cho ví POAP của mình (hoặc thậm chí là một giao diện web không an toàn) để quét chuỗi và xem tất cả POAP của mình mà không cần cấp quyền chi tiêu cho giao diện đó.

Địa chỉ ẩn danh và dễ quét

Để dễ dàng quét toàn bộ tập hợp khóa công khai tạm thời, một kỹ thuật là thêm một nhãn xem vào mỗi khóa công khai tạm thời. Một cách để thực hiện điều này trong cơ chế trên là làm cho nhãn xem trở thành một byte của khóa chia sẻ (ví dụ, tọa độ x của S modulo 256, hoặc byte đầu tiên của hash(S)).

Như vậy, Bob chỉ cần thực hiện một phép nhân đường cong elip cho mỗi khóa công khai tạm thời để tính toán khóa chia sẻ, và với nhãn xem, việc quét cũng dễ dàng hơn.

Địa chỉ ẩn danh và an toàn chống lượng tử

Các phương án ở trên phụ thuộc vào đường cong elip, nhưng mặc dù phương án này hoạt động rất tốt, nhưng không may, nó dễ bị tấn công bởi máy tính lượng tử. Chúng ta sẽ cần chuyển sang các thuật toán chống lượng tử. Có hai ứng viên tự nhiên: đồng cấu đường cong elip và lưới (lattices).

Đồng cấu đường cong elip là một cấu trúc toán học rất khác dựa trên đường cong elip, có các đặc tính tuyến tính, cho phép chúng ta sử dụng các mẹo mật mã tương tự như những gì đã làm ở trên, nhưng khéo léo tránh việc cấu trúc có thể dễ bị tấn công bởi máy tính lượng tử thông qua logarit rời rạc.

Điểm yếu chính của mật mã đồng cấu là toán học nền tảng rất phức tạp, cũng như rủi ro ẩn chứa các cuộc tấn công trong sự phức tạp này. Một số giao thức dựa trên đồng cấu đã bị tấn công vào năm ngoái, nhưng các giao thức khác vẫn an toàn. Lợi thế chính của đồng cấu là kích thước khóa tương đối nhỏ và khả năng chuyển giao nhiều phương pháp dựa trên đường cong elip.

Một 3-isogeny trong CSIDH

Lưới (lattices) là một cấu trúc mật mã rất khác, dựa vào toán học đơn giản hơn so với đồng cấu đường cong elip, và có khả năng thực hiện một số điều rất mạnh mẽ (ví dụ mã hóa hoàn toàn đồng nhất). Các phương án địa chỉ ẩn danh có thể được xây dựng trên lưới, mặc dù việc thiết kế phương án tốt nhất vẫn là một câu hỏi chưa được giải quyết. Tuy nhiên, cấu trúc dựa trên lưới thường có kích thước khóa lớn hơn.

Mã hóa hoàn toàn đồng nhất, ứng dụng của lưới. FHE cũng có thể được sử dụng để giúp các giao thức địa chỉ ẩn danh theo những cách khác nhau: giúp Bob ủy quyền kiểm tra xem địa chỉ ẩn danh có tài sản nào trong toàn bộ chuỗi mà không tiết lộ khóa xem của mình.

Cách thứ ba là xây dựng các phương án địa chỉ ẩn danh từ các nguyên lý hộp đen tổng quát. Phần tạo khóa chia sẻ của phương án này trực tiếp ánh xạ đến trao đổi khóa, một thành phần quan trọng trong hệ thống mã hóa công khai. Phần khó hơn là làm cho Alice chỉ tạo ra địa chỉ ẩn danh (không phải khóa chi tiêu) và cho Bob tạo ra khóa chi tiêu bằng thuật toán song song.

Thật không may, bạn không thể sử dụng các thành phần đơn giản hơn để xây dựng địa chỉ ẩn danh so với những gì cần thiết để xây dựng hệ thống mã hóa công khai. Có một bằng chứng đơn giản rằng bạn có thể sử dụng một phương án địa chỉ ẩn danh để xây dựng một hệ thống mã hóa công khai. Nếu Alice muốn mã hóa một thông điệp cho Bob, cô ấy có thể gửi N giao dịch, mỗi giao dịch gửi đến một địa chỉ ẩn danh của Bob hoặc gửi đến một địa chỉ ẩn danh thuộc về chính cô, Bob có thể xem những giao dịch nào anh nhận được để đọc thông điệp. Điều này rất quan trọng, trong chứng minh toán học bạn không thể chỉ sử dụng hàm băm để thực hiện mã hóa công khai, trong khi bạn có thể chỉ sử dụng hàm băm để thực hiện chứng minh không biết, do đó, địa chỉ ẩn danh không thể chỉ hoàn thành bằng hàm băm.

Đây thực sự là một phương pháp sử dụng các thành phần tương đối đơn giản: chứng minh không biết, có thể được tạo thành từ hàm băm và mã hóa công khai (giấu khóa). Địa chỉ meta của Bob là một khóa mã hóa công khai công khai cộng với một hàm băm h = hash(x), khóa chi tiêu của anh là khóa giải mã tương ứng cộng với x. Để tạo ra một địa chỉ ẩn danh, Alice tạo ra một giá trị c và mã hóa c mà Bob có thể đọc như khóa công khai tạm thời của cô ấy. Địa chỉ đó bản thân nó là một tài khoản ERC-4337, mã của nó xác thực giao dịch bằng cách yêu cầu giao dịch cung cấp chứng minh không biết, chứng minh quyền sở hữu của giá trị x và c, khiến k = hash(hash(x), c) (trong đó k là một phần của mã tài khoản). Biết x và c, Bob có thể tự tái tạo địa chỉ và mã.

Việc mã hóa (c) sẽ không tiết lộ bất kỳ thông tin nào cho bất kỳ ai khác ngoài Bob, và (k) là một hàm băm, gần như không tiết lộ bất kỳ điều gì về c. Mã ví bản thân chỉ chứa (k), (c) riêng tư có nghĩa là (k) không thể truy ngược về (h).

Tuy nhiên, điều này cần một STARK. Cuối cùng, tôi nghĩ rằng thế giới Ethereum sau lượng tử rất có thể sẽ liên quan đến việc sử dụng nhiều ứng dụng STARK, vì vậy tôi ủng hộ các giao thức tổng hợp như được mô tả ở đây để kết hợp tất cả các STARK này thành một STARK đệ quy nhằm tiết kiệm không gian.

Địa chỉ ẩn danh và phục hồi xã hội cũng như ví đa L2

Trong một thời gian dài, tôi đã rất quan tâm đến ví phục hồi xã hội, ví phục hồi xã hội có cơ chế ký đa chữ ký, cho phép chia sẻ khóa giữa một tổ chức, các thiết bị khác của bạn và một số bạn bè. Nếu bạn mất khóa chính, hầu hết các khóa cho phép phục hồi quyền truy cập vào tài khoản.

Tuy nhiên, ví phục hồi xã hội không kết hợp tốt với địa chỉ ẩn danh: nếu bạn phải phục hồi tài khoản của mình (thay đổi khóa riêng điều khiển nó), bạn cũng phải thực hiện một số bước để thay đổi logic xác thực tài khoản của N ví ẩn danh của bạn, điều này sẽ cần N giao dịch, với chi phí cao, tiện lợi và chi phí quyền riêng tư.

Sự tương tác giữa phục hồi xã hội và nhiều giao thức L2 cũng có những lo ngại tương tự: nếu bạn có tài khoản trên Optimism, Arbitrum, StarkNet, Scroll, Polygon, vì lý do mở rộng có hàng chục phiên bản song song, và bạn có một tài khoản trên mỗi phiên bản, thì việc thay đổi khóa có thể là một thao tác rất phức tạp.

Thay đổi khóa của nhiều tài khoản trên nhiều chuỗi là một công việc khổng lồ.

Có thể bạn có thể sử dụng một số phần mềm tự động để chuyển tài sản đến địa chỉ ẩn danh mới trong khoảng thời gian hai tuần với khoảng thời gian ngẫu nhiên nhằm giảm hiệu quả của các liên kết dựa trên thời gian. Nhưng điều này vẫn chưa hoàn hảo. Một cách khác là chia sẻ khóa gốc giữa các người giám hộ một cách bí mật, thay vì sử dụng hợp đồng thông minh để phục hồi. Tuy nhiên, điều này sẽ loại bỏ khả năng tạm dừng quyền lực của người giám hộ trong việc giúp phục hồi tài khoản của bạn, do đó có rủi ro lâu dài.

Một phương pháp phức tạp hơn liên quan đến chứng minh không biết. Điều này cho phép nhiều tài khoản, thậm chí trải dài qua nhiều giao thức L2, được kiểm soát bởi một giá trị k duy nhất ở đâu đó (trên chuỗi cơ sở hoặc trên một số L2), trong đó việc thay đổi giá trị đó đủ để thay đổi quyền sở hữu của tất cả các tài khoản, tất cả đều không tiết lộ liên kết giữa nhiều tài khoản của bạn.

Kết luận

Các địa chỉ ẩn danh cơ bản hiện tại có thể được triển khai nhanh chóng và có thể cải thiện đáng kể quyền riêng tư của người dùng trên Ethereum. Tôi nghĩ rằng vì những lý do khác liên quan đến quyền riêng tư, ví nên bắt đầu chuyển sang mô hình nhiều địa chỉ nguyên bản hơn (ví dụ, tạo một địa chỉ mới cho mỗi ứng dụng mà bạn tương tác có thể là một lựa chọn).

Tuy nhiên, địa chỉ ẩn danh thực sự sẽ mang lại một số vấn đề về khả năng sử dụng lâu dài, chẳng hạn như khó khăn trong việc phục hồi xã hội. Về lâu dài, những vấn đề này có thể được giải quyết, nhưng hệ sinh thái địa chỉ ẩn danh thực sự có vẻ phụ thuộc vào chứng minh không biết.