Quyền riêng tư trong Ethereum - Địa chỉ ẩn

Nguồn: Cộng đồng Denglian

Giới thiệu

Một điểm khó khăn lớn mà người dùng mã hóa Web3 gặp phải là thiếu quyền riêng tư. Tất cả các giao dịch đều hiển thị trên sổ cái công khai và ngày càng được liên kết với tên ENS hiển thị rõ ràng, điều này khiến người dùng ít có động lực hơn để thực hiện một số hoạt động nhất định hoặc khiến họ thực hiện chúng theo cách gây thêm khó khăn cho người dùng khi trải nghiệm các hoạt động này. Một ví dụ đơn giản là chuyển tiền từ ví nóng sang ví lạnh hoặc ngược lại. Người dùng có thể không muốn một ví này được kết nối với một ví khác vì họ có thể không muốn số dư ví lạnh của mình bị lộ. Hiện tại, địa chỉ Ethereum không hoạt động giống như tài khoản ngân hàng tư nhân, vì mọi người đều có thể xem ví của bạn và ngày càng nhiều hoạt động xã hội của bạn (SBT, bằng chứng, hoạt động trên nhiều dapp khác nhau, v.v.) sẽ được nhìn thấy. Vì lý do này, Vitalik gọi quyền riêng tư là một trong ba chuyển đổi công nghệ lớn mà Ethereum cần phải trải qua để nó có ích cho người dùng bình thường.

Khi sử dụng các giải pháp bảo mật hiện có như Tornado Cash, trải nghiệm sẽ kém lý tưởng hơn vì nhiều lý do. Đầu tiên: người dùng sẽ lo lắng một cách chính đáng về việc địa chỉ của họ bị đưa vào danh sách đen trên các sàn giao dịch tập trung hoặc các nền tảng khác. Thứ hai, trải nghiệm người dùng tương tác với các dịch vụ như Tornado Cash không thân thiện với người dùng và thực sự chỉ phù hợp với những người dùng có trình độ cao.

Địa chỉ ẩn cung cấp cho người dùng quyền riêng tư tương tự như những gì họ được cấp trong tài khoản ngân hàng cá nhân nhưng theo cách dễ hiểu. Ngoài ra, sự đổi mới về địa chỉ ẩn có nghĩa là chúng tôi có thể thực hiện việc này theo cách tuân thủ các quy định chống rửa tiền trên nhiều khu vực pháp lý.

Nhu cầu của người dùng về quyền riêng tư

Mặc dù nghiên cứu về thái độ riêng tư của người dùng mạng và Web3 không sâu rộng, nhưng nghiên cứu sau đây đã được tìm thấy thông qua tìm kiếm trên mạng và kết quả gần như nhất quán, cho thấy nhu cầu rõ ràng về quyền riêng tư trong giao dịch.

1. Một cuộc khảo sát được thực hiện vào năm 2022 và được Simin Ghesmati et al. xuất bản trong một bài báo có tiêu đề Bài viết của người dùng nhận thức về quyền riêng tư trong blockchain nêu rõ rằng "Một nửa số người được hỏi nói rằng quyền riêng tư trong giao dịch là rất quan trọng đối với họ". Mặc dù nghiên cứu này phù hợp hơn với Bitcoin nhưng người dùng Ethereum có thể có thái độ tương tự. Tuy nhiên, cỡ mẫu của nghiên cứu này tương đối nhỏ (14 người tham gia).

2. Một nghiên cứu thú vị khác được thực hiện từ năm 2022 và được xuất bản trên Frontiers, có tiêu đề Thái độ chính trị, kinh tế và quản trị của người dùng blockchain, nghiên cứu này toàn diện hơn, khảo sát tổng cộng 3.710 người dùng tiền điện tử. Kết quả cho thấy khoảng 1/4 số người được hỏi cho biết quyền riêng tư là "tính năng quan trọng nhất trong blockchain và tiền điện tử".

Áp dụng giao thức giao dịch bí mật

Railgun Dữ liệu sử dụng rất ấn tượng, với việc sử dụng giao thức dường như tăng đều đặn theo thời gian, đạt tổng giá trị bị khóa (TVL) hơn 70 triệu USD và khối lượng giao dịch là 2 tỷ USD tính đến tháng 11 năm 2024.

Railgun TVL (USD) trên mạng chính Ethereum — Nguồn: Railgun — Số lượng người dùng DefiLlama

Umbra cũng tăng đều đặn (số người đăng ký bí mật tới ENS của họ), gần 77.000 tính đến tháng 11 năm 2024:

Số lượng người đã đăng ký tích lũy của Umbra (chuỗi chéo) — Nguồn: dune.com

Nếu chúng ta nhìn vào giao thức bảo mật được biết đến rộng rãi nhất (và không may là lại khét tiếng) trong Ethereum, Tornado Cash, chúng ta có thể thấy rằng mặc dù địa chỉ hợp đồng về mặt kỹ thuật là như vậy được đưa vào danh sách SDN của OFAC, nhưng nó vẫn được sử dụng nhiều.

Biểu đồ bên dưới hiển thị TVL của Tornado Cash theo thời gian. Chúng ta có thể quan sát thấy rằng bắt đầu từ mức đỉnh điểm vào khoảng tháng 10 năm 2021, đợt giảm giá lớn đầu tiên của TVL trùng với đợt bán tháo tổng thể trên thị trường tiền điện tử và đợt giảm giá lớn thứ hai xảy ra vào tháng 8 năm 2022, trùng với thời điểm OFAC niêm yết Tornado Cash. danh sách SDN, với mức giảm lớn thứ ba tương ứng với việc OFAC được chỉ định lại vào tháng 11 năm 2022. Tuy nhiên, kể từ đó, bất chấp các lệnh trừng phạt, việc sử dụng Tornado Cash vẫn tăng đều đặn, với TVL đạt gần 600 triệu USD. Đây là bằng chứng mạnh mẽ về sự cần thiết của quyền riêng tư giao dịch cơ bản trong Ethereum.

TVL (USD) Tornado Cash trên Ethereum Mainnet — Nguồn: Tornado Cash — DefiLlama

Thực trạng địa chỉ ẩn

Nghiên cứu này xác định 4 giải pháp chính hiện đang được sản xuất trên chuỗi EVM, đó là: p>

• Fluidkey

• < span href="https://www.umbra.cash/">Umbra

• Mê cung

• Railgun

Fluidkey và Umbra dựa trên các tiêu chuẩn Ethereum, đó là:

• < nhịp href="https://eips.ethereum.org/EIPS/eip-5564">ERC-5564: Giao thức địa chỉ ẩn

• ERC-6538: Đăng ký siêu địa chỉ tiền điện tử

Mê cung và Railgun là dựa trên giao thức zerocash (zcash cũng dựa trên điều này ), Giao thức sử dụng một nhóm được bảo vệ để người dùng gửi tiền vào. Zerocash sử dụng khái niệm “ghi chú”, về cơ bản là các biểu diễn giá trị bằng mật mã, cho phép các giao dịch riêng tư. Mỗi ghi chú bao gồm một giá trị ẩn, khóa chủ sở hữu và một số duy nhất (số không hợp lệ) sử dụng zk-SNARK để xác minh quyền sở hữu mà không tiết lộ chi tiết, từ đó chuyển giá trị trong ghi chú. Khi một ghi chú được chi tiêu, trình vô hiệu hóa của nó sẽ được tiết lộ để ngăn chặn việc chi tiêu gấp đôi, trong khi một ghi chú mới được tạo cho người nhận, tạo thành hệ thống UTXO trong một nhóm được bảo vệ.

