Giới thiệu

Một điểm đau lớn đối với người dùng tiền điện tử web3 là thiếu quyền riêng tư. Thực tế là 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 tăng: được liên kết với một tên ENS duy nhất, dễ đọc, là một sự không khuyến khích người dùng thực hiện một số hoạt động nhất định hoặc khiến họ thực hiện các hoạt động đó theo cách dẫn đến tăng ma sát UX. Một ví dụ chỉ đơ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 có một ví được liên kết với một ví khác, vì họ có thể không muốn số dư ví lạnh của họ được nhìn thấy. Hiện tại, địa chỉ Ethereum không hoạt động như tài khoản ngân hàng cá nhân, bởi vì mọi người đều có thể nhìn thấy ví của bạn và ngày càng có nhiều hoạt động xã hội của bạn (SBT, chứng thực, hoạt động trên các dapp khác nhau, v.v.). Chính vì những lý do này mà Vitalik đã gọi quyền riêng tư là một trong những ba sự chuyển đổi kỹ thuật chínhđể Ethereum trở nên hữu ích đối với người dùng thông thường cần phải trải qua.

Sử dụng các giải pháp bảo mật hiện có, như Tornado Cash, là một trải nghiệm hơi không tối ưu vì một số lý do. Thứ nhất: người dùng có lý do để lo lắ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 nền tảng khác. Thứ hai, trải nghiệm người dùng khi tương tác với dịch vụ như Tornado Cash không thân thiện và chỉ phù hợp với người dùng thành thạo.

Địa chỉ ngấm nước cung cấp cách thức để đảm bảo quyền riêng tư cho người dùng giống như tài khoản ngân hàng riêng tư, và cách này dễ hiểu. Hơn nữa, các đổi mới xoay quanh địa chỉ ngấm nước có nghĩa là chúng ta có thể làm điều này một cách tuân thủ các quy định AML ở nhiều lãnh thổ khác nhau.

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

Mặc dù nghiên cứu về thái độ đối với quyền riêng tư của người dùng web và web3 không phổ biến, nhưng nghiên cứu dưới đây đã được phát hiện thông qua tìm kiếm trên web, và kết quả nói chung khá khớp nhau và cho thấy rằng có một nhu cầu rõ ràng về quyền riêng tư giao dịch.

1. Một cuộc khảo sát được tiến hành vào năm 2022 và được công bố bởi Simin Ghesmati và nhóm tác giả trong một bài báo có tiêu đề: Quyền riêng tư được người dùng cảm nhận trong blockchain, cho biết rằng “một nửa số người được phỏng vấn đã chỉ ra rằng quyền riêng tư giao dịch rất quan trọng với họ”. Mặc dù nghiên cứu này liên quan nhiều đến Bitcoin hơn là Ethereum, có khả năng người dùng Ethereum cũng có những quan điểm tương tự. Tuy nhiên, kích thước mẫu cho nghiên cứu này khá nhỏ (14 người tham gia).
2. Một tác phẩm nghiên cứu thú vị khác từ năm 2022, được xuất bản trên Frontiers, được đặt tên làThái độ chính trị, kinh tế và quản trị của người dùng blockchain, tổng quan hơn với 3.710 người dùng tiền mã hóa được khảo sát. Kết quả cho thấy khoảng một phần tư số người tham gia đã cho biết quyền riêng tư là “yếu tố quan trọng nhất của blockchain và tiền mã hóa”.

1. Về mặt thái độ đối với quyền riêng tư nói chung, Consensyscông bố nghiên cứu có tựa đềCuộc khảo sát toàn cầu về Web3 và tiền điện tử năm 2023, trong đó họ đã khảo sát 15.158 người trực tuyến trên 15 quốc gia về các chủ đề liên quan đến web, không chỉ là crypto. Cuộc khảo sát cho thấy 83% người tham gia cho rằng quyền riêng tư dữ liệu là quan trọng, trong khi chỉ có 45% người tham gia cho biết họ tin tưởng cách dịch vụ Internet hiện tại sử dụng dữ liệu và thông tin cá nhân của họ.
2. Một cuộc khảo sát do Chương trình Bồi thường Dịch vụ Tài chính của Vương quốc Anh tiến hành, được công bố vào tháng 4 năm 2023, đã nhấn mạnh rằng 9% số người tham gia khảo sát đã đưa ra lý do “mong muốn về nặc danh/quyền riêng tư” là lý do của họ để đầu tư vào tiền điện tử.

Sự áp dụng các giao thức giao dịch ẩn danh

Railgun có số liệu ấn tượng, với việc sử dụng giao thức có vẻ đang tăng trưởng ổn định theo thời gian, đạt đỉnh điểm hơn 70 triệu đô la TVL và 2 tỷ đô la trong khối lượng giao dịch tính đến tháng 11 năm 2024.

TVL (USD) Railgun trên Ethereum main - nguồn: ​​Railgun - DefiLlama

Umbracũng đã chứng kiến sự tăng đều đặn của người sử dụng giao thức của họ (người đăng ký địa chỉ ẩn danh cho ENS của họ), với gần 77 nghìn vào tháng 11 năm 2024:

Người đăng ký tích lũy Umbra (Cross Chain)— nguồn: dune.com

Nếu chúng ta nhìn vào giao thức bảo mật phổ biến nhất (và hiện nay đáng tiếc là nổi tiếng) trong Ethereum, đó là Tornado cash, chúng ta có thể thấy rằng nó vẫn đang được sử dụng đáng kể, mặc dù địa chỉ hợp đồng thực tế nằm trong danh sách SDN của OFAC.

Biểu đồ dưới đây cho thấy giá trị khối lượng tổng TVL của Tornado Cash theo thời gian. Chúng ta có thể quan sát rằng sự giảm mạnh đầu tiên về TVL từ điểm cao nhất vào khoảng tháng 10 năm 2021 trùng với sự bán rộng rãi trên thị trường tiền điện tử, với sự giảm mạnh thứ hai vào tháng 8 năm 2022 tương ứng với việc OFAC đưa Tornado Cash vào danh sách SDN, và sự giảm mạnh thứ ba tương ứng với việc OFAC tái chỉ định vào tháng 11 năm 2022. Tuy nhiên, kể từ đó, Tornado Cash đã trải qua sự phát triển ổn định, mặc dù có sự trừng phạt, đạt gần 600 triệu đô la Mỹ về TVL. Điều này là bằng chứng mạnh mẽ cho thấy có nhu cầu về quyền riêng tư giao dịch cơ bản trên Ethereum.

