Tôi thích việc ngày càng có nhiều nghiên cứu về quyền riêng tư ở cấp độ RPC. Đây là một phần chưa được nghiên cứu nhiều, chưa được đánh giá cao trong quyền riêng tư của Ethereum và xứng đáng có một giải pháp. Thật không may, việc xoay vòng các RPC không phải là giải pháp đó, ít nhất là dưới hình thức được mô tả ở đây. Đây là lý do tại sao 🧵

𝗣𝗿𝗼𝗯𝗹𝗲𝗺 𝟭: Không nhà cung cấp nào có thể liên kết địa chỉ Ethereum của bạn với địa chỉ IP của bạn. 𝗣𝗿𝗼𝗯𝗹𝗲𝗺 𝟮: Không nhà cung cấp nào có thể liên kết hai địa chỉ Ethereum của bạn với nhau. Điều này đặc biệt quan trọng trong bối cảnh của các địa chỉ ẩn.

Giải pháp đầu tiên được đề xuất không giải quyết được vấn đề nào. Thực tế, nó làm cho vấn đề 1 trở nên 𝙷𝙾𝚁𝚂𝙴: thay vì một nhà cung cấp biết địa chỉ IP và Ethereum của bạn, giờ đây 𝙼𝚄𝙻𝚃𝙸𝙿𝙻𝙴 nhà cung cấp như vậy biết cả hai.

Giải pháp thứ hai giải quyết vấn đề 1 bằng cách giới thiệu một middleware trong TEE. Nó về cơ bản là một proxy mù, mà sự mù quáng được cung cấp bởi TEE. Nhưng vấn đề 2 vẫn chưa được giải quyết: Các nhà cung cấp vẫn có thể liên kết các địa chỉ Ethereum của bạn với nhau.

TEEs không phải là không thể bị tấn công. Nhưng ngay cả khi chúng ta giả định rằng chúng hoạt động như mong muốn, khách hàng vẫn cần xác minh rằng phần mềm trung gian mà họ đang giao tiếp thực sự đang chạy trong một TEE. Nếu không, khách hàng (ví dụ: ví điện tử) không thể chắc chắn rằng phần mềm trung gian không thực sự ghi lại mọi thứ.

Khách hàng có thể xác minh điều này bằng cách thực hiện một điệu nhảy chứng thực khối lượng công việc. Điều này có thể, nhưng phức tạp để triển khai. Tôi chưa thấy một triển khai thực tế nào của điều này, và tôi không rõ liệu điều đó có dễ triển khai hơn việc chỉ tích hợp một mạng trộn thực sự hay không.

Một proxy nên không biết những gì nó truyền qua. Mật mã học giải quyết điều này mà không cần giả định về độ tin cậy của TEE. Các mạng trộn như Tor/Nym/HOPR hoạt động theo cách này: Mã hóa dữ liệu trong nhiều lớp mã hóa, nơi mỗi bước sẽ bóc một lớp mã hóa ra khỏi củ hành.

Tại sao mixnets không được sử dụng ngày nay? - Người dùng không yêu cầu quyền riêng tư ở cấp độ RPC từ các nhà phát triển ví của họ. Walletbeat khắc phục điều này. - Kỳ vọng UX RPC <100ms. Mixnets/middleware làm tăng độ trễ. - Tích hợp vào ví trình duyệt yêu cầu phải triển khai lại TLS trong JS để mã hóa bước cuối.

Chỉ riêng Mixnets cũng không giải quyết được vấn đề 2. Vấn đề vẫn là việc xoay vòng các RPC một cách ngây thơ (nhà cung cấp ngẫu nhiên cho mỗi yêu cầu) thực sự là 𝙡𝙚𝙩𝙝𝙚𝙧 cho quyền riêng tư: điều này có nghĩa là nhiều nhà cung cấp sẽ thấy nhiều địa chỉ của bạn theo thời gian.

Giải pháp tốt hơn: đối với một RPC về `address`, luôn gửi nó đến nhà cung cấp #`hash(address) modulo num_providers`. Nói cách khác, các truy vấn về cùng một địa chỉ sẽ được gửi đến cùng một nhà cung cấp RPC. Điều này đảm bảo rằng không có nhà cung cấp nào biết toàn bộ tập hợp địa chỉ của bạn.

Cũng tốt hơn khi có nhiều nhà cung cấp hơn là số địa chỉ bạn có. Bằng cách này, mỗi nhà cung cấp chỉ biết một trong các địa chỉ của bạn, hoặc không biết địa chỉ nào; không bao giờ biết nhiều địa chỉ. Nhưng cách khắc phục thực sự? - Chạy nút của riêng bạn! - Yêu cầu nhà phát triển ví của bạn bắt đầu quan tâm đến quyền riêng tư ở cấp độ RPC.

Những điều tôi chưa đề cập nhưng cũng quan trọng: - Các cuộc tấn công tương quan thời gian RPC. - Ví tìm kiếm số dư của nhiều địa chỉ trong một RPC. - Các yêu cầu không phải Ethereum mà rò rỉ dữ liệu tương tự. Ví ngày nay đầy những cái đó; hỏi tôi làm sao tôi biết. - L2 với các điểm cuối tập trung. (cười lớn)

Ngay cả khi chủ đề này có vẻ chỉ trích công việc của @jimouris, tôi muốn nhấn mạnh rằng nó không có ý định chỉ trích. Tôi rất tôn trọng bất kỳ ai thực sự đứng ra giải quyết vấn đề này. Đây là một lĩnh vực chưa được nghiên cứu nhiều và cần được chú ý hơn, vì vậy thật đáng mừng khi thấy mọi người đang làm việc trên đó.