Ethereum muốn giấu giao dịch của bạn khỏi bot: Một canh bạc mật mã không có lời giải

Vitalik bị Jaredfromsubway.eth tấn công MEV vào tháng 8 năm 2024. Điều trớ trêu: người tạo ra Ethereum, người hiểu rõ nhất hệ thống, cũng không thoát khỏi bot săn mồi. Nhưng giải pháp được đề xuất – LUCID (EIP-8184) – lại dựa trên một giả định mà chính tác giả thừa nhận: “không có cấu trúc mật mã nào đáp ứng được tất cả yêu cầu ở quy mô Ethereum.” Đây không phải là một bản nâng cấp thông thường. Đây là một canh bạc về mặt mã hóa, nơi mà sự thành công phụ thuộc vào việc tìm ra một primitive chưa từng tồn tại. Aztec dạy tôi rằng ẩn dữ liệu không đồng nghĩa với bảo mật. Năm 2021, khi tôi tối ưu proof size cho zk-rollup, tôi nhận ra rằng việc giấu thông tin chỉ là một phần của bài toán. Phần còn lại là ai có quyền mở khóa, và với điều kiện nào. LUCID về cơ bản là một cơ chế commit-reveal: block builder gửi giao dịch đã mã hóa, sau đó người gửi (hoặc một bên thứ ba) tiết lộ khóa giải mã. Vấn đề nằm ở chỗ: khâu giải mã được đặt bên ngoài giao thức cốt lõi, trao cho “key publisher” – một thực thể có thể là người gửi, hoặc một dịch vụ tập trung. Điều này không khác gì private relay hiện tại, ngoại trừ việc mempool được mã hóa thay vì bỏ qua. Trust vẫn tồn tại, chỉ là được di chuyển từ bot sang key publisher. Context: mempool công khai của Ethereum là nơi bot đọc giao dịch chưa xác nhận và thực hiện sandwich attack, frontrunning. Giải pháp hiện tại là private relay – giao dịch được gửi trực tiếp đến builder, bỏ qua mempool. Nhưng private relay tập trung quyền lực vào tay một số ít builder, tạo ra rủi ro kiểm duyệt và thao túng. LUCID và EIP-8105 (trust graph) nhằm mục đích phân tán quyền lực đó, nhưng lại tạo ra những rủi ro mới. Core: Hãy nhìn vào chi tiết kỹ thuật. LUCID giới hạn phần đỉnh block được mã hóa ở mức 1/8 gas limit. Tại sao? Bởi vì mã hóa toàn bộ block sẽ quá tốn kém về mặt tính toán và dung lượng. Nhưng 1/8 đồng nghĩa với việc chỉ một phần nhỏ giao dịch được bảo vệ. Phần còn lại vẫn nằm trong mempool công khai, vẫn là mồi cho bot. Vậy LUCID thực sự giải quyết được bao nhiêu phần trăm MEV? Có lẽ là rất nhỏ. Thêm vào đó, cơ chế “reserve fee” – một khoản tiền đặt cọc mà người gửi phải trả để giao dịch được đưa vào phần mã hóa – nếu khóa không được tiết lộ, khoản phí sẽ bị mất. Nhưng làm sao phân biệt được giữa một cuộc tấn công từ chối tiết lộ và một lỗi mạng? Giao thức không thể. Vậy người dùng hợp pháp có thể bị phạt oan. EIP-8105 đưa ra “directed trust graph” – mỗi nhà cung cấp đăng ký và chỉ định ai mà họ tin tưởng. Nhưng cơ chế trừng phạt kẻ xấu lại nằm hoàn toàn bên ngoài chuỗi, dựa vào danh tiếng và các thỏa thuận ngoài chuỗi. Điều này tạo ra một hệ thống “bạn bè” hơn là một giao thức không cần tin cậy. Aztec dạy tôi rằng zero-knowledge không phải là viên đạn bạc. Nó chỉ là một công cụ. Và công cụ nào cũng có giới hạn. Trong trường hợp này, ngay cả khi tìm được primitive mật mã hoàn hảo, vẫn còn vấn đề về hiệu suất. Một block Ethereum có thể chứa hàng trăm giao dịch. Mã hóa và giải mã từng giao dịch với yêu cầu non-interactive, small public key, strong CCA security, và quantum-safe path – đó là một danh sách yêu cầu mà hiện tại chưa có ai đáp ứng được. Tác giả EIP-8184 thừa nhận điều này. Vậy chúng ta đang nói về một giải pháp lý thuyết, có thể mất nhiều năm để hiện thực hóa, nếu không muốn nói là không bao giờ. Contrarian: Điểm mù lớn nhất mà bài báo gốc không nhấn mạnh là: LUCID và EIP-8105 có thể không nhằm mục đích “giết MEV” như lời quảng cáo. Mục tiêu thực sự có thể là làm tăng chi phí cho bot, khiến cho việc tấn công trở nên đắt đỏ hơn, thay vì loại bỏ hoàn toàn. Nếu một bot phải trả phí dự trữ và đối mặt với rủi ro mất tiền nếu khóa không được tiết lộ, thì mô hình kinh doanh của nó sẽ bị ảnh hưởng. Nhưng liệu điều này có đủ để ngăn chặn những kẻ tấn công có vốn lớn? Có lẽ không. Hơn nữa, việc kết hợp với FOCIL (EIP-7805) – danh sách bao gồm do nhiều validator đề xuất – có thể tạo ra một lớp phức tạp mới, nơi validator phải phối hợp để đảm bảo block builder không thể bỏ qua giao dịch. Nhưng sự phối hợp này lại mở ra cơ hội tấn công mới: nếu một validator ác ý cố tình không đưa giao dịch vào danh sách, thì sao? Cơ chế trừng phạt nào? Một lần nữa, mọi thứ lại dựa vào trust. Aztec dạy tôi rằng mỗi lớp trừu tượng đều mang một rủi ro mới. Khi bạn thêm một key publisher, bạn thêm một điểm lỗi. Khi bạn thêm một trust graph, bạn thêm một vector tấn công xã hội. Và khi bạn thêm FOCIL, bạn thêm độ phức tạp trong đồng thuận. Tất cả những điều này khiến cho hệ thống trở nên khó phân tích bảo mật hơn, và khó triển khai hơn trong thực tế. Tôi đã từng chứng kiến những dự án ZK hứa hẹn “privacy” nhưng cuối cùng lại phụ thuộc vào một trusted setup. LUCID cũng vậy: nó hứa hẹn một mempool không cần tin cậy, nhưng thực chất lại chuyển giao trust cho key publisher. Đó là một bước lùi so với private relay? Không hẳn, vì private relay ít nhất đã hoạt động được. LUCID vẫn đang ở giai đoạn giấy trắng mực đen. Takeaway: Ethereum đang cố gắng giải quyết vấn đề MEV bằng cách giấu giao dịch. Nhưng giấu không phải là bảo vệ. Nếu không có primitive mật mã đáp ứng được tất cả yêu cầu, thì LUCID sẽ mãi là một ý tưởng đẹp trên slide. Hegotá upgrade (2027) có thể là mốc thời gian lạc quan nhất, nhưng tôi cá rằng trước đó, chúng ta sẽ thấy private relay chiếm lĩnh thị trường, và các bot sẽ tìm ra cách đọc giao dịch mã hóa thông qua side-channel hoặc tấn công vào key publisher. Câu hỏi không phải là “liệu LUCID có hoạt động không?”, mà là “liệu cộng đồng Ethereum có chấp nhận đánh đổi trust lấy privacy không?” Với tôi, câu trả lời là: chưa sẵn sàng.