TVL (USD) Tornado Cash trên Ethereum chính — nguồn: Tornado Cash - DefiLlama

Bức tranh Địa chỉ Ẩn

Nghiên cứu này đã xác định 4 giải pháp chính cho các chuỗi EVM trong sản xuất đến ngày hôm nay, đó là:

• Fluidkey
• Umbra
• Labyrinth
• Railgun

Cả Fluidkey và Umbra đều dựa trên các tiêu chuẩn Ethereum, bao gồm:

• ERC-5564: Giao thức Địa chỉ ẩn
• ERC-6538: Stealth Meta-Address Registry

Labyrinth và Railgun dựa trên giao thức zerocash(những zcashcũng được dựa trên), sử dụng một nguồn tiền được bảo vệ mà người dùng gửi tiền vào. Zerocash sử dụng khái niệm “ghi chú”, đó là biểu diễn mật mã của giá trị cho phép 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 (một nullifier), với zk-SNARKs được sử dụng để xác minh quyền sở hữu mà không tiết lộ chi tiết và do đó chuyển giá trị trong các ghi chú. Khi một ghi chú được tiêu thụ, nullifier của nó được tiết lộ để ngăn chặn việc chi tiêu kép, trong khi tạo ra các ghi chú mới cho người nhận, tạo thành một hệ thống UTXO bên trong nguồn tiền được bảo vệ.

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

Tiêu chuẩn erc-5564 chỉ định một cơ chế mà người nhận có thể xuất bản một địa chỉ ẩn danh-meta, từ đó các địa chỉ Ethereum mới có thể được tạo ra. Bất kỳ ai muốn gửi quỹ cho người nhận, có thể tạo ra các địa chỉ mới từ địa chỉ ẩn danh-meta, và cho phép người nhận biết về các quỹ này mà không cần có bất kỳ giao tiếp trực tiếp nào diễn ra. Tất cả các triển khai địa chỉ ẩn danh đều hoạt động trên cơ sở cơ bản này.

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

Một địa chỉ ẩn danh meta là sự kết hợp của 2 khóa công khai nén, được gọi là “khóa chi tiêu” và “khóa xem”. Địa chỉ ẩn danh meta sử dụng định dạng địa chỉ cụ thể của chuỗi EIP-3770, với tiền tố “st:” được thêm vào. Dưới đây là một ví dụ về địa chỉ ẩn danh:

st:eth:0x036ffa94a70a5b9608aca693e12da815fe0295f3739c7b22b0284c6d85c464ba4a02c0521b6fe31714b2ca0efa159402574355b754e0b50406b0b5fb33128eec3507