Ở cấp độ cao, nguyên tắc cơ bản của địa chỉ ẩn là bên thứ ba có thể gửi tiền đến một địa chỉ chưa từng tồn tại và người nhận dự định có thể tìm và kiểm soát địa chỉ đó (tức là sau đó có thể tiêu tiền ).

Tiêu chuẩn erc-5564 chỉ định một cơ chế theo đó người nhận có thể xuất bản một địa chỉ meta mật mã mà từ đó các địa chỉ Ethereum mới có thể được lấy ra. Bất kỳ ai muốn gửi tiền cho người nhận đều có thể tạo một địa chỉ mới từ địa chỉ meta khó hiểu và cho phép người nhận tìm hiểu về số tiền mà không cần bất kỳ liên lạc trực tiếp nào. Tất cả việc triển khai địa chỉ ẩn đều dựa trên tiền đề cơ bản này.

Địa chỉ ẩn hoạt động như thế nào

Địa chỉ meta ẩn về cơ bản là sự kết hợp của hai khóa chung được nén, được gọi là "Khóa chi tiêu" và "Khóa xem" chìa khóa". Siêu địa chỉ ẩn sử dụng định dạng địa chỉ dành riêng cho chuỗi EIP-3770 có thêm tiền tố "st:". Dưới đây là ví dụ về địa chỉ ẩn:

st:eth:0x036ffa94a70a5b9608aca693e12da815fe0295f3739c7b22b0284c6d85c464ba4a02c0 521b6fe31714b2ca0efa159402574355b754e0b50406b0b5fb33128eec3507

Để đơn giản hóa, địa chỉ ẩn này có thể được so sánh với địa chỉ Ethereum thông thường (và do đó cũng ENS), giúp gửi tiền đến chủ sở hữu địa chỉ ẩn dễ dàng hơn. Để gửi tiền, người gửi phân tích địa chỉ trên và sử dụng tiêu chuẩn EIP-5564 để tạo khóa chung tạm thời mà địa chỉ ẩn được lấy từ đó. Người gửi gửi tiền đến địa chỉ ẩn mới, thường thông qua một hợp đồng đơn lẻ trong đó tất cả người nhận địa chỉ ẩn sẽ lắng nghe các sự kiện. Hợp đồng phát ra một sự kiện "thông báo" mà người nhận có thể đăng ký. Bất cứ khi nào một sự kiện thông báo được gửi đi, người nhận sẽ kiểm tra khóa chung tạm thời trong thông báo, kết hợp nó với khóa riêng đang xem của họ và xác định xem họ có khả năng chi tiêu số tiền được gửi đến địa chỉ ẩn hay không. Nếu vậy, ví/khách hàng họ đang sử dụng sẽ ghi nhớ địa chỉ ẩn và số tiền tương ứng rồi thêm nó vào số dư được hiển thị của người dùng. Để thực sự chi tiêu số tiền đó, họ có thể ký một giao dịch bằng khóa chi tiêu riêng của mình.

Sơ đồ sau đây cung cấp cái nhìn tổng quan rõ ràng hơn về toàn bộ quá trình:

Xin hãy nhớ rằng quá trình này hoàn toàn không tương tác, có nghĩa là người gửi và Ở đó không có liên lạc trực tiếp giữa người nhận, có nghĩa là thực sự không có liên kết nào giữa người gửi và người nhận mà bất kỳ bên thứ ba nào cũng có thể quan sát được.

Tuy nhiên, để việc này hoạt động bình thường, người nhận phải thông báo cho người gửi địa chỉ ẩn của họ. Một cách để đạt được điều này là sử dụng eip-6538 sổ đăng ký siêu địa chỉ mật mã. Đây là một hợp đồng đơn lẻ cho phép người dùng đăng ký địa chỉ meta ẩn thành địa chỉ Ethereum thông thường mà người gửi có thể tra cứu. Điều này cho phép người gửi phân giải địa chỉ thông thường từ ENS và sau đó tra cứu địa chỉ meta ẩn liên quan từ sổ đăng ký.

Kế hoạch này phá vỡ mối liên kết giữa người gửi và người nhận, cho phép cả hai tránh cho cả thế giới biết về công việc của họ. Tuy nhiên, có một số lưu ý:

• Khi người nhận tiêu tiền, người mà họ chuyển tiền sẽ biết rằng những khoản tiền đó tiền đến từ người gửi ban đầu (tức là họ có thể xem địa chỉ mà tiền đã được chuyển đến và ai trước đó đã gửi tiền đến địa chỉ đó). Điều này có nghĩa là chuỗi chuyển tiền vẫn còn nguyên vẹn và có thể theo dõi được, nhưng chúng chỉ được liên kết với người nhận được đề cập (trừ khi người nhận thực hiện hành động nào đó như gửi tiền đến một địa chỉ không lén lút mà họ biết). Lưu ý rằng điều này chỉ hoạt động với việc triển khai erc-5564, không phải Railgun hoặc Labyrinth.

• Một tác dụng phụ khác của các vấn đề trên là để duy trì quyền riêng tư tối ưu, người dùng có thể cần giữ tiền của mình ở địa chỉ ẩn mà họ được gửi ban đầu cho đến khi họ thực sự cần chúng, thay vì hợp nhất chúng dưới một địa chỉ. Điều này thể hiện chi phí bổ sung cho việc ghi nhớ địa chỉ và sau đó chi tiền cho các địa chỉ đó, vì số tiền bạn muốn chuyển cần phải được lấy từ sự kết hợp số tiền từ nhiều địa chỉ khác.

• Để chuyển tiền từ địa chỉ này, người nhận cần cung cấp một số ETH đến địa chỉ đó để thanh toán gas, điều này có thể khiến người nhận mất danh tính. Đây là một sự cố đã biết với các địa chỉ ẩn và là một trong những lý do khiến nhiều triển khai hỗ trợ eip-4337 và người trả tiền.

• Một nhược điểm của sơ đồ địa chỉ ẩn là người nhận cần giám sát chuỗi khối để biết các sự kiện Thông báo và kiểm tra từng thông báo để xác định xem họ có nhận được tiền hay không . Đây rõ ràng là một chi phí không thực tế đối với hầu hết người dùng, đặc biệt là khi nhận tiền từ nhiều mạng. Để làm cho quy trình này hiệu quả hơn, tiêu chuẩn chỉ định một "thẻ xem", là hàm băm rút gọn bắt nguồn từ bí mật chung có thể được sử dụng để loại bỏ nhanh chóng các giao dịch rõ ràng không dành cho họ. Bằng cách sử dụng tab Xem, hiệu suất không quá tệ trên máy tính để bàn nhưng có thể rõ ràng hơn trên thiết bị di động. Lần duy nhất sự suy giảm hiệu suất thực sự đáng chú ý là nếu ví đang phục hồi, trong trường hợp đó, ví cần quét mọi địa chỉ kể từ khi hợp đồng trực tuyến được triển khai, việc này rất tốn thời gian.

