Tác giả: Vitalik Buterin
Biên dịch: DeFi 之道
Xin chân thành cảm ơn Ben DiFrancesco, Matt Solomon, Toni Wahrstätter và Antonio Sanso vì những phản hồi và đánh giá quý báu.
Một trong những thách thức lớn nhất còn tồn tại trong hệ sinh thái Ethereum chính là vấn đề quyền riêng tư. Mặc định, mọi thứ được đưa lên blockchain công khai đều trở nên minh bạch. Ngày càng nhiều, điều này không chỉ bao gồm tiền và các giao dịch tài chính, mà còn cả tên miền ENS, POAP, NFT, token gắn liền với linh hồn (soul-bound tokens), v.v. Trên thực tế, việc sử dụng toàn bộ bộ ứng dụng Ethereum đồng nghĩa với việc bạn công khai một phần đời sống của mình cho bất kỳ ai xem xét và phân tích.
Làm thế nào để cải thiện tình trạng này đã trở thành một vấn đề cấp thiết được thừa nhận rộng rãi. Tuy nhiên, cho đến nay, các cuộc thảo luận về cải thiện quyền riêng tư chủ yếu tập trung vào một trường hợp sử dụng cụ thể: chuyển khoản riêng tư đối với ETH và các token ERC-20 phổ biến (thường là chuyển khoản giữa các ví của cùng một người). Bài viết này sẽ mô tả cơ chế và các trường hợp sử dụng của một loại công cụ khác, có khả năng nâng cao quyền riêng tư trên Ethereum trong nhiều tình huống: địa chỉ ẩn (stealth addresses).
Hệ thống địa chỉ ẩn là gì?
Giả sử Alice muốn gửi một tài sản cho Bob. Tài sản đó có thể là một lượng tiền mã hóa nhất định (ví dụ: 1 ETH, 500 RAI), hoặc cũng có thể là một NFT. Khi nhận tài sản, Bob không muốn cả thế giới biết mình là người nhận. Việc che giấu sự kiện một giao dịch đã xảy ra là điều không thể, đặc biệt nếu đó là một NFT độc nhất trên chuỗi, nhưng việc che giấu danh tính người nhận thì khả thi hơn. Alice và Bob cũng muốn mọi thứ đơn giản: họ mong muốn một quy trình thanh toán hoàn toàn giống như hiện tại. Bob chỉ cần gửi cho Alice (hoặc đăng ký trên ENS) một loại "địa chỉ" mã hóa đặc biệt, biểu thị cách thức người khác có thể gửi tiền cho anh ấy. Chỉ với thông tin duy nhất này, Alice (hoặc bất kỳ ai khác) đã có thể gửi tài sản cho Bob.
Lưu ý rằng điều này khác với quyền riêng tư mà các công cụ như Tornado Cash cung cấp. Tornado Cash có thể che giấu việc chuyển khoản các tài sản thay thế phổ biến như ETH hoặc các token ERC-20 chính (mặc dù nó dễ sử dụng nhất khi gửi riêng tư cho chính mình), nhưng lại kém hiệu quả trong việc bảo vệ quyền riêng tư cho các giao dịch ERC-20 ít phổ biến, và hoàn toàn không thể áp dụng cho các giao dịch NFT.
Quy trình thanh toán thông thường khi sử dụng tiền mã hóa. Mục tiêu của chúng ta là tăng cường quyền riêng tư (không ai có thể biết Bob là người nhận tài sản) trong khi vẫn giữ nguyên quy trình làm việc.
Địa chỉ ẩn chính là giải pháp cho vấn đề này. Đây là những địa chỉ mà Alice hoặc Bob có thể tạo ra, nhưng chỉ có Bob mới kiểm soát được. Bob tạo và giữ bí mật một khóa chi tiêu (spending key), sau đó dùng khóa này để tạo ra một địa chỉ siêu ẩn (stealth meta-address). Anh ấy gửi địa chỉ siêu ẩn này cho Alice (hoặc đăng ký trên ENS). Alice có thể thực hiện một phép tính trên địa chỉ siêu ẩn này để tạo ra một địa chỉ ẩn thuộc về Bob. Sau đó, cô ấy có thể gửi bất kỳ tài sản nào muốn tới địa chỉ này, và Bob sẽ hoàn toàn kiểm soát chúng. Trong quá trình chuyển khoản, Alice sẽ đăng tải một số dữ liệu mã hóa bổ sung lên chuỗi (một khóa công khai tạm thời), giúp Bob nhận diện được địa chỉ đó thuộc về mình.
Nói cách khác: địa chỉ ẩn mang lại mức độ riêng tư tương đương với việc Bob tạo một địa chỉ mới cho mỗi giao dịch, nhưng không yêu cầu Bob phải thực hiện bất kỳ tương tác nào.
Quy trình làm việc đầy đủ của một hệ thống địa chỉ ẩn được minh họa như sau:
1. Bob tạo khóa chi tiêu gốc (m) và địa chỉ meta ẩn danh (M) của mình.
2. Bob thêm một bản ghi vào ENS để đăng ký M làm địa chỉ meta ẩn danh cho tên miền bob.eth.
3. Giả sử Alice biết Bob sở hữu bob.eth. Cô tra cứu địa chỉ meta ẩn danh M của anh ấy trên ENS.
4. Alice tạo một khóa tạm thời chỉ dùng một lần và chỉ mình cô biết (dành riêng cho việc tạo địa chỉ ẩn danh này).
5. Alice sử dụng thuật toán kết hợp khóa tạm thời của mình với địa chỉ meta của Bob để tạo ra một địa chỉ ẩn danh. Giờ cô có thể gửi tài sản đến địa chỉ này.
6. Alice cũng tạo và đăng khóa công khai tạm thời của mình lên sổ đăng ký khóa công khai tạm thời (việc này có thể thực hiện trong cùng giao dịch đầu tiên khi gửi tài sản đến địa chỉ ẩn danh).
7. Để phát hiện địa chỉ ẩn danh thuộc về mình, Bob cần quét toàn bộ sổ đăng ký khóa công khai tạm thời, tìm kiếm danh sách các khóa được đăng tải kể từ lần quét gần nhất.
8. Với mỗi khóa công khai tạm thời, Bob thử kết hợp nó với khóa chi tiêu gốc của mình để tạo một địa chỉ ẩn danh, sau đó kiểm tra xem địa chỉ đó có chứa tài sản nào không. Nếu có, Bob tính toán khóa chi tiêu cho địa chỉ đó và lưu lại.
Toàn bộ quy trình dựa trên hai ứng dụng của kỹ thuật mật mã. Thứ nhất, chúng ta cần một cặp thuật toán để tạo bí mật chung: một thuật toán sử dụng yếu tố bí mật của Alice (khóa tạm thời) và yếu tố công khai của Bob (địa chỉ meta), thuật toán còn lại sử dụng yếu tố bí mật của Bob (khóa chi tiêu gốc) và yếu tố công khai của Alice (khóa công khai tạm thời). Có nhiều cách thực hiện việc này; trao đổi khóa Diffie-Hellman là một thành tựu nền tảng trong mật mã hiện đại, chính xác là để đạt được mục đích đó.
Tuy nhiên, chỉ có bí mật chung là chưa đủ. Nếu đơn thuần tạo khóa riêng từ bí mật chung, cả Alice và Bob đều có thể chi tiêu từ địa chỉ đó. Chúng ta có thể dừng lại và yêu cầu Bob chuyển tiền sang địa chỉ mới, nhưng cách này kém hiệu quả và làm giảm không cần thiết mức độ bảo mật. Do đó, chúng ta bổ sung cơ chế làm mù khóa: một cặp thuật toán cho phép Bob kết hợp bí mật chung với khóa chi tiêu gốc của mình, trong khi Alice kết hợp bí mật chung với địa chỉ meta của Bob. Nhờ vậy, Alice có thể tạo địa chỉ ẩn danh và Bob có thể tạo khóa chi tiêu cho địa chỉ đó — tất cả mà không tạo ra bất kỳ liên kết công khai nào giữa địa chỉ ẩn danh và địa chỉ meta của Bob (hoặc giữa các địa chỉ ẩn danh với nhau).
Địa chỉ ẩn danh sử dụng mật mã đường cong elliptic
Địa chỉ ẩn danh sử dụng mật mã đường cong elliptic lần đầu được Peter Todd giới thiệu vào năm 2014 trong bối cảnh Bitcoin. Cơ chế hoạt động của công nghệ này như sau (giả định người đọc đã có kiến thức nền về mật mã đường cong elliptic; tham khảo một số bài hướng dẫn tại đây, tại đây và tại đây):
• Bob tạo một khóa m và tính M = G * m, trong đó G là điểm sinh chung đã được thỏa thuận trên đường cong elliptic. Địa chỉ meta ẩn danh là dạng mã hóa của M.
• Alice tạo một khóa tạm thời r và đăng khóa công khai tạm thời R = G * r.
• Alice có thể tính bí mật chung S = M * r, trong khi Bob có thể tính cùng một bí mật chung S = m * R.
• Về cơ bản, trong Bitcoin và Ethereum (bao gồm cả tài khoản ERC-4337 được thiết kế đúng cách), địa chỉ là giá trị băm của khóa công khai dùng để xác minh giao dịch phát sinh từ nó. Vì vậy, nếu tính được khóa công khai, bạn có thể suy ra địa chỉ. Để tính khóa công khai, Alice hoặc Bob có thể tính P = M + G * hash(S).
• Để tính khóa riêng tư tương ứng với địa chỉ này, chỉ duy nhất Bob có thể tính p = m + hash(S). Điều này đáp ứng đầy đủ mọi yêu cầu và cực kỳ đơn giản!
Hiện nay thậm chí có một EIP đang nỗ lực định nghĩa chuẩn địa chỉ ẩn danh cho Ethereum, vừa hỗ trợ phương pháp này vừa mở ra không gian để phát triển các phương pháp khác (ví dụ: hỗ trợ Bob sở hữu riêng biệt khóa chi tiêu và khóa xem, hoặc sử dụng mật mã khác để đảm bảo khả năng chống tấn công lượng tử). Giờ đây, bạn có thể nghĩ rằng: địa chỉ ẩn danh không khó, lý thuyết đã rất vững chắc, việc áp dụng chỉ là vấn đề triển khai chi tiết. Tuy nhiên, vấn đề nằm ở chỗ việc triển khai thực sự hiệu quả đòi hỏi phải xử lý một số chi tiết kỹ thuật khá phức tạp.
Địa chỉ ẩn danh và phí giao dịch
Giả sử có ai đó gửi cho bạn một NFT. Để bảo mật thông tin, họ sẽ gửi NFT này đến một địa chỉ ẩn danh do bạn kiểm soát. Sau khi quét khóa công khai tạm thời (ephemeral public key) trên chuỗi, ví của bạn sẽ tự động phát hiện ra địa chỉ đó. Lúc này, bạn có thể tự do chứng minh quyền sở hữu hoặc chuyển nhượng NFT này cho người khác. Tuy nhiên, vẫn còn một vấn đề! Số dư ETH trong tài khoản này bằng 0, nên bạn không thể thanh toán phí giao dịch. Ngay cả cơ chế thanh toán token theo tiêu chuẩn ERC-4337 cũng không hoạt động, vì chúng chỉ áp dụng cho các token thay thế (fungible) ERC-20. Hơn nữa, bạn cũng không thể chuyển ETH từ ví chính sang địa chỉ này, vì hành động đó sẽ tạo ra một liên kết công khai rõ ràng.
Một cách giải quyết "đơn giản" là sử dụng ZK-SNARKs để chuyển tiền nhằm chi trả phí! Tuy nhiên, phương pháp này tiêu tốn rất nhiều gas, có thể làm tăng thêm hàng chục nghìn gas cho mỗi lần chuyển.
Một phương pháp thông minh hơn liên quan đến việc tin tưởng các bộ tổng hợp giao dịch chuyên biệt (hay còn gọi là "searchers" trong thuật ngữ MEV). Các bộ tổng hợp này cho phép người dùng thanh toán một lần để mua một tập hợp "vé" dùng để chi trả phí giao dịch trên chuỗi. Khi cần sử dụng NFT tại một địa chỉ ẩn danh không chứa bất kỳ tài sản nào khác, người dùng sẽ cung cấp một trong những "vé" này cho bộ tổng hợp, được mã hóa bằng sơ đồ làm mù Chaumian. Đây là giao thức gốc được sử dụng trong các hệ thống tiền điện tử bảo vệ quyền riêng tư tập trung, được đề xuất từ những năm 1980 và 1990. Người tìm kiếm chấp nhận "vé", sau đó liên tục đưa giao dịch vào gói giao dịch (bundle) của họ miễn phí cho đến khi giao dịch được đưa thành công vào một khối. Vì số tiền liên quan nhỏ và chỉ dùng để chi trả phí giao dịch, các vấn đề về niềm tin và quản lý sẽ thấp hơn nhiều so với việc triển khai "toàn diện" một hệ thống tiền điện tử bảo vệ quyền riêng tư tập trung.
Địa chỉ ẩn danh và tách biệt khóa chi tiêu với khóa xem
Giả sử Bob không muốn chỉ có một khóa chi tiêu "gốc" duy nhất thực hiện mọi chức năng, mà muốn tách biệt giữa khóa chi tiêu gốc và khóa xem. Khóa xem có thể xem tất cả các địa chỉ ẩn danh của Bob, nhưng không thể chi tiêu từ chúng.
Trong thế giới đường cong elliptic, vấn đề này có thể được giải quyết bằng một thủ thuật mật mã đơn giản:
• Địa chỉ siêu (meta-address) M của Bob giờ đây có dạng (K, V), được mã hóa dưới dạng G * k và G * v, trong đó k là khóa chi tiêu và v là khóa xem.
• Bí mật chia sẻ (shared secret) giờ đây là S = V * r = v * R, trong đó r vẫn là khóa tạm thời của Alice và R vẫn là khóa công khai tạm thời do Alice công bố.
• Khóa công khai của địa chỉ ẩn danh là P = K + G * hash(S), còn khóa riêng tư tương ứng là p = k + hash(S).
Lưu ý rằng bước mật mã đầu tiên (tạo bí mật chia sẻ) sử dụng khóa xem, trong khi 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 tư tương ứng) sử dụng khóa chi tiêu gốc.
Giải pháp này có nhiều ứng dụng thực tế. Ví dụ, nếu Bob muốn nhận POAP, anh ấy có thể cung cấp khóa xem cho ví POAP (hoặc thậm chí một giao diện web kém an toàn hơn) để quét chuỗi và xem tất cả POAP của mình, mà không cần trao quyền chi tiêu các POAP đó.
Địa chỉ ẩn danh và việc quét dễ dàng hơn
Để quét toàn bộ tập hợp khóa công khai tạm thời dễ dàng hơn, một kỹ thuật là thêm một thẻ xem (view tag) vào mỗi khóa công khai tạm thời. Một cách thực hiện trong cơ chế trên là làm cho thẻ xem trở thành một byte của bí mật chia sẻ (ví dụ: tọa độ x của S mod 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 elliptic cho mỗi khóa công khai tạm thời để tính bí mật chia sẻ, trong khi số lần Bob cần thực hiện các phép tính phức tạp hơn để tạo và kiểm tra địa chỉ đầy đủ chỉ chiếm 1/256.
Địa chỉ ẩn danh và khả năng chống tấn công lượng tử
Cơ chế trên phụ thuộc vào đường cong elliptic — điều này rất tốt, nhưng tiếc là lại dễ bị tấn công bởi máy tính lượng tử. Nếu máy tính lượng tử trở thành mối đe dọa thực sự, chúng ta sẽ cần chuyển sang các thuật toán kháng lượng tử. Hai ứng cử viên tự nhiên là: đồng cấu đường cong elliptic (elliptic curve isogenies) và mạng lưới (lattices).
Đồng cấu đường cong elliptic là một cấu trúc toán học đặc biệt, kế thừa tính tuyến tính cho phép áp dụng các kỹ thuật mật mã tương tự như đã đề cập, nhưng theo cách tinh vi hơn để tránh phải xây dựng các nhóm cyclic - vốn dễ bị máy tính lượng tử tấn công thông qua bài toán logarit rời rạc.
Nhược điểm chính của mật mã đồng cấu nằm ở nền tảng toán học cực kỳ phức tạp, tiềm ẩn nguy cơ các lỗ hổng bị che giấu trong chính độ phức tạp đó. Năm ngoái, một số giao thức dựa trên đồng cấu đã bị phá vỡ, dù các giao thức khác vẫn an toàn. Ưu điểm then chốt của phương pháp này là kích thước khóa tương đối nhỏ và khả năng chuyển đổi trực tiếp nhiều kỹ thuật từ đường cong elliptic.
Đồng cấu bậc 3 trong CSIDH. Nguồn: tại đây.
Lattice (lưới) là một cấu trúc mật mã hoàn toàn khác, dựa trên nền tảng toán học đơn giản hơn nhiều so với đồng cấu đường cong elliptic và có khả năng thực hiện những tác vụ cực kỳ mạnh mẽ (ví dụ: mã hóa đồng hình toàn phần – FHE). Các lược đồ địa chỉ ẩn hoàn toàn có thể được xây dựng trên lattice, dù việc thiết kế lược đồ tối ưu nhất vẫn là một bài toán mở. Tuy nhiên, các cấu trúc dựa trên lattice thường có kích thước khóa lớn hơn.
Mã hóa đồng hình toàn phần (FHE) – một ứng dụng nổi bật của lattice. FHE còn có thể hỗ trợ các giao thức địa chỉ ẩn theo cách khác: cho phép Bob thuê ngoài việc kiểm tra xem toàn bộ chuỗi có chứa địa chỉ ẩn nào sở hữu tài sản hay không, mà không cần tiết lộ khóa xem (view key) của mình.
Phương pháp thứ ba là xây dựng lược đồ địa chỉ ẩn từ các nguyên thủy hộp đen tổng quát – những thành phần cơ bản được nhiều người sử dụng vì các mục đích khác. Phần tạo bí mật chung của lược đồ này có thể ánh xạ trực tiếp sang trao đổi khóa, một thành phần quan trọng trong hệ thống mật mã khóa công khai. Thách thức lớn hơn là thiết kế một thuật toán song song sao cho Alice chỉ tạo ra địa chỉ ẩn (chứ không phải khóa chi tiêu), trong khi Bob mới là người tạo ra khóa chi tiêu.
Thật không may, bạn không thể xây dựng địa chỉ ẩn chỉ bằng những thành phần đơn giản hơn mức cần thiết để xây dựng hệ thống mật mã khóa công khai. Có một chứng minh đơn giản: bạn hoàn toàn có thể xây dựng một hệ thống mật mã khóa công khai từ một lược đồ địa chỉ ẩn. Nếu Alice muốn mã hóa một thông điệp gửi cho Bob, cô ấy có thể gửi N giao dịch, mỗi giao dịch hoặc gửi đến một địa chỉ ẩn của Bob, hoặc gửi đến một địa chỉ ẩn thuộc về chính cô ấy; Bob có thể xác định được mình nhận được những giao dịch nào để giải mã thông điệp. Điều này rất quan trọng vì đã có chứng minh toán học rằng bạn không thể chỉ dùng hàm băm để xây dựng mật mã khóa công khai, trong khi bạn hoàn toàn có thể chỉ dùng hàm băm để xây dựng chứng minh không tiết lộ thông tin (zero-knowledge proof) – do đó, địa chỉ ẩn không thể được thực hiện chỉ bằng hàm băm.
Dưới đây là một phương pháp thực tế sử dụng các thành phần tương đối đơn giản: chứng minh không tiết lộ thông tin (zero-knowledge proof), có thể được xây dựng từ hàm băm và mật mã khóa công khai (có tính ẩn khóa). Địa chỉ siêu cấp (meta-address) của Bob là một khóa mã hóa công khai cộng thêm một giá trị băm h = hash(x), còn khóa chi tiêu của anh ấy là khóa giải mã tương ứng cộng thêm x. Để tạo một địa chỉ ẩn, Alice sinh ra một giá trị c và đăng tải phiên bản được mã hóa của c dưới dạng khóa công khai tạm thời mà Bob có thể đọc được. Bản thân địa chỉ là một tài khoản ERC-4337, với mã hợp đồng yêu cầu giao dịch phải cung cấp một chứng minh không tiết lộ thông tin nhằm xác thực, chứng minh quyền sở hữu giá trị x và c sao cho k = hash(hash(x), c) (trong đó k là mã hợp đồng của tài khoản). Với kiến thức về x và c, Bob có thể tự tái tạo địa chỉ và mã hợp đồng tương ứng.
Việc mã hóa c sẽ không tiết lộ bất kỳ thông tin nào về c cho Bob hay bất kỳ ai khác, và k là một giá trị băm nên gần như không tiết lộ thông tin nào về c. Mã ví chỉ chứa k, trong khi c là riêng tư, nghĩa là k không thể truy ngược lại h.
Tuy nhiên, phương pháp này đòi hỏi một STARK, và STARK có kích thước rất lớn. Cuối cùng, tôi cho rằng thế giới Ethereum hậu lượng tử rất có thể sẽ liên quan đến nhiều ứng dụng sử dụng nhiều STARK, do đó tôi đề xuất các giao thức tập hợp như mô tả ở đây nhằm kết hợp tất cả các STARK này thành một STARK đệ quy để tiết kiệm không gian.
Địa chỉ ẩn, khôi phục xã hội và ví đa L2
Trong một thời gian dài, tôi luôn ủng hộ ví khôi phục xã hội (social recovery wallet): loại ví sử dụng cơ chế đa chữ ký, trong đó các khóa được chia sẻ giữa các tổ chức, thiết bị cá nhân và bạn bè, sao cho đa số các khóa này có thể khôi phục quyền truy cập vào tài khoản nếu bạn vô tình làm mất khóa chính.
Tuy nhiên, ví khôi phục xã hội không tương thích tốt với địa chỉ ẩn: nếu bạn phải khôi phục tài khoản (tức là thay đổi khóa riêng tư kiểm soát tài khoản), bạn cũng phải thực hiện nhiều bước để thay đổi logic xác thực cho N địa chỉ ẩn của mình. Điều này sẽ yêu cầu N giao dịch, kéo theo chi phí cao, giảm tiện lợi và ảnh hưởng đến tính riêng tư.
Tương tác giữa cơ chế khôi phục xã hội và các giao thức lớp 2 (L2) cũng dấy lên mối lo tương tự: nếu bạn có tài khoản trên Optimism, Arbitrum, Starknet, Scroll và Polygon, đồng thời sở hữu hàng chục phiên bản song song trên một số rollup để mở rộng quy mô, thì việc thay đổi khóa sẽ trở thành một thao tác cực kỳ phức tạp.
Thay đổi khóa cho hàng loạt tài khoản trên nhiều chuỗi là một công việc đồ sộ.
Một cách tiếp cận là chấp nhận cứng nhắc rằng việc khôi phục hiếm khi xảy ra, và chi phí cao cùng sự bất tiện là điều có thể chấp nhận được. Bạn cũng có thể sử dụng phần mềm tự động để chuyển tài sản sang một địa chỉ ẩn mới theo các khoảng thời gian ngẫu nhiên trong vòng hai tuần, nhằm giảm hiệu lực của việc liên kết dựa trên thời gian. Tuy nhiên, giải pháp này vẫn chưa hoàn hảo. Một phương án khác là chia sẻ khóa bí mật gốc giữa những người giám hộ thay vì dùng hợp đồng thông minh để khôi phục. Nhưng điều này sẽ loại bỏ khả năng vô hiệu hóa quyền trợ giúp khôi phục từ các giám hộ, dẫn đến rủi ro dài hạn.
Một phương pháp phức tạp hơn liên quan đến chứng minh không tiết lộ thông tin (zero-knowledge proof – ZKP). Hãy xem xét lại sơ đồ dựa trên ZKP đã nêu, nhưng điều chỉnh logic như sau: Thay vì tài khoản trực tiếp lưu giữ giá trị k = hash(hash(x), c), tài khoản sẽ lưu một cam kết (commitment) ẩn trên chuỗi đối với vị trí k. Khi thực hiện giao dịch t��� tài khoản này, người dùng phải cung cấp một chứng minh ZKP để chứng minh (i) bạn biết vị trí trên chuỗi khớp với cam kết nói trên, và (ii) đối tượng tại vị trí đó chứa một giá trị k (bạn không tiết lộ), đồng thời bạn sở hữu các giá trị x và c sao cho k = hash(hash(x), c).
Điều này cho phép nhiều tài khoản — thậm chí trải rộng trên nhiều giao thức lớp 2 — đều được kiểm soát bởi một giá trị k duy nhất (trên chuỗi nền tảng hoặc trên một số lớp 2). Chỉ cần thay đổi một giá trị duy nhất này là đủ để chuyển quyền sở hữu của tất cả các tài khoản, mà không làm lộ mối liên hệ giữa chúng.
Kết luận
Các địa chỉ ẩn (stealth address) cơ bản hiện nay có thể được triển khai khá nhanh chóng và sẽ cải thiện đáng kể tính riêng tư thực tế của người dùng trên Ethereum. Tuy nhiên, chúng đòi hỏi ví phải nỗ lực tích hợp để hỗ trợ chức năng này. Dù vậy, tôi cho rằng vì những lý do liên quan đến quyền riêng tư khác, các ví nên hướng tới mô hình đa địa chỉ mang tính bản địa hơn (ví dụ: tạo một địa chỉ mới cho mỗi ứng dụng bạn tương tác có thể là một lựa chọn khả thi).
Tuy nhiên, địa chỉ ẩn cũng đặt ra 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 khôi phục xã hội. Hiện tại, ta có thể tạm chấp nhận những lo ngại này, chẳng hạn bằng cách thừa nhận rằng khôi phục xã hội sẽ đi kèm với việc mất quyền riêng tư hoặc trì hoãn hai tuần để từ từ đăng các giao dịch khôi phục lên nhiều loại tài sản khác nhau (việc này có thể được xử lý bởi các dịch vụ bên thứ ba). Về lâu dài, những vấn đề này hoàn toàn có thể được giải quyết, tuy nhiên hệ sinh thái địa chỉ ẩn rõ ràng phụ thuộc mạnh mẽ vào chứng minh không tiết lộ thông tin (zero-knowledge proof).