Để đơn giản, địa chỉ ẩn này có thể được liên kết với một địa chỉ Ethereum bình thường (và do đó là 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 sẽ giải quyết địa chỉ trên và sử dụng tiêu chuẩn EIP-5564, sẽ tạo khóa công khai tạm thời, từ đó họ lấy được địa chỉ ẩn. Người gửi gửi tiền đến địa chỉ ẩn mới, thường thông qua hợp đồng singleton mà tất cả các địa chỉ ẩn mà người nhận lắng nghe cho các sự kiện. Hợp đồng này phát ra sự kiện “Thông báo” mà người nhận đăng ký. Mỗi khi một sự kiện thông báo được phát ra, người nhận sẽ kiểm tra khóa công khai tạm thời trong thông báo, kết hợp nó với khóa riêng tư 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 họ làm vậy, ví / khách hàng họ đang sử dụng sẽ nhớ địa chỉ ẩn và các khoản tiền tương ứng, thêm nó vào số dư được hiển thị của người dùng. Để thực sự chi tiêu tiền, họ có thể ký một giao dịch bằng khóa chi tiêu riêng tư.

Sơ đồ sau đây mô tả quy trình từ đầu đến cuối hi vọng sẽ rõ hơn một chút:

Hãy nhớ rằng quá trình này diễn ra hoàn toàn không tương tác, điều đó có nghĩa là người gửi và người nhận không bao giờ có bất kỳ giao tiếp trực tiếp nào, điều đó có nghĩa là thực tế không có bất kỳ 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ó thể quan sát được.

Tuy nhiên, để làm việc này, người nhận phải cho người gửi biết địa chỉ ẩn danh của mình. Một cách để làm điều này là sử dụng eip-6538 Stealth Meta-Address RegistryĐây là một hợp đồng đơn lẻ cho phép người dùng đăng ký một địa chỉ meta ẩn đến một địa chỉ Ethereum bình thường, mà người gửi sau đó có thể tra cứu. Điều này cho phép người gửi giải quyết địa chỉ bình thường từ ENS, sau đó tra cứu địa chỉ meta ẩn liên quan từ registry.

Kế hoạch này phá vỡ liên kết giữa người gửi và người nhận, mang lại cho họ cả quyền riêng tư khỏi việc toàn bộ thế giới biết về công việc của họ. Tuy nhiên, cũng có một số điều cần lưu ý:

• Khi người nhận chi tiêu tiền, người nhận sẽ thấy rằng tiền đó xuất phát từ người gửi ban đầu (tức là họ có thể thấy địa chỉ tiền đã được chuyển từ đâu và ai đã gửi tiền đến địa chỉ đó trước đó). Điều này có nghĩa là chuỗi chuyển tiền vẫn được giữ nguyên và có thể theo dõi, nhưng chỉ không liên quan đến người nhận cụ thể đó (trừ khi người nhận làm điều gì đó như gửi tiền vào một trong những địa chỉ không ẩn danh đã biết của họ). Lưu ý rằng điều này chỉ áp dụng cho các phiên bản erc-5564, không áp dụng cho Railgun hoặc Labyrinth.
• Một tác động phụ khác của vấn đề trên là để duy trì quyền riêng tư tối ưu, người dùng có thể cần để để lại tiền trong các địa chỉ ẩn danh ban đầu cho đến khi họ thực sự cần đến chúng, thay vì tập trung chúng lại dưới một địa chỉ duy nhất. Điều này đòi hỏi việc nhớ các địa chỉ và sau đó chi tiêu các khoản tiền tại những địa chỉ đó, vì số tiền bạn muốn chuyển đi sẽ cần được lấy từ sự kết hợp của các khoản tiền tại các địa chỉ khác nhau.
• Để chuyển quỹ từ địa chỉ này, người nhận sẽ cần tài trợ cho địa chỉ bằng một số ETH để thanh toán cho gas, và điều này có thể tiềm ẩn nguy cơ làm mất tính ẩn danh của người nhận. Điều này là một vấn đề đã biết đến với địa chỉ ẩn danh, và một trong những lý do mà một số phiên bản đã triển khai hỗ trợ cho eip-4337 và một người quản lý thanh toán.
• Một nhược điểm của hệ thống địa chỉ ẩn là người nhận cần theo dõi blockchain để theo dõi sự kiện Thông báo và kiểm tra mọi thông báo để xác định xem họ đã được gửi tiền hay chưa. Điều nà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 họ nhận tiền trên nhiều mạng. Để làm cho quá trình này hiệu quả hơn, tiêu chuẩn quy định một “thẻ xem”, đó là một băm cắt ngắn được tạo ra từ bí mật chia sẻ, và có thể được sử dụng để nhanh chóng loại bỏ các giao dịch mà chắc chắn không dành cho họ. Qua việc sử dụng thẻ xem, hiệu suất không tệ trên máy tính để bàn, tuy nhiên có thể hơi đáng chú ý hơn trên thiết bị di động. Thời gian duy nhất mà hiệu suất bị chú ý thực sự là khi một ví đang được khôi phục, trong trường hợp đó ví sẽ cần quét qua mỗi địa chỉ từ khi hợp đồng trên chuỗi được triển khai, điều này tốn thời gian.
• Để điều này, người dùng có thể tùy chọn chia sẻ khóa xem riêng tư với một bên thứ ba đáng tin cậy. Dịch vụ bên thứ ba này có thể theo dõi các mạng khác nhau và có thể thông báo cho người dùng khi họ nhận được tiền. Tất nhiên điều này đến với một sự đánh đổi: mặc dù bên thứ ba không thể thực sự tiêu tiền của người dùng (họ không có khóa tiêu tiền riêng để làm điều đó), họ có thể nhìn thấy tất cả các khoản tiền được gửi cho người nhận cụ thể, điều này có nghĩa là người dùng cần tin tưởng họ với quyền riêng tư. Fluidkey thực hiện điều này theo mặc định.
• Giao thức địa chỉ ẩn danh tiêu chuẩn, tức ERC-5564, được thiết kế để tạo điều kiện cho việc chuyển tiền bảo mật, tuy nhiên, các trường hợp sử dụng không liên quan đến tài chính như gọi các chức năng hợp đồng thông minh tùy ý yêu cầu một chút công nghệ hơn và thường là cụ thể cho từng trường hợp triển khai.

Bảng so sánh

Có nhiều cách mà chúng ta có thể so sánh bốn cách triển khai địa chỉ ẩn danh mà bài viết này khám phá. Tất cả các cách triển khai đều có sự khác biệt tinh tế và sự đánh đổi, nhưng có lẽ những điểm quan trọng nhất cần phải nhấn mạnh là về sự theo dõi và làm mờ giá trị.

Trong khi cả Fluidkey và Umbra đều cho phép chuyển tiền đến một địa chỉ Ethereum tiêu chuẩn mà không để lại bất kỳ liên kết nào với danh tính của người nhận, họ vẫn bảo tồn tính khả năng theo dõi của giao dịch, có nghĩa là người gửi có thể được nhìn thấy bởi bất kỳ ai nghiên cứu lịch sử giao dịch của địa chỉ ẩn. Điều này có nghĩa là nếu bạn nhận được tiền tại một địa chỉ ẩn, người mà bạn quyết định gửi tiền đến sẽ biết được nguồn gốc của số tiền đó. Hơn nữa, giá trị thực tế được chuyển tiếp cũng có thể nhìn thấy. Railgun và Labyrinth ẩn người gửi, cũng như giá trị được gửi đi, nhưng với sự đánh đổi rằng tất cả điều này diễn ra bên trong một hợp đồng duy nhất, và không phải là một giao dịch thông thường đến một địa chỉ Ethereum thông thường.

Hình dưới đây cho thấy cách các giao thức chúng ta xem xét trong bài viết so sánh với nhau theo hai chiều quan trọng so sánh này.

Để khám phá sự khác biệt một cách cụ thể hơn, dưới đây là một ma trận so sánh của bốn giao protocal địa chỉ ẩn chính qua sáu chiều chính:

1. Bảo mật toàn diện từ đầu đến cuối (chỉ có người gửi và người nhận thấy thanh toán)
2. Tính bảo mật tiên tiến. Việc gửi tiền đã nhận thông qua giao dịch ẩn không cho phép người nhận thứ hai biết nguồn gốc của số tiền.
3. Tuân theo các tiêu chuẩn erc-5564 và erc-6538
4. Triển khai một kiến trúc mở rộng có thể tích hợp với ứng dụng bên thứ ba một cách linh hoạt
5. Cài đặt có cung cấp một SDK mà nhà phát triển có thể sử dụng để tích hợp không?
6. Rất mong đợi sự hỗ trợ từ bạn.
7. Thiết kế có hỗ trợ che đậy số lượng / giá trị đang được chuyển giao không?

| Giao thức | Bảo mật E2E | Bảo mật Forward Secrecy | Tiêu chuẩn mở | Kiến trúc linh hoạt | SDK | Hỗ trợ giải mã ẩn danh | Số tiền được ẩn |

|—————-|——————-|————————-|————————|———————————|———|—————————————|————————|

| Umbra | ✅ | ⛔️ | ✅ | ⛔️ | ⛔️ | ⛔️ | ⛔️ |

| Fluidkey | ⛔️ | ⛔️ | ✅ | ✅ | sắp tới | ✅ | ⛔️ |

| Labyrinth | ✅ | ✅ | ⛔️ | ✅ | ✅ | ✅ | ✅ |

| Railgun | ✅ | ✅ | ⛔️ | ✅ | ✅ | tùy ý | ✅ |

Một số sự tinh vi và khác biệt khác được thu thập chi tiết hơn trong phần tiếp theo. Mỗi cài đặt có sự khác biệt tinh tế thú vị có thể hoặc không có sự khác biệt tùy thuộc vào trường hợp sử dụng của bạn.

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

Chi tiết về cài đặt địa chỉ ẩn

Fluidkey

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

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

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

Một khía cạnh thú vị khác của thiết kế Fluidkey là nó triển khai một tài khoản hợp đồng thông minh cho mỗi địa chỉ ẩn danh mới. Điều này xảy ra ngược lại chỉ khi có quỹ từ một địa chỉ ẩn danh được chi tiêu. Tài khoản thông minh là một tài khoản Safe 1/1, và cho phép các hoạt động như tài trợ gas, giúp quản lý các địa chỉ ẩn danh khác nhau dễ dàng hơn. Có những chi tiết toàn diện về điều này trong trang của họ.Hướng dẫn Kỹ thuật.

Mặc dù Fluidkey có một sự đánh đổi là giữ được khả năng nhìn thấy tài khoản của người dùng, điều này có thể tiềm năng là một lợi thế khi liên quan đến tuân thủ, tuy nhiên, khung việc cụ thể về cách Fluidkey sẽ xử lý những yêu cầu của cơ quan chức năng như yêu cầu từ cơ quan chức năng trong tương lai vẫn chưa được công khai. Tuy nhiên, họ đặt trụ sở tại Thụy Sĩ và trong khi họ phải tuân thủ các luật địa phương, luật bảo vệ dữ liệu rất rõ ràng và rất mạnh mẽ - phải có một vụ án rõ ràng để chia sẻ dữ liệu và cũng phải được xem xét bởi một tòa án (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ư tại Thụy Sĩ).

Người dùng cũng hoàn toàn tự do xuất các giao dịch của họ hoặc chia sẻ khóa xem của họ với các bên thứ ba (ví dụ: kế toán của họ), điều này có thể cực kỳ hữu ích, đặc biệt là đối với các doanh nghiệp. Tuy nhiên, cần lưu ý rằng với 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 có gì”, có nghĩa là nó không thể tự tiết lộ các giao dịch riêng lẻ bị cô lập. Ngoài ra, như với tất cả các triển khai erc-5564, truy xuất nguồn gốc không bị phá vỡ - chỉ liên kết với người dùng - có nghĩa là lịch sử giao dịch của mỗi địa chỉ ẩn được tiếp xúc với bất kỳ ai có khóa xem. Một tính năng không nổi tiếng của Fluidkey giúp giảm thiểu những đánh đổi này là khả năng xoay các phím xem, cho phép người dùng sử dụng khóa xem mới mỗi tháng và chỉ chia sẻ quyền truy cập chế độ xem vào các tháng cụ thể với bên thứ ba.

Một lợi ích tốt của phương pháp của Fluidkey là địa chỉ ẩn danh không được người gửi tạo ra, mà được Fluidkey tạo ra một cách ngẫu nhiên giả mạo mỗi khi ENS được truy vấn. Điều này nhanh hơn nhiều vì người dùng không cần 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 một ví địa chỉ ẩn danh để tạo ra một địa chỉ ẩn danh cho người nhận - họ chỉ cần gửi tiền vào một địa chỉ như bất kỳ địa chỉ nào khác và đó là tất cả. Điều này cũng có nghĩa là không có hợp đồng đăng ký nào liên quan, điều này độc đáo đối với thiết kế của Fluidkey và là một lợi thế lớn.

Có thể nói rằng Fluidkey cam kết hoàn toàn tự giữ tài sản và họ đã công khai mã nguồn thư viện Stealth Account Kit của mình. Ngoài ra, nếu Fluidkey biến mất đột ngột, cũng có một số giao diện khôi phục được phát triển độc lập sẵn có, điều này đồng nghĩa rằng quỹ sẽ không bị khóa hoặc bị mắc kẹt.

Trừu tượng địa chỉ

Bằng cách sử dụng tài khoản hợp đồng thông minh một cách điều kiện, Fluidkey có thể tự động trừu tượng hóa việc quản lý các địa chỉ ẩn cá nhâ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 bạn trên các địa chỉ ẩn khác nhau, Fluidkey có thể tự động xác định tổ hợp địa chỉ nào để sử dụng để cung cấp nguồn vốn cho việc chuyển tiền, xử lý tất cả các chi phí gas và triển khai hợp đồng, tất cả đằng sau màn hình. Fluidkey cũng cho phép người dùng có một số kiểm soát về việc kết hợp các địa chỉ bằng cách sử dụng tính năng thú vị gọi là nhãn, cho phép người dùng gắn thẻ các địa chỉ vào các danh mục khác nhau.

Giải quyết ENS

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

Bộ cài đặt ENS sử dụng một Bộ giải quyết ngoại tuyến ENS (hay còn gọi là erc-3668: CCIP Read) để trả về địa chỉ ẩn. Mỗi khi truy vấn bộ giải quyết ngoại chuỗi, nó tạo và trả về một địa chỉ ẩn mới cho tên ENS tương ứng. Điều này là một tính năng tốt vì nó cho phép người dùng có một tên ENS đọc được cho con người duy nhất trong khi vẫn giữ được tính riêng tư của địa chỉ ẩn, vì các địa chỉ ẩn được tạo không thể liên kết với tên ENS theo hồi tưởng.

Chi phí

Fluidkey miễn phí và không tính phí. Có chi phí triển khai hợp đồng An toàn đến mỗi địa chỉ có quỹ khi bạn muốn sử dụng quỹ đó. Tuy nhiên, trong khi tương đối đắt đỏ trên mainnet, trên L2 thì rất nhỏ bé, thường ít hơn 1 xu, thậm chí khi kết hợp nhiều địa chỉ ẩn danh thành một lệnh chuyển đổi duy nhất.

Họ cũng có thể thực hiện việc tài trợ gas thông qua các triển khai An toàn - họ tính toán chi phí gas sẽ là bao nhiêu và trừ số tiền này từ số dư của người dùng, ngay cả khi đó là một token - trong trường hợp này, một người truyền thông triển khai an toàn và chuyển token thay mặt cho người dùng.

Umbra Cash

Umbralà một phiên bản thực hiện của eip-5564 + eip6538 bởi Scopelift. Khi người dùng đăng nhập vào ứng dụng Umbra, họ sẽ trải qua một giai đoạn thiết lập, trong đó họ ký một tin nhắn, từ đó suy ra các khóa chi tiêu và xem và địa chỉ ẩn tương ứng. Sau đó, họ đăng ký địa chỉ ẩn tương ứng này vào địa chỉ ví chính của họ trong một đăng ký trên chuỗi. Đây là nơi mà cài đặt khác biệt so với Fluidkey.

Việc triển khai của Umbra đối với erc-5564 gần nhất với thông số kỹ thuật, vì họ không có quyền truy cập vào các 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ể xem xét quỹ của người dùng, điều này cũng có nghĩa là để gửi quỹ, người gửi phải có một ví erc-5564 tương thích (hoặc ứng dụng Umbra) để tạo ra địa chỉ ẩn của họ.

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

Relayer

Một vấn đề với địa chỉ ẩn danh mà chúng tôi đã đề cập trước đó là để người nhận chi tiêu các khoản tiền được gửi đến một địa chỉ ẩn danh, địa chỉ đó sẽ cần phải có ETH hoặc mã thông báo gas cần thiết khác để trả phí giao dịch. Trên hầu hết các mạng, nếu địa chỉ ẩn danh được gửi ETH từ đầu, điều này thường không phải là một vấn đề. Tuy nhiên, nếu địa chỉ ẩn danh được gửi một mã erc-20 hoặc NFT, việc tài trợ địa chỉ với ETH để thanh toán cho gas có thể liên kết địa chỉ đó với các địa chỉ khác của người dùng, loại bỏ tính riêng tư của họ.

Để giải quyết vấn đề này, Umbra sử dụng một cấu trúc liên quan đến một người chuyển tiếp. Khi bất kỳ tài sản nào không phải là ETH đượ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 địa chỉ ẩn. Người dùng có thể chi tiêu tiền được gửi đến địa chỉ ẩn của họ bằng cách gửi một giao dịch meta (từ ứng dụng Umbra) đến người chuyển tiếp của Umbra, sẽ chuyển tiền ra khỏi hợp đồng thông minh thay mặt người dùng. Người chuyển tiếp sẽ khấu trừ một số mã thông báo để trang trải chi phí phí gas và chỉ một số lượng mã thông báo nhất định được hỗ trợ ban đầu.

Chi phí

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

Mạng Lưới Được Hỗ Trợ

Umbra hiện đang triển khai trên Ethereum mainnet, cũng như trên Optimism, Polygon, Gnosis Chain và Arbitrum.

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

Umbra v2

Scopelift hiện đang phát triểnphiên bản 2 của Umbra, giới thiệu một kiến trúc modul mới cho phép các hợp đồng cốt lõi được mở rộng để 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 liên quan đến thanh toán. 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 các module cho bất kỳ tiêu chuẩn mã thông báo nào, ví dụ như erc-1155, erc-7621, hỗ trợ cho erc-4337 paymasters hoặc bất cứ thứ gì khác bạn có thể nghĩ tới. Hiện tại hợp đồng cốt 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

Labyrinth là một giao thức không dựa trên EIP-5564 + EIP6538, mà thay vào đó sử dụng bằng chứng không có kiến thức để thêm ẩ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 bảo mật với sự tuân thủ tích hợp”. Tuân thủ tích hợp đề cập đến “Selective De-Anonymization” của Labyrinth, đây là một giải pháp tinh vi cho phép một số giao dịch nhất định được ẩn danh cho các tác nhâ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 mà Labyrinth sử dụng bao gồm một bể giao dịch đ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 duy nhất. Để tiêu thụ tài sản, người dùng quét mạng và lấy dữ liệu ghi chú được mã hóa, giải mã các ghi chú và lọc các tài sản mà họ muốn tiêu thụ. Sau đó, người dùng tạo ra một ZKP bao gồm các giao dịch và một chữ ký từ khóa ký liên quan đến các giao dịch mà họ muốn tiêu thụ từ.

Một phần của các hợp đồng cốt lõi của Labrynth bao gồm một hợp đồng chuyển đổi, tương tác với các hợp đồng proxy modul, đó là các proxy đến các hợp đồng bên ngoài. Ví dụ: Nếu người dùng muốn sử dụng Labyrinth để tương tác với Uniswap, người dùng sẽ tạo một giao dịch sử dụng hợp đồng chuyển đổi để gọi một hoạt động swap trên một pool Uniswap thông qua hợp đồng proxy của Uniswap.

Giao thức zkFi của Labyrinth sử dụng “notes” để theo dõi số dư và chuyển khoản. Một note về cơ bản là một cấu trúc dữ liệu mô tả một lượng tài sản nào đó và địa chỉ nó thuộc về. Một client lưu trữ thông tin cần thiết để tạo lại một note, và sử dụng điều này để tiêu tốn tài sản. Một cam kết đến note (một hash của id tài sản, chủ sở hữu, và giá trị) được lưu trữ trong một cây merkle trên chuỗi. Trên thực tế, Labyrinth sử dụng hai cây merkle, một cho notes, và một cho root addresses.

Cấu trúc dữ liệu ghi chú chứa các thông tin sau:

• assetId: Định danh cho tài sản (ETH, WBTC, MATIC, v.v.) mà ghi chú này đại diện cho giá trị của nó.
• giá trị: Giá trị hoặc số tiền mà ghi chú đại diện.
• leafIndex: Chỉ số lá của cây merkle cam kết nơi ghi chú này sẽ được chèn vào.
• blinding: Một yếu tố mờ ngẫu nhiên.
• rootAddress: Địa chỉ gốc của người dùng có quyền chi tiêu nó.
• 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 rằng 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 tài sản, điều này khá lạ, vì cam kết được ghi trong cây merkle ghi chú là một hash của id tài sản, giá trị và chủ sở hữu. Trên thực tế, chủ sở hữu được tính toán từ địa chỉ gốc, người thu hồi và một yếu tố mờ hóa ngẫu nhiên, và vì vậy đối với các quan sát viên bên ngoài, chủ sở hữu thực tế là một địa chỉ mới được tạo ra cho mỗi giao dịch mới.

Hồ bảo vệ

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

Để hiểu cách hồ bảo vệ này hoạt động, chúng ta cần nhìn vào cách quỹ được chuyển đi trong giao thức:

Số dư của người dùng trong nhóm được bảo vệ là tổng các ghi chú của các tài sản tương ứng. Để chi tiêu những ghi chú đó, người dùng cần tiết lộ “nullifiers” của những ghi chú đó. Một nullifier là duy nhất cho một ghi chú và một khi ghi chú đó được chi tiêu, nullifier được đánh dấu để ngăn chặn chi tiêu gấp đôi và một ghi chú mới được tạo từ ghi chú đã chi tiêu đó. Một số ghi chú của cùng một nội dung có thể được kết hợp và một số ghi chú mới có thể được tạo. Nullifier chỉ đơn giản là hàm băm của (l, c, δ), trong đó l là chỉ số của cam kết ghi chú trong cây ghi chú và c là cam kết và δ là một phần tử ngẫu nhiên còn được gọi là yếu tố mù.

Người nhận một giao dịch ẩn danh xác định giao dịch thông qua cùng một phương pháp như eip-5564, trong mức độ mà họ lắng nghe các sự kiện được phát ra từ các hợp đồng chính và xác định những địa chỉ ẩn danh mà họ có thể gửi tiền từ, ghi chú chúng vào cục bộ. Xác định nguồn tiền đến cũng được thực hiện nhanh hơn bằng cách sử dụng thẻ xem và bằng cách đồng bộ hóa và lưu trữ cục bộ ghi chú bất đồng bộ trong suốt thời gian hoạt động của ứng dụng.

Hiện đang tiến hành nghiên cứu để làm cho quá trình khám phá tiền nhận được nhanh hơn, hãy xem ví dụ đề xuất này từ Aztec:Yêu cầu đề xuất: Giao thức Phát hiện Ghi chú - Aztec.

Để chi tiêu các quỹ, người dùng cũng phải tạo ra một chứng minh zk, khác với việc triển khai erc-6654, đó là địa chỉ Ethereum bình thường. Việc tạo chứng minh đòi hỏi một ví tiền điện tử tương thích, với hiệu suất tương đối tốt, mất khoảng 20 giây trên thiết bị Android tầm trung.

Bundler và Converter

Có một số tính năng tốt mà Labyrinth cung cấp giải quyết một số vấn đề đau đầu của giao dịch ẩn danh. Các giao dịch gửi đến các hợp đồng nhân vật Labyrinth được gửi dưới dạng các hoạt động người dùng thông qua các bundlers erc-4337. Thiết lập này cho phép tiêu hao ghi chú mà không cần ETH hoặc yêu cầu token gas cho các giao dịch, vì người dùng có thể tận dụng erc-4337 paymaster để trả phí gas thay mặt cho họ, điều này tạo thêm một lớp bảo mật. Điều duy nhất là ngoại lệ là khoản tiền gửi ban đầu không được gửi dưới dạng userop. Việc sử dụng er-4337 paymaster cũng có lợi ích bổ sung là có thể trả phí gas thông qua tài sản được chuyển, ngay cả khi chúng là các token erc-20, và với điều này, Labyrinth tiết lộ một API báo giá gas.

Một tính năng rất hay khác mà Labyrinth có 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 dapp của bên thứ ba. Điều này cho phép người dùng không chỉ chuyển tiền bằng các giao dịch ẩn mà còn tương tác với các dapp của bên thứ ba như DEX, (ví dụ: Uniswap, Aave, Lido, v.v.). Các hợp đồng “chuyển đổi” proxy này về cơ bản thực hiện một chức năng trong đó một số lượng tài sản và một số lượng tài sản xuất hiện, với logic cơ bản nằm trong một số hợp đồng của bên thứ ba.

Giải pháp tuân thủ

Labyrinth đảm bảo tuân thủ và tuân thủ quy định thông qua một khung gọi là Tuyển chọn De-Anonymization (SeDe).

Nhớ rằng cấu trúc dữ liệu của một ghi chú chứa một trường gọi là “revoker”. Revoker là địa chỉ của một thực thể cụ thể có thể khởi động quá trình de-anonymization. Người dùng phải chọn ít nhất một revoker từ danh sách được định nghĩa trước. Revoker không phải độc lập chịu trách nhiệm xác định hoạt động có thể vi phạm pháp luật hay bất hợp pháp, nhưng có thể đáp ứng yêu cầu từ cơ quan chức năng.

Người thu hồi không có khả năng đơn phương để bóc tách danh tính giao dịch trực tiếp, nhưng họ chịu trách nhiệm cho việc khởi xướng yêu cầu bóc tách danh tính. Những yêu cầu này được đăng công khai đến các người bảo vệ, đó là một ủy ban các thực thể giám sát quyền riêng tư và tuân thủ. Người bảo vệ phải đáp ứng yêu cầu bằng cách bỏ phiếu về việc cho phép hay không cho phép bóc tách danh tính giao dịch. Nếu những người bảo vệ có thể đạt đến đa số và bỏ phiếu thuận lợi, thì người thu hồi có thể giải mã dữ liệu giao dịch, cho phép họ liên kết giao dịch cần xét đến với các giao dịch trước đó cho đến khi chuỗi giao dịch đã được hoàn toàn bóc tách danh tính.

Hệ thống này tạo ra một loạt các kiểm tra và cân đối, trong mức độ mà các người giám hộ không thể một mình quyết định để tiết lộ dữ liệu giao dịch, và ngay cả khi họ xảy ra hiệp đồng, họ không thể làm bất cứ điều gì mà không có sự can thiệp của người thu hồi, và chỉ có người thu hồi một mình không thể làm bất cứ điều gì với sự đa số bỏ phiếu của các người giám hộ.

Súng điện tử

RAILGUNlà một hệ thống bảo mật giao dịch ẩn danh triển khai trên Ethereum, BSC, Polygon và Arbitrum. Giao thức này tương tự như Labyrinth ở một số điểm, vì nó dựa trên các ghi chú được lưu trữ trong một cây merkle dưới dạng cam kết và tạo thành một tập hợp UTXO, tức là các ghi chú có thể được chi tiêu bằng cách tạo ra các ghi chú mới cho người nhận khác. Để chi tiêu một ghi chú, một nullifier được thêm vào trạng thái cho ghi chú đó, ngăn chặn các lần chi tiêu trùng lặp. Chỉ chủ sở hữu của một ghi chú mới có thể tính toán nullifier của nó, được dựa trên băm của khóa chi tiêu và chỉ số của các ghi chú trên cây merkle, có nghĩa là chỉ chủ sở hữu của ghi chú mới có thể chi tiêu nó (và chỉ có thể chi tiêu một lần).

Địa chỉ meta tàng hình trong Railgun sử dụng tiền tố “0zk”, và giống như eip-5564, là sự kết hợp của khóa xem công khai và khóa chi tiêu công khai. Tuy nhiên, Railgun sử dụng các phím Ed25519 trên đường cong BabyJubJub thay vì ECDSA & secp256k1. Theo cách tương tự như eip-5564, người dùng quét qua tất cả các sự kiện được phát ra từ các 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ột mạng lưới các đài phát thanh, đó là những người truyền tải thông tin chuyển đổi từ người dùng và phát sóng giao dịch thực tế đến chuỗi khối tương ứng, trả phí gas cho người dùng. Giao dịch trực tiếp với hợp đồng Railgun đến từ mạng lưới các đài phát thanh này, bảo vệ tính vô danh của người dùng cuối. Các giao dịch được gửi từ người dùng đến đài phát thanh được mã hóa bằng khóa công khai của đài phát thanh cụ thể và truyền thông bằng Giao thức Waku.

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, cho phép các chức năng vượt xa việc chuyển giao đơn giản. Điều này được thực hiện thông qua hợp đồng AdaptRelay, giúp che và bảo vệ các token trước và sau khi tương tác với một hợp đồng bên ngoài, ví dụ như bỏ che token A, đổi lấy token B trên một AMM nào đó, và bảo vệ lại token B cho chủ sở hữu ban đầu.

Với phiên bản 3, Railgun đang lên kế hoạch tận dụng eip-4337 cũng như hỗ trợ giao dịch meta cũ. Họ hy vọng rằng bằng cách duy trì một mempool eip-4337 dành riêng cho Railgun, các giải quyết viên độc lập có thể tham gia như nhà phát sóng. Hiện tại, họ đang hợp tác với Umbra để nghiên cứu vấn đề này, và xác định các trường hợp đặc biệt và cách xử lý chúng, xem phần Railgun v3 bên dưới để biết thêm chi tiết.

Phí

Giao thức Railgun thu phí 0,25% cho việc gửi và rút tiền. Những khoản phí này được gửi đến quỹ DAO và được trả dần cho những người sở hữu token quản trị RAIL trong thời gian. Ngoài khoản phí gửi và rút 0,25%, người phát sóng thường áp dụng khoản phí riêng của họ và thường là khoảng 10% của phí gas cho giao dịch trên chuỗi thực tế.

Quản trị

Railgun có một hệ thống quản trị cho phép bất kỳ dạng đề xuất nào được nộp, và không có thay đổi nào đối với bất kỳ hợp đồng cốt lõi nào (bao gồm cả hợp đồng quản trị và quỹ) có thể xảy ra mà không có đề xuất từ DAO. Không bình thường, các phiên bản riêng lẻ của Railgun có hệ thống quản trị riêng của họ. Ví dụ, Railgun trên Ethereum, Polygon và Binance Chain đều có các hệ thống quản trị và token riêng biệt.

SDK và Cookbook

Railgun cung cấp một SDK toàn diện và được tài liệu rõ ràng mà các nhà phát triển ví hoặc ứng dụng dapp có thể sử dụng để xây dựng chức năng địa chỉ ẩn thông qua việc hỗ trợ Railgun. Railgun cũng có một cộng đồng được duy trì bởi gate.sách nấu ăn với “công thức” cho phép nhà phát triển dapp cung cấp các module cho Railgun cho phép người dùng tương tác với dapp của họ bằng cách sử dụng Railgun. Ví dụ, một nhà phát triển có thể viết một công thức cho một DEX cho phép người dùng có số dư token trong Railgun thực hiện trao đổi token một cách riêng tư.

RailGun v3

Phiên bản tiếp theo của Railgun sẽ làm giảm chi phí giao dịch khoảng 50% - 60%. Những thay đổi khác trong phiên bản 3 là chuyển đổi để hỗ trợ eip-4337 userops thông qua một mempool riêng. Ngoài ra, v3 sẽ cung cấp hỗ trợ cho một kiến trúc dựa trên ý định, cho phép các bộ giải quyết cạnh tranh để thực hiện tốt nhất, mặc dù chi tiết rất cao cấp vào thời điểm viết. Hiện tại, họ đang làm việc với CowSwaptrên điều này và kế hoạch sử dụng các pre và post hooks để cho phép các giải quyết viên truy cập vào các quỹ.

Kết nối Railgun

Một thay đổi có thể coi là thú vị nhất được đề xuất là một công cụ gọi là Railgun Connect, được mô tả là một công cụ tương tự như WalletConnect, trong đó nó cho phép địa chỉ 0zk kết nối với hầu hết các giao diện người dùng cho việc sử dụng riêng tư, mà không yêu cầu các ứng dụng phi tập trung đó cung cấp tích hợp cụ thể với Railgun thông qua các module tùy chỉnh.

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

Kết luận

Có một số đề xuất thú vị để định sẵn địa chỉ ẩn trong giao thức Ethereum. Ví dụ, Inco Sử dụng ý tưởng về một “trình bao bọc” ERC-20, bao bọc một 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 đều được thực hiện trên trạng thái được mã hóa thông qua mã hóa hoàn toàn đồng cấu. Inco dựa vào các bản 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 một ngày nào đó có thể chuyển sang Ethereum.

Có một đề xuất khác được gọi là EIP-7503: Zero-Knowledge Wormholesđược xây dựng dựa trên một thiết kế gọi là “proof-of-burn”, tuy nhiên điều này dường như không thu hút nhiều sự chú ý, có lẽ vì nó yêu cầu một bản cập nhật cho EVM, mà không có thì nó thực sự chỉ có thể được thực hiện ở mức độ mã thông báo, sử dụng một thiết kế erc-20 hỗ trợ eip-7503 cụ thể (hoặc nếu một L2 quyết định thêm hỗ trợ cho các mã opcode EVM của họ).

AztecCó lẽ đó là công nghệ bảo mật tinh vi nhất hiện nay, nhưng nó đòi hỏi người dùng phải chuyển khoản sang Aztec để sử dụng, điều này có thể hoặc không phải là một trải nghiệm người dùng không chấp nhận được đối với phần lớn người dùng. Tuy nhiên, nếu nhu cầu về quyền riêng tư giao dịch cơ bản tăng lên trong số người dùng Ethereum, thì Aztec có thể đưa ra một đề xuất giá trị duy nhất khiến nó trở thành một L2 rất có giá trị khi dapps và người dùng di chuyển sang một nền tảng mà mặc định mang lại cho họ quyền riêng tư.

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

Hỗ trợ Ví

Trong khi chúng ta đang chứng kiến sự áp dụng ngày càng tăng của các giao protocổ địa chỉ âm thầm, điều này là một dấu hiệu hứa hẹn, nhưng vẫn còn một số thách thức. Thách thức quan trọng nhất là họ chưa được hỗ trợ hoàn toàn trong các ví Ethereum phổ biến (ít nhất là cho đến bây giờ). Các ví phổ biến có lẽ sẽ phải đưa ra một số lựa chọn nếu họ muốn cung cấp hỗ trợ cho các địa chỉ âm thầm. Một số lựa chọn này bao gồm:

• Liệu họ sẽ cung cấp hỗ trợ có quan điểm cho một việc thực hiện duy nhất, hay họ sẽ xây dựng và duy trì một loại trình tự tổng hợp toàn diện qua nhiều giao thức? Khả năng cao là việc duy trì loại trình tự sau sẽ tốn kém về mặt phát triển và duy trì.
• Liệu có xem xét quy định, và họ có cần phải đưa ra quan điểm về mức độ và cơ chế cho việc làm mất ẩn danh theo lựa chọn (tức là giống như của Labyrinth)?
• Địa chỉ ẩn yêu cầu một phần trên chuỗi vis-à-vis hợp đồng đăng ký (ngoại trừ Fluidkey), điều này có nghĩa là mỗi mạng EVM đều phải được hỗ trợ một cách rõ ràng bởi ví (mặc dù thiết kế của Umbra giúp việc triển khai hợp đồng đăng ký một cách không cần sự cho phép).
• Địa chỉ ẩn làm cho các tích hợp hiện tại với các trình khám phá khối (ví dụ như Etherscan) phức tạp hơn. Ví dụ: Nút “Xem trên Trình khám phá” sẽ không hoạt động cho một địa chỉ meta ẩn, nơi ví tiền điện tử hiển thị tổng số dư. Vấn đề này có thể tồn tại cho các giao dịch chuyển khoản. Các trường hợp biên nhận khác nhau như thế này sẽ cần được suy nghĩ đến.
• Tùy thuộc vào cách triển khai cơ bản, người dùng chỉ có thể sử dụng địa chỉ ẩn danh một cách hiệu quả với một tập hợp cụ thể các ứng dụng phân tán (dapps), đó là những ứng dụng được hỗ trợ bởi giao thức cơ bản. Điều này sẽ được thực hiện thông qua kiến trúc địa chỉ ẩn danh linh hoạt. Tuy nhiên, không phải tất cả các dapps đều được hỗ trợ, và điều này sẽ cần được truyền đạt cho người dùng một cách nào đó. Việc này đôi khi đơn giản hơn với eip-5506, nhưng vẫn có những rắc rối và trường hợp biên giới của nó, và điều này thường xuyên ảnh hưởng đến giao diện người dùng của ví.

Cũng có khả năng cải thiện trong việc ngăn chặn việc bảo mật kém của người dùng, xem bài báo này: “Phân tích tính nặng danh của hệ thống địa chỉ ẩn danh Umbra trên Ethereum” về cách mà các tác giả đã thành công trong việc giải mã tên ẩn 48,5% giao dịch tiền ảo trên Ethereum mainnet. Các hêuristics họ sử dụng để làm điều này không liên quan gì đến các giao thức, và chủ yếu xoay quanh vệ sinh về quyền riêng tư, ví dụ, một người dùng gửi tiền vào một địa chỉ ẩn họ kiểm soát, sau đó gửi lại số tiền đó đến địa chỉ họ ban đầu gửi từ, nhầm tưởng rằng tính truy vết đã bị hỏng. Nhìn chung, các tác giả đã xác định 6 hêuristics khác nhau có thể được sử dụng để giải mã tên ẩn các giao dịch địa chỉ, hầu hết đều dựa vào việc không tuân theo các quy tắc tốt nhất. Tuy nhiên, đây là các vấn đề quan trọng về UX cần phải được giải quyết.

Nhìn chung, tôi khá lạc quan về địa chỉ ẩn danh, và quyền riêng tư trong Ethereum nói chung. Tôi nghĩ rằng chúng ta đã có những tiến bộ ấn tượng, và phát hiện ra một số thách thức rất có thể giải quyết. Tôi tin rằng các ví tiền chính thống sẽ tìm ra cách cung cấp mức hỗ trợ cho địa chỉ ẩn danh mà cho phép người dùng sử dụng chúng một cách dễ dàng và không cần suy nghĩ, mang lại mức độ quyền riêng tư bình thường mà người dùng mong đợi và xứng đáng.

Lời cảm ơn lớn lao đến tất cả các nhóm đã dành thời gian và công sứ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 viết này. Công việc và sự kiên trì của họ sẽ tạo ra sự khác biệt lớn cho Ethereum!

Thông báo miễn trừ trách nhiệm:

1. Bài viết này được tái bản từ [Trung bình]. All copyrights belong to the original author [Simon Brown]. Nếu có bất kỳ ý kiến ​​phản đối về việc tái bản này, vui lòng liên hệ với Gate Learnđội và họ sẽ xử lý nhanh chóng.
2. Miễn trách nhiệm về trách nhiệm: Các quan điểm và ý kiến được thể hiện trong bài viết này chỉ là của tác giả và không hình thành bất kỳ lời khuyên đầu tư nào.
3. Đội ngũ Học viện Gate thực hiện việc dịch bài viết sang các ngôn ngữ khác. Trừ khi có thông báo, việc sao chép, phân phối hoặc đạo văn bản dịch là không được phép.