• Để giải quyết vấn đề này, người dùng có thể chọn chia sẻ khóa xem riêng tư với bên thứ ba đáng tin cậy. Dịch vụ bên thứ ba này giám sát các mạng khác nhau và thông báo cho người dùng khi họ nhận được tiền. Tất nhiên, điều này đi kèm với sự đánh đổi: trong khi các bên thứ ba thực sự không thể chi tiêu tiền của người dùng (họ không có khóa chi tiêu riêng), họ có thể thấy tất cả số tiền được gửi đến một người nhận cụ thể, điều đó có nghĩa là người dùng cần phải tin tưởng vào sự riêng tư của họ. Fluidkey thực hiện việc này theo mặc định.

• Giao thức địa chỉ ẩn tiêu chuẩn, ERC-5564, được thiết kế để hỗ trợ việc chuyển giao bảo vệ quyền riêng tư, tuy nhiên, các trường hợp sử dụng phi tài chính (chẳng hạn như gọi các chức năng hợp đồng thông minh tùy ý) yêu cầu kỹ thuật hơn, thường là triển khai cụ thể.

Ma trận so sánh

Chúng ta có thể so sánh bốn cách triển khai địa chỉ ẩn được thảo luận trong bài viết này theo nhiều cách khác nhau. Tất cả các quá trình triển khai đều có sự khác biệt và sự đánh đổi nhỏ, nhưng có lẽ những điểm rút ra quan trọng nhất là về khả năng truy xuất nguồn gốc và sự xáo trộn giá trị.

Mặc dù cả Fluidkey và Umbra đều cho phép chuyển tiền đến các địa chỉ Ethereum tiêu chuẩn đồng thời phá vỡ mọi liên kết đến danh tính của người nhận, nhưng họ vẫn giữ khả năng truy xuất nguồn gốc của giao dịch, nghĩa là người gửi không chịu trách nhiệm kiểm tra bất kỳ địa chỉ ẩn nào lịch sử giao dịch được hiển thị cho bất cứ ai. Điều này có nghĩa là nếu bạn nhận tiền tại một địa chỉ ẩn, người mà bạn quyết định gửi số tiền đó sẽ biết số tiền đó đến từ đâu. Ngoài ra, giá trị chuyển giao thực tế cũng được hiển thị. Railgun và Labyrinth ẩn người gửi và giá trị được gửi, nhưng phải trả giá bằng tất cả những điều đó xảy ra trong một hợp đồng duy nhất chứ không phải là một giao dịch thông thường tới một địa chỉ Ethereum thông thường.

Hình sau đây cho thấy các giao thức mà chúng ta thảo luận trong bài viết này so sánh với nhau như thế nào theo hai khía cạnh so sánh quan trọng này.

Để khám phá những khác biệt này một cách chi tiết hơn, đây là ma trận so sánh của bốn giao thức địa chỉ ẩn chính dọc theo sáu khía cạnh chính:

< li >

Quyền riêng tư hoàn toàn từ đầu đến cuối (chỉ người gửi và người nhận mới thấy thông tin thanh toán)

1. Chuyển tiếp bí mật. Số tiền nhận được thông qua giao dịch ẩn không cho phép người nhận thứ hai nhìn thấy nguồn tiền

2. Tuân theo tiêu chuẩn erc-5564 và erc-6538

< li>

Triển khai kiến ​​trúc mô-đun có thể mở rộng cho phép tích hợp với các dapp của bên thứ ba

3. Việc triển khai có cung cấp SDK mà nhà phát triển có thể sử dụng để tích hợp không?

4. Giải pháp này có cung cấp sự tuân thủ thông qua một số hình thức hỗ trợ khử ẩn danh không?

5. Thiết kế có hỗ trợ việc che giấu số lượng/giá trị được chuyển không?

Các phần sau đây trình bày chi tiết hơn một số sắc thái và sự khác biệt bổ sung. Mỗi cách triển khai đều có những sắc thái thú vị có thể có hoặc không ảnh hưởng đến trường hợp sử dụng của bạn.

Ví dụ: trong Fluidkey: tất cả các giao dịch đều chuyển trực tiếp đến địa chỉ ẩn trên chuỗi, trong khi ở Umbra**:** chỉ ETH đi đến địa chỉ ẩn trên chuỗi và mã thông báo đi đến địa chỉ ẩn hợp đồng trung tâm, với Railgun, giống như Labyrinth, có tất cả các giao dịch đi đến hợp đồng cốt lõi thay vì trực tiếp đến một địa chỉ ẩn trên chuỗi.

Khám phá sâu sắc việc triển khai các địa chỉ ẩn

Fluidkey

Fluidkey là một triển khai erc-5564 cho phép người dùng gửi, nhận, trao đổi và kết nối các mã thông báo ETH và erc-20. Tại thời điểm viết bài, Fluidkey được triển khai trên Base, Optimism, Arbitrum, Polygon, Gnosis và mạng chính Ethereum.

Người dùng tương tác với Fluidkey thông qua giao diện người dùng web của nó. Khi họ đăng nhập lần đầu bằng ví, họ sẽ ký một thông báo tạo khóa để lấy khóa xem và chi tiêu của họ. Các khóa tương tự này được tạo lại theo cùng một cách mỗi khi người dùng vào ứng dụng.

Fluidkey khác với các cách triển khai khác ở một số điểm. Một trong những điểm khác biệt là người dùng chia sẻ khóa xem riêng tư của họ với Fluidkey (thực ra là BIP-32 nút dẫn xuất). Điều này cho phép Fluidkey tạo địa chỉ ẩn cho người dùng và thông báo cho người dùng khi họ nhận được khoản thanh toán tới các địa chỉ đó. Tuy nhiên, điều này cũng có nghĩa là Fluidkey có khả năng xem các giao dịch và số dư đến của người dùng, đây là một sự đánh đổi. Tuy nhiên, Fluidkey vẫn hoàn toàn tự quản lý.

Một khía cạnh thú vị khác trong thiết kế của Fluidkey là nó triển khai tài khoản hợp đồng thông minh cho mỗi địa chỉ ẩn mới. Điều này sẽ chỉ xảy ra nếu số tiền được tài trợ từ địa chỉ bị che giấu được sử dụng. Tài khoản thông minh là tài khoản bảo mật 1/1 cho phép thực hiện các hoạt động như tài trợ gas, giúp quản lý các địa chỉ ẩn khác nhau dễ dàng hơn. Để biết thêm thông tin về vấn đề này, hãy xem hướng dẫn kỹ thuật của họ.

Mặc dù Fluidkey vẫn duy trì khả năng hiển thị đối với tài khoản người dùng, điều này có thể là một lợi thế khi tuân thủ, nhưng khuôn khổ chính xác về cách Fluidkey sẽ xử lý các yêu cầu thực thi pháp luật tiềm năng trong tương lai vẫn chưa được công khai. Họ có trụ sở tại Thụy Sĩ và mặc dù phải tuân theo luật pháp địa phương nhưng luật bảo vệ dữ liệu rất rõ ràng và mạnh mẽ - phải có lý do rất rõ ràng để chia sẻ dữ liệu và vấn đề phải được tòa án xem xét (Xem bài viết này để có cái nhìn tổng quan tuyệt vời về luật quyền riêng tư của Thụy Sĩ).

Người dùng cũng hoàn toàn có thể xuất các giao dịch của mình hoặc chia sẻ khóa xem của họ với các bên thứ ba (chẳng hạn như kế toán), điều này đặc biệt hữu ích cho các doanh nghiệp. Điều đáng lưu ý là theo thông số kỹ thuật erc-5564, việc chia sẻ khóa công khai là "tất cả hoặc không", nghĩa là nó không thể tự mình tiết lộ cho một giao dịch riêng lẻ. Ngoài ra, giống như tất cả các hoạt động triển khai erc-5564, khả năng truy xuất nguồn gốc không bị gián đoạn—chỉ có mối tương quan với người dùng—có nghĩa là lịch sử giao dịch của từng địa chỉ ẩn sẽ được công khai cho bất kỳ ai có khóa xem. Một tính năng ít được biết đến của Fluidkey là khả năng xoay các phím xem, cho phép người dùng sử dụng phím xem mới mỗi tháng và chỉ chia sẻ quyền truy cập xem trong một tháng cụ thể với bên thứ ba.

Một lợi ích của phương pháp Fluidkey là bản thân địa chỉ ẩn không phải do người gửi tạo ra mà được Fluidkey tạo giả ngẫu nhiên mỗi khi truy vấn ENS. Việc này nhanh hơn vì người dùng không phải quét qua các sự kiện thông báo để xác định các giao dịch mà họ là người nhận. Điều này cũng có nghĩa là người gửi không cần ví địa chỉ ẩn để tạo địa chỉ ẩn cho người nhận - họ chỉ cần gửi tiền như bất kỳ địa chỉ nào khác. Điều này cũng có nghĩa là không có hợp đồng đăng ký nào liên quan, đây là điểm độc đáo trong thiết kế của Fluidkey và là một lợi thế lớn.

Điều đáng nói là Fluidkey cam kết tự quản lý hoàn toàn và họ đã mở nguồn thư viện bộ công cụ tài khoản tàng hình của mình và trong trường hợp Fluidkey biến mất chỉ sau một đêm, họ sẽ có thể có một số bộ công cụ được phát triển độc lập giao diện khôi phục có sẵn, nghĩa là tiền không bao giờ bị khóa hoặc bị kẹt.

Tóm tắt địa chỉ

Bằng cách sử dụng tài khoản hợp đồng thông minh, Fluidkey có thể tự động trừu tượng hóa và quản lý từng địa chỉ ẩn. Điều này có nghĩa là nếu bạn muốn chuyển một số tiền cụ thể cho một người nhận cụ thể từ số dư của mình ở nhiều địa chỉ ẩn khác nhau, Fluidkey có thể tự động tính toán tổ hợp địa chỉ để chuyển tiền, xử lý tất cả phí gas và triển khai hợp đồng, tất cả đều diễn ra trong nền. Fluidkey cũng cho phép người dùng có một số quyền kiểm soát đối với những địa chỉ nào được kết hợp thông qua một tính năng thú vị được gọi là thẻ, cho phép người dùng gắn thẻ địa chỉ vào các danh mục khác nhau.

Độ phân giải ENS

Fluidkey yêu cầu người dùng tạo tên ENS duy nhất cho Fluidkey. Các tên tĩnh này có hai dạng: username.fkey.id và username.fkey.eth, một dạng là URL tới giao diện web để gửi tiền cho ai đó và dạng còn lại là tên ENS tiêu chuẩn có thể được sử dụng với ví.

ENS được thiết lập bằng cách sử dụng Trình phân giải ngoại tuyến ENS (còn được gọi là erc-3668: CCIP Read) để trả về địa chỉ ẩn. Mỗi khi trình phân giải ngoại tuyến được truy vấn, nó sẽ tạo và trả về một địa chỉ ẩn mới cho tên ENS tương ứng. Đây là một tính năng tuyệt vời vì nó cho phép người dùng có một tên ENS mà con người có thể đọc được trong khi vẫn giữ được quyền riêng tư của địa chỉ ẩn, vì địa chỉ ẩn thu được không thể truy ngược lại tên ENS.

Phí

Fluidkey được sử dụng miễn phí và không mất phí. Khi bạn muốn tiêu tiền, mỗi địa chỉ có tiền sẽ phải trả một khoản phí để triển khai Hợp đồng an toàn. Tuy nhiên, mặc dù tương đối đắt trên mạng chính, nhưng điều này thực tế không đáng kể trên L2, thường dưới 1 xu, ngay cả khi kết hợp nhiều địa chỉ lén lút vào một lần chuyển.

Họ cũng có thể tài trợ gas thông qua Triển khai an toàn - họ tính toán chi phí gas và khấu trừ từ số dư của người dùng, ngay cả khi đó là mã thông báo - trong trường hợp này, người giao nhận triển khai An toàn và chuyển mã thông báo trên thay mặt người dùng.

Umbra Cash

Umbra là eip-5564 + eip6538 được triển khai bởi href="https://scopelift.co/">Scopelift. Khi người dùng đăng nhập vào ứng dụng Umbra, họ sẽ trải qua giai đoạn thiết lập trong đó họ ký một tin nhắn từ đó lấy được khóa chi tiêu và xem cũng như địa chỉ meta ẩn tương ứng. Sau đó, họ đăng ký địa chỉ meta tàng hình này vào sổ đăng ký trực tuyến của địa chỉ ví chính của họ. Đây là điểm mà việc triển khai khác với Fluidkey.

Việc triển khai erc-5564 của Umbra gần nhất với thông số kỹ thuật vì họ không có quyền truy cập vào khóa của người dùng. Mặc dù điều này có nghĩa là Umbra (hoặc bất kỳ ai khác) không thể nhìn thấy tiền của người dùng, nhưng điều đó có nghĩa là để nhận được tiền, người gửi phải có ví tuân thủ ERC-5564 (hoặc ứng dụng Umbra) để tạo địa chỉ meta ẩn của họ.

Khi ai đó muốn gửi tiền tới Khi người dùng thực hiện việc này, họ thường sử dụng ứng dụng Umbra. Về cơ bản, ứng dụng Umbra tìm kiếm địa chỉ meta ẩn được đăng ký với tên/địa chỉ ví ENS và tạo địa chỉ ẩn. Người nhận có thể đăng nhập vào ứng dụng Umbra và quét mọi khoản tiền được gửi đến địa chỉ ẩn thuộc về họ kể từ lần đăng nhập cuối cùng của họ. Nhờ một số bộ nhớ đệm thông minh, quá trình này dường như chỉ mất 10-15 giây cho lần quét hàng tuần, mặc dù người dùng cũng có thể chọn chỉ định phạm vi khối để thu hẹp phạm vi quét. Umbra v2 sẽ bao gồm việc sử dụng thẻ xem, điều này sẽ giúp đẩy nhanh quá trình hơn nữa.

Người chuyển tiếp

Một vấn đề với các địa chỉ bị che giấu mà chúng tôi đã đề cập trước đó là để người nhận chi tiêu số tiền được gửi đến địa chỉ bị che giấu, địa chỉ ETH hoặc các token gas cần thiết khác được yêu cầu phải trả phí giao dịch. Trên hầu hết các mạng, điều này thường không thành vấn đề nếu địa chỉ ẩn ban đầu nhận được ETH. Tuy nhiên, nếu một địa chỉ ẩn nhận được mã thông báo erc-20 hoặc NFT, hành động gửi địa chỉ đó bằng ETH có thể liên kết địa chỉ đó với các địa chỉ khác của người dùng, do đó làm mất quyền riêng tư.

Để giải quyết vấn đề này, Umbra sử dụng cấu trúc liên quan đến người chuyển tiếp. Khi bất kỳ tài sản không phải ETH nào được gửi đến người dùng Umbra, nó thực sự được gửi đến một hợp đồng đặc biệt thay vì trực tiếp đến một địa chỉ ẩn. Người dùng có thể chi tiêu số tiền được gửi đến địa chỉ ẩn của họ bằng cách gửi siêu giao dịch (từ ứng dụng Umbra) đến người giao nhận của Umbra, người sẽ thay mặt người dùng chuyển tiền từ hợp đồng thông minh. Những người đăng lại sẽ khấu trừ một số mã thông báo để trang trải chi phí gas và ban đầu chỉ một số lượng mã thông báo nhất định sẽ được hỗ trợ.

Phí

Hợp đồng Umbra cũng tính một khoản phí nhỏ khi chuyển tiền trên mạng có phí giao dịch thấp để hạn chế thư rác. Lý do là thư rác làm tăng chi phí quét giao dịch để xác định các giao dịch có liên quan nên đây được coi là một sự đánh đổi có thể chấp nhận được.

Mạng được hỗ trợ

Umbra hiện được triển khai trên mạng chính Ethereum, cũng như Optimism, Polygon, Gnosis Chain và Arbitrum.

Hợp đồng đăng ký Umbra có thiết kế thú vị. Phương thức triển khai sử dụng create2 và trình triển khai create2 tiêu chuẩn, đồng thời địa chỉ hợp đồng thông minh giống nhau trên bất kỳ mạng nào. Điều này có nghĩa là nếu có một hợp đồng tồn tại trên một mạng nhất định, khách hàng có thể đảm bảo rằng đó là hợp đồng chính xác. Khách hàng có thể được cấu hình để thêm mạng và bất kỳ ai cũng có thể triển khai vào bất kỳ mạng nào. Họ đã bình thường hóa mã byte để các hợp đồng không có chủ sở hữu, điều này cho phép mọi người triển khai các hợp đồng đăng ký và thông báo trên bất kỳ chuỗi nào mà không được phép.

Umbra v2

Scopelift hiện đang phát triển Phiên bản 2 của Umbra, giới thiệu kiến ​​trúc mô-đun mới cho phép mở rộng hợp đồng cốt lõi để hỗ trợ các tiêu chuẩn mã thông báo mới hoặc các trường hợp sử dụng không thanh toán. Bằng cách sử dụng kiến ​​trúc mới này, các nhà phát triển bên thứ ba có thể xây dựng mô-đun cho bất kỳ loại tiêu chuẩn mã thông báo nào, chẳng hạn như erc-1155, erc-7621, hỗ trợ cho người trả tiền erc-4337 hoặc bất kỳ điều gì khác mà bạn có thể nghĩ tới. Hiện tại, hợp đồng lõi Umbra hỗ trợ hai kịch bản, một cho ETH và một cho erc-20. V2 sẽ hỗ trợ nhiều kịch bản khác nhau.

Mê cung

Mê cung không dựa trên eip-5564 + eip6538 giao thức, thay vào đó sử dụng bằng chứng không có kiến ​​thức để thêm tính ẩn danh và quyền riêng tư cho các giao dịch. Sách trắng của Labyrinth mô tả nó như một phần mềm trung gian "zkFi": "zkFi cung cấp một giải pháp đóng gói hoạt động như một phần mềm trung gian về quyền riêng tư có tính năng tuân thủ tích hợp". Tuân thủ tích hợp đề cập đến “khử ẩn danh có chọn lọc” của Labyrinth, một giải pháp phức tạp cho phép hủy ẩn danh một số giao dịch nhất định đối với các bên được ủy quyền cụ thể (tức là các cơ quan pháp lý như Interpol, v.v.) trong khi vẫn duy trì tính minh bạch và cởi mở.

Các hợp đồng thông minh cốt lõi được Labyrinth sử dụng bao gồm nhóm đa giao dịch và đa tài sản, cho phép người dùng giao dịch nhiều tài sản trong một giao dịch. Để chi tiêu tài sản, người dùng quét mạng và lấy dữ liệu vé được mã hóa, giải mã vé và lọc ra tài sản họ muốn chi tiêu. Sau đó, người dùng tạo ZKP bao gồm giao dịch và khóa ký cho ghi chú liên quan đến giao dịch mà họ muốn chi tiêu.

Một phần của hợp đồng cốt lõi Labyrinth bao gồm một hợp đồng chuyển đổi có giao diện với các hợp đồng proxy mô-đun, về cơ bản là các proxy cho các hợp đồng bên ngoài. Vì vậy, ví dụ: Nếu người dùng muốn tương tác với Uniswap bằng Labyrinth, thì người dùng sẽ xây dựng một giao dịch sử dụng hợp đồng chuyển đổi để gọi một hoạt động hoán đổi trên nhóm Uniswap thông qua hợp đồng proxy của Uniswap.

Giao thức zkFi của Labyrinth sử dụng “vé” để theo dõi số dư và chuyển khoản. Ghi chú về cơ bản là một cấu trúc dữ liệu mô tả một lượng tài sản nhất định và địa chỉ của nó. Khách hàng lưu trữ thông tin cần thiết để xây dựng lại vé và sử dụng thông tin này để chi tiêu tài sản. Cam kết đối với ghi chú (mã băm của ID nội dung, chủ sở hữu và giá trị) được lưu trữ trong cây Merkle trên chuỗi. Trên thực tế, Labyrinth sử dụng hai cây Merkle, một cây dành cho vé và một cây dành cho địa chỉ gốc.

Cấu trúc dữ liệu ghi chú chứa nội dung sau:

• assetId: nội dung được đại diện bằng mã định danh ghi chú này (ETH, WBTC, MATIC, v.v.).

• giá trị: Giá trị hoặc số tiền được biểu thị bằng tờ tiền.

• leafIndex: Chỉ mục nút lá của cây Merkle hứa hẹn mà ghi chú này sẽ được chèn vào.

• làm mù: Yếu tố bảo vệ ngẫu nhiên.

• rootAddress: Địa chỉ gốc của người dùng có quyền chi tiêu.

• revoker: Điểm khóa công khai của người thu hồi được chọn.

Bạn sẽ nhận thấy cấu trúc dữ liệu trên không chứa bất kỳ tham chiếu nào đến chủ sở hữu của nội dung, điều này thật lạ vì trong ghi chú Merck Cam kết được ghi trong cây là hàm băm của ID, giá trị và chủ sở hữu tài sản. Trong thực tế, chủ sở hữu được tính toán từ địa chỉ gốc, người hoàn tác và hệ số bảo vệ ngẫu nhiên, do đó, đối với người quan sát bên ngoài, chủ sở hữu thực sự là một địa chỉ mới được tạo với mỗi giao dịch mới.

Protection Pool

Điều đặc biệt thú vị về Labyrinth là nó hơi khác so với các giao thức dựa trên địa chỉ ẩn truyền thống ở chỗ nhóm tài sản thực sự là một Nhóm được bảo vệ, tận dụng khái niệm ghi chú để tạo nhóm UTXO được bảo vệ nhằm cung cấp bí mật chuyển tiếp cho các giao dịch. Hãy nhớ lại rằng trong quá trình triển khai eip-5564, người nhận chuyển khoản của người dùng sẽ có thể nhìn thấy nguồn gốc của số tiền đó. Nói cách khác, Alice trả tiền cho Bob bằng địa chỉ lén lút và Bob trả tiền cho Charlie, vì vậy giờ đây Charlie có thể thấy rằng ban đầu Bob đã nhận những khoản tiền này từ Alice, v.v. Đây không phải là trường hợp với bể bảo vệ của Mê cung.

Để hiểu cách hoạt động của nhóm bảo vệ này, chúng ta cần xem xét cách chuyển tiền trong giao thức:

Số dư của người dùng trong nhóm bảo vệ là một trong những lưu ý cho nhóm tương ứng tài sản và. Để chi tiêu các ghi chú này, người dùng cần tiết lộ "cờ không hợp lệ" của các ghi chú đó. ID không hợp lệ được liên kết duy nhất với ghi chú và sau khi ghi chú được chi tiêu, ID không hợp lệ sẽ được đánh dấu để ngăn chặn việc chi tiêu hai lần và ghi chú mới sẽ được tạo dựa trên ghi chú đã chi tiêu. Nhiều ghi chú cho cùng một nội dung có thể được hợp nhất và có thể tạo nhiều ghi chú mới. Mã định danh không hợp lệ chỉ đơn giản là hàm băm của (?,?,?), trong đó ? là chỉ số cam kết của ghi chú trong cây Merkle của ghi chú, ? là phần tử ngẫu nhiên còn được gọi là yếu tố bảo vệ.

Người nhận chuyển giao giao dịch lén lút xác định giao dịch chuyển tiền theo cách tương tự như eip-5564, trong đó họ lắng nghe các sự kiện phát ra từ hợp đồng cốt lõi và xác định địa chỉ ẩn mà họ có thể gửi tiền, ghi nhật ký cục bộ các địa chỉ này. Tốc độ xác định số tiền đến cũng được cải thiện bằng cách tận dụng thẻ xem và bộ nhớ đệm cục bộ không đồng bộ cũng như đồng bộ hóa ghi chú trong suốt vòng đời của ứng dụng.

Nghiên cứu hiện đang được tiến hành để đẩy nhanh quá trình khám phá nhằm nhận được tài trợ, hãy xem đề xuất này từ Aztec: Yêu cầu đề xuất: Giao thức khám phá ghi chú — Aztec.

Về việc chi tiêu, người dùng cũng phải tạo bằng chứng zk, không giống như việc triển khai erc-6654 về cơ bản là một địa chỉ Ethereum thông thường. Việc tạo bằng chứng yêu cầu một ví tương thích và hoạt động tương đối tốt, mất khoảng 20 giây hoặc lâu hơn trên thiết bị Android tầm trung.

Nhà đóng gói và Nhà chuyển đổi

Labyrinth cung cấp một số tính năng thú vị giúp giải quyết một số điểm khó khăn trong giao dịch lén lút. Các giao dịch được gửi đến hợp đồng lõi Labyrinth được gửi dưới dạng thao tác của người dùng thông qua trình đóng gói erc-4337. Thiết lập này cho phép chi tiêu ghi chú mà không cần ETH hoặc mã thông báo gas từ giao dịch, vì người dùng có thể tận dụng những người trả tiền erc-4337 để trả gas cho họ, thêm một lớp bảo mật bổ sung. Ngoại lệ duy nhất là khoản tiền gửi ban đầu không được gửi dưới dạng hành động của người dùng. Một lợi ích khác của việc sử dụng người trả tiền erc-4337 là khả năng thanh toán tiền gas bằng tài sản được chuyển nhượng, ngay cả khi chúng là mã thông báo erc-20, vì vậy Labyrinth hiển thị API oracle về giá gas.

Một tính năng rất hay khác của Labyrinth là kiến ​​trúc mô-đun, cho phép các hợp đồng chuyển đổi hoạt động như proxy cho các ứng dụng phi tập trung của bên thứ ba. Điều này không chỉ cho phép người dùng chuyển tiền bằng các giao dịch lén lút mà còn tương tác với các ứng dụng phi tập trung của bên thứ ba như DEX như Uniswap, Aave, Lido, v.v. Các hợp đồng "Bộ chuyển đổi" proxy này về cơ bản thực hiện chức năng nhận đầu vào của một nội dung nhất định và xuất ra một số nội dung. Logic cơ bản tồn tại trong hợp đồng bên thứ ba.

Giải pháp tuân thủ

Labyrinth đảm bảo sự tuân thủ và tuân thủ quy định thông qua một khuôn khổ có tên là Xác định tên có chọn lọc (SeDe).

Hãy nhớ lại rằng cấu trúc dữ liệu của ghi chú có chứa một trường có tên là "hoàn tác bởi". Người thu hồi là địa chỉ của một thực thể cụ thể có thể bắt đầu quá trình khử ẩn danh. Người dùng phải chọn ít nhất một người thu hồi từ danh sách được xác định trước. Người thu hồi không chịu trách nhiệm duy nhất trong việc xác định hoạt động có khả năng bất hợp pháp hoặc không phù hợp nhưng có thể đáp ứng yêu cầu từ các cơ quan thực thi pháp luật.

Người hoàn tác không có khả năng duy nhất là trực tiếp hủy ẩn danh các giao dịch nhưng họ chịu trách nhiệm thực hiện các yêu cầu hủy ẩn danh. Những yêu cầu này được đăng công khai lên Guardian, một hội đồng gồm các đơn vị giám sát quyền riêng tư và tuân thủ. Người giám hộ phải bỏ phiếu xem có cho phép các giao dịch hủy danh tính hay không. Nếu người giám hộ có thể đạt được số đại biểu và bỏ phiếu ủng hộ, người hoàn tác có thể giải mã dữ liệu giao dịch, liên kết các giao dịch có liên quan với các giao dịch trước đó cho đến khi chuỗi giao dịch được khử ẩn danh hoàn toàn.

Hệ thống này tạo ra một loạt các kiểm tra và cân bằng, bởi vì người giám hộ không thể quyết định tiết lộ dữ liệu giao dịch một mình và ngay cả khi họ thông đồng, họ không thể làm bất cứ điều gì nếu không có người hoàn tác, và một mình người hoàn tác không thể. Người giám hộ làm mọi việc theo đa số bỏ phiếu.

Railgun

RAILGUN là một nền tảng dựa trên Ethereum, Binance Smart Chain, Đa giác và trọng tài Hệ thống bảo mật giao dịch bí mật được triển khai trên. Giao thức này tương tự như Labyrinth ở một số điểm, ở chỗ nó dựa trên các ghi chú, được lưu trữ dưới dạng cam kết trong cây Merkle, tạo thành một bộ UTXO, tức là bằng cách tạo ghi chú mới cho chi tiêu của người nhận khác. Điều này có nghĩa là chỉ chủ sở hữu của một ghi chú mới có thể tính toán ID vô hiệu của nó, ID này thường được tạo từ hàm băm của khóa chi tiêu và chỉ mục của ghi chú trong cây Merkle.

Các địa chỉ meta khó hiểu trong Railgun sử dụng tiền tố "0zk", tương tự như eip-5564, là sự kết hợp giữa khóa xem công khai và khóa chi tiêu công khai. Tuy nhiên, Railgun sử dụng khóa Ed25519 trên đường cong BabyJubJub thay vì ECDSA và secp256k1. Giống như eip-5564, người dùng quét tất cả các sự kiện được phát ra trong hợp đồng Railgun và sử dụng khóa xem của họ để xác định sự kiện nào đại diện cho việc chuyển tiền vào ví của họ.

Railgun sử dụng mạng các đài truyền hình thực chất là những người chuyển tiếp nhận các siêu giao dịch của người dùng và phát các giao dịch thực tế tới chuỗi khối tương ứng thay mặt cho người dùng Trả phí gas. Các giao dịch giữa người dùng với đài truyền hình được mã hóa và giao tiếp bằng giao thức Waku, bảo vệ tính ẩn danh của người dùng cuối.

Railgun có kiến ​​trúc mô-đun cho phép nó tương tác với các hợp đồng thông minh bên ngoài, cung cấp chức năng ngoài việc chuyển giao đơn giản. Nó đạt được điều này thông qua hợp đồng AdaptRelay, đảm bảo và không bảo vệ mã thông báo trước và sau khi tương tác với các hợp đồng bên ngoài, ví dụ: không bảo vệ mã thông báo A, trao đổi mã thông báo trên một số mã thông báo AMM B, bảo vệ mã thông báo B trở lại chủ sở hữu ban đầu .

Trong phiên bản 3, Railgun có kế hoạch tận dụng eip-4337 và hỗ trợ các giao dịch meta truyền thống. Họ hy vọng có thể cho phép những người giải quyết độc lập tham gia với tư cách là người phát sóng bằng cách duy trì nhóm bộ nhớ người dùng eip-4337 dành riêng cho Railgun. Họ hiện đang làm việc với Umbra để nghiên cứu vấn đề này và xác định các trường hợp nguy hiểm cũng như cách giải quyết chúng, thông tin chi tiết hơn trong phần Railgun v3 bên dưới.

Phí

Giao thức Railgun tính phí 0,25% đối với tiền gửi và rút tiền. Các khoản phí này sẽ được gửi đến kho bạc DAO, khoản phí này sẽ được thanh toán theo thời gian cho những người đặt cược mã thông báo quản trị RAIL. Ngoài phí gửi và rút tiền 0,25%, các đài truyền hình thường tính phí riêng của họ, thường là khoảng 10% phí gas cho các giao dịch thực tế trên chuỗi.

Quản trị

Railgun có hệ thống quản trị cho phép gửi bất kỳ hình thức đề xuất nào và mọi thay đổi đối với hợp đồng cốt lõi (bao gồm cả hợp đồng tài chính và quản trị) phải thông qua DAO Đề xuất mới có thể được thực hiện. Điều bất thường là các phiên bản khác nhau của Railgun có cách quản lý riêng. Ví dụ: Railgun có hệ thống quản trị và mã thông báo riêng biệt trên Ethereum, Polygon và Binance Chain.

SDK và Cookbook

Railgun cung cấp SDK toàn diện và được ghi chép đầy đủ mà các nhà phát triển ví hoặc DApp có thể sử dụng để hỗ trợ xây dựng chức năng địa chỉ ẩn của Railgun. Railgun cũng có một sách dạy nấu ăn do cộng đồng duy trì, cung cấp "công thức nấu ăn" và cho phép các nhà phát triển DApp cung cấp các mô-đun cho Railgun để hỗ trợ người dùng Có thể sử dụng Railgun để tương tác với DApp của họ. Ví dụ: nhà phát triển có thể viết công thức cho DEX cho phép người dùng có số dư mã thông báo trong Railgun để trao đổi mã thông báo một cách riêng tư.

RailGun v3

Phiên bản tiếp theo của Railgun sẽ giảm chi phí giao dịch từ 50% đến 60%. Những thay đổi khác trong phiên bản 3 là hỗ trợ cho người dùng eip-4337, thông qua nhóm bộ nhớ chuyên dụng. Ngoài ra, v3 sẽ hỗ trợ kiến ​​trúc dựa trên mục đích, cho phép người giải quyết cạnh tranh để có được khả năng thực thi tốt nhất, mặc dù tính đến thời điểm viết bài này, chi tiết vẫn ở mức rất cao. Họ hiện đang làm việc với CowSwap và có kế hoạch sử dụng pre-hook và post-hook để cho phép người giải quyết tiếp cận nguồn vốn.

Railgun Connect

Có thể cho rằng thay đổi thú vị nhất trong đề xuất là một công cụ có tên Railgun Connect, tương tự như WalletConnect và cho phép các địa chỉ 0zk kết nối với Hầu hết các giao diện người dùng đều nhằm mục đích sử dụng riêng tư và không yêu cầu các DApp này cung cấp khả năng tích hợp rõ ràng với Railgun thông qua các mô-đun tùy chỉnh.

Railgun Connect là một tiện ích mở rộng trình duyệt thực sự sử dụng trạng thái của chuỗi sao chép cục bộ HardHat và đưa nhà cung cấp web3 của riêng nó vào DApp, với các điểm cuối RPC cho chuỗi phiên bản HardHat cục bộ. Điều này cho phép bạn tương tác với hợp đồng DApp như bình thường, ghi lại giao dịch, sau đó phân nhóm và tạo bằng chứng báo lỗi rồi gửi nó đến hợp đồng Railgun trên chuỗi thực tế. Mặc dù mô tả này có phần đơn giản nhưng nó truyền tải được ý tưởng chung. Điều này cho phép bạn tương tác với bất kỳ DApp nào về cơ bản (có thể có một số trường hợp đặc biệt đối với DApp yêu cầu xử lý ngoài chuỗi bổ sung). Điều quan trọng cần lưu ý là việc lưu trạng thái chuỗi cục bộ là một hoạt động tiêu tốn nhiều tài nguyên, nhưng sau khi hoàn thành, bạn có thể sử dụng địa chỉ ẩn của Railgun để tương tác với DApps mà không có bất kỳ sự khác biệt nào so với việc sử dụng ví thông thường.

Kết luận

Hiện tại có một số đề xuất thú vị để thiết lập địa chỉ ẩn trong giao thức Ethereum. Ví dụ: Inco sử dụng khái niệm "trình bao bọc" erc-20 để đóng gói các hợp đồng erc-20 thông thường và mã hóa tất cả số dư. Việc chuyển giao và phê duyệt diễn ra ở trạng thái được mã hóa bằng cách sử dụng mã hóa đồng hình hoàn toàn. Inco dựa vào tính năng biên dịch trước hiện chỉ tồn tại trên mạng riêng của mình nhưng có thể được chuyển sang Ethereum trong tương lai.

Có một đề xuất khác tên là EIP-7503: Zero-Knowledge Wormholes, dựa trên trên Một thiết kế có tên "Proof-of-Burn", mặc dù đề xuất này dường như không thu hút được sự chú ý rộng rãi, có thể vì nó yêu cầu cập nhật cho EVM và nếu không có bản cập nhật này, nó thực sự chỉ có thể được triển khai ở cấp độ mã thông báo, sử dụng hỗ trợ chuyên dụng eip-7503 thiết kế erc-20 (hoặc nếu L2 quyết định thêm hỗ trợ cho các mã EVM của nó).

Aztec có thể là công nghệ bảo mật phức tạp nhất hiện nay, nhưng công nghệ này yêu cầu người dùng phải chuyển tiền cho Aztec để sử dụng công nghệ này, đây là một vấn đề lớn đối với mọi người. Điều này có thể không được hầu hết người dùng chấp nhận. Tuy nhiên, nếu nhu cầu về quyền riêng tư trong giao dịch cơ bản tăng lên trong số người dùng Ethereum, Aztec có thể có một đề xuất giá trị duy nhất và trở thành L2 rất có giá trị khi DApp và người dùng chuyển sang nền tảng cung cấp quyền riêng tư theo mặc định.

Tương tự, Intmax là Ethereum L2 tập trung vào quyền riêng tư (dựa trên thiết kế Plasma), cũng là một khía cạnh về giám sát tuân thủ, ZKP xác minh tính hợp pháp của quỹ cá nhân dựa trên chứng chỉ AML và áp đặt các giới hạn đối với số tiền giao dịch. Intmax có những hạn chế trong việc cung cấp quyền riêng tư cho việc chuyển tiền, trong khi hoạt động hợp đồng thông minh EVM không có quyền riêng tư. Tuy nhiên, không giống như Aztec, hợp đồng thông minh có thể được viết bằng Solidity, điều mà một số nhà phát triển có thể thích (tùy thuộc vào trường hợp sử dụng).

Hỗ trợ Ví

Mặc dù chúng tôi nhận thấy việc áp dụng các giao thức địa chỉ ẩn ngày càng tăng. Đây là một dấu hiệu tích cực nhưng vẫn còn nhiều thách thức. Thách thức quan trọng nhất là chúng chưa được hỗ trợ đầy đủ trong các ví Ethereum chính thống (ít nhất là chưa). Ví chính thống có thể có một số lựa chọn để thực hiện khi cung cấp hỗ trợ cho các địa chỉ ẩn. Những lựa chọn này bao gồm:

• Họ sẽ cung cấp hỗ trợ tư vấn cho một lần triển khai duy nhất hay họ sẽ xây dựng và duy trì một số loại tích hợp trên nhiều giao thức? Trình tổng hợp? Cái sau có thể tốn kém để phát triển và duy trì.

• Có cần cân nhắc về mặt quy định không và liệu có cần phải đưa ra quan điểm về phạm vi cũng như cơ chế khử ẩn danh có chọn lọc (như trường hợp của Labyrinth) không?

• Địa chỉ tàng hình yêu cầu thành phần trên chuỗi thông qua hợp đồng đăng ký (ngoại trừ Fluidkey), có nghĩa là mỗi mạng EVM phải được ví hỗ trợ rõ ràng (mặc dù thiết kế của Umbra tạo điều kiện thuận lợi cho việc không cần cấp phép). triển khai sổ đăng ký).

• Địa chỉ ẩn làm phức tạp thêm việc tích hợp hiện có với các công cụ phát hiện khối như Etherscan. Ví dụ: nút "Xem trên Trình phát hiện" sẽ không hoạt động đối với các địa chỉ meta ẩn vì ví hiển thị số dư tổng hợp. Vấn đề này cũng có thể tồn tại trong chuyển khoản. Những trường hợp khó khăn này cần được xem xét nghiêm túc.

• Tùy thuộc vào cách triển khai cơ bản, người dùng chỉ có thể sử dụng hiệu quả các địa chỉ ẩn với một nhóm DApp cụ thể, cụ thể là các địa chỉ được hỗ trợ bởi giao thức cơ bản. Kiến trúc địa chỉ ẩn dạng mô-đun sẽ biến điều này thành hiện thực. Tuy nhiên, không phải tất cả DApp đều được hỗ trợ và người dùng sẽ cần được thông báo theo một cách nào đó. Điều này tương đối dễ dàng khi sử dụng eip-5506, nhưng vẫn có những vấn đề phức tạp và khó khăn có thể ảnh hưởng đến trải nghiệm người dùng của ví.

Ngoài ra còn có chỗ cần cải thiện trong việc ngăn chặn tình trạng vệ sinh quyền riêng tư kém của người dùng, hãy xem bài viết này: " Phân tích ẩn danh của Lược đồ địa chỉ tàng hình Umbra trên Ethereum", tác giả đã hủy ẩn danh thành công 48,5% giao dịch vô hình trên mạng chính Ethereum. Các phương pháp phỏng đoán mà họ sử dụng không liên quan gì đến giao thức mà hơn thế nữa là về vệ sinh quyền riêng tư, chẳng hạn như người dùng gửi tiền đến một địa chỉ được che giấu mà họ kiểm soát và sau đó gửi số tiền đó trở lại địa chỉ gửi ban đầu, do nhầm tưởng rằng khả năng truy xuất nguồn gốc đã bị phá vỡ. Nhìn chung, các tác giả đã xác định được 6 phương pháp phỏng đoán khác nhau có thể được sử dụng để loại bỏ ẩn danh các giao dịch địa chỉ ẩn, chủ yếu dựa trên việc không tuân theo các phương pháp hay nhất. Tuy nhiên, đây là những vấn đề quan trọng về trải nghiệm người dùng cần được giải quyết.

Nhìn chung, tôi khá lạc quan về địa chỉ ẩn và quyền riêng tư trong Ethereum. Tôi nghĩ chúng tôi đã đạt được tiến bộ khá ấn tượng và tìm thấy một số thách thức có thể khắc phục được. Tôi tin rằng các ví chính thống sẽ tìm cách hỗ trợ các địa chỉ ẩn để người dùng có thể dễ dàng sử dụng những địa chỉ này với mức độ riêng tư thông thường mà người dùng mong đợi và xứng đáng được hưởng.

Cảm ơn tất cả các nhóm đã đầu tư thời gian và công sức vào việc nghiên cứu và xây dựng cơ sở hạ tầng địa chỉ ẩn, bao gồm bốn giao thức mà tôi đã đề cập trong bài đăng này. Sự chăm chỉ và kiên trì của họ sẽ có tác động rất lớn đến Ethereum!