Tác giả | Pranav Garimidi, Joseph Bonneau, Lioba Heimbach, a16z
Biên dịch | Saoirse, Foresight News
Trong blockchain, việc kiếm tiền thông qua việc quyết định giao dịch nào được đóng gói vào khối, giao dịch nào bị loại trừ, hoặc điều chỉnh thứ tự giao dịch, giá trị tối đa có thể kiếm được từ những hoạt động này được gọi là "Giá trị có thể trích xuất tối đa", viết tắt là MEV. MEV tồn tại phổ biến trong hầu hết các blockchain và luôn là chủ đề được ngành công nghiệp quan tâm và thảo luận.
Nhiều nhà nghiên cứu khi quan sát hiện tượng MEV đã đặt ra một câu hỏi rõ ràng: Liệu công nghệ mã hóa có thể giải quyết vấn đề này không? Một trong những giải pháp là sử dụng bộ nhớ giao dịch mã hóa: Người dùng phát sóng giao dịch đã được mã hóa, và những giao dịch này chỉ được giải mã và công khai sau khi hoàn tất việc sắp xếp. Như vậy, giao thức đồng thuận sẽ phải "chọn mù" thứ tự giao dịch, điều này dường như có thể ngăn chặn việc lợi dụng cơ hội MEV trong giai đoạn sắp xếp.
Nhưng thật không may, cả về mặt ứng dụng thực tế và lý thuyết, bộ nhớ pool mã hóa không thể cung cấp giải pháp chung cho vấn đề MEV. Bài viết này sẽ trình bày những khó khăn trong đó và khám phá hướng thiết kế khả thi cho bộ nhớ pool mã hóa.
Cách hoạt động của bể nhớ tiền mã hóa
Về bộ nhớ crypto, đã có nhiều đề xuất, nhưng khung chung của nó như sau:
Người dùng phát sóng giao dịch đã được mã hóa.
Giao dịch mã hóa được gửi lên chuỗi (trong một số đề xuất, giao dịch cần phải trải qua quá trình xáo trộn ngẫu nhiên có thể xác minh trước).
Khi các khối chứa các giao dịch này được xác nhận cuối cùng, giao dịch sẽ được giải mã.
Cuối cùng thực hiện các giao dịch này.
Cần lưu ý rằng, bước 3 (Giải mã giao dịch) có một vấn đề quan trọng: Ai sẽ chịu trách nhiệm giải mã? Nếu giải mã không hoàn thành thì sao? Một ý tưởng đơn giản là để người dùng tự giải mã giao dịch của họ (trong trường hợp này thậm chí không cần mã hóa, chỉ cần ẩn cam kết là đủ). Nhưng cách này có lỗ hổng: Kẻ tấn công có thể thực hiện MEV đầu cơ.
Trong MEV đầu cơ, kẻ tấn công sẽ đoán rằng một giao dịch tiền điện tử nào đó chứa cơ hội MEV, sau đó mã hóa giao dịch của mình và cố gắng chèn nó vào vị trí thuận lợi (chẳng hạn như trước hoặc sau giao dịch mục tiêu). Nếu các giao dịch được sắp xếp theo thứ tự mong đợi, kẻ tấn công sẽ giải mã và thông qua giao dịch của mình để trích xuất MEV; nếu không đạt được mong đợi, họ sẽ từ chối giải mã và giao dịch của họ sẽ không được đưa vào chuỗi khối cuối cùng.
Có thể áp dụng hình phạt đối với người dùng không giải mã thành công, nhưng việc thực hiện cơ chế này rất khó khăn. Nguyên nhân là: tất cả hình phạt cho các giao dịch mã hóa phải đồng nhất (dù sao cũng không thể phân biệt giao dịch sau khi mã hóa), và hình phạt phải đủ nghiêm khắc, ngay cả khi đối mặt với mục tiêu có giá trị cao cũng có thể kiềm chế MEV đầu cơ. Điều này sẽ dẫn đến một lượng lớn vốn bị khóa lại, và những khoản tiền này cần phải giữ tính ẩn danh (để tránh tiết lộ mối liên hệ giữa giao dịch và người dùng). Thậm chí phức tạp hơn, nếu do lỗi chương trình hoặc sự cố mạng khiến người dùng thực không thể giải mã bình thường, họ cũng sẽ chịu tổn thất vì điều đó.
Do đó, hầu hết các giải pháp đề xuất khi mã hóa giao dịch, cần đảm bảo rằng chúng có thể được giải mã vào một thời điểm nào đó trong tương lai, ngay cả khi người dùng khởi tạo giao dịch ngoại tuyến hoặc từ chối hợp tác. Mục tiêu này có thể được đạt được thông qua một vài cách sau:
Môi trường thực thi đáng tin cậy (TEE): Người dùng có thể mã hóa giao dịch bằng khóa được lưu trữ trong khu vực bảo mật của môi trường thực thi đáng tin cậy (TEE). Trong một số phiên bản cơ bản, TEE chỉ được sử dụng để giải mã giao dịch sau một thời điểm nhất định (điều này yêu cầu TEE phải có khả năng cảm nhận thời gian bên trong). Các giải pháp phức tạp hơn cho phép TEE chịu trách nhiệm giải mã giao dịch và xây dựng khối, sắp xếp giao dịch dựa trên thời gian đến, phí và các tiêu chuẩn khác. So với các giải pháp bộ nhớ mã hóa khác, lợi thế của TEE là khả năng xử lý trực tiếp giao dịch ở dạng rõ, giảm thông tin dư thừa trên chuỗi bằng cách lọc các giao dịch có thể bị quay lại. Tuy nhiên, nhược điểm của phương pháp này là phụ thuộc vào độ tin cậy của phần cứng.
Chia sẻ bí mật và mã hóa ngưỡng (Secret-sharing and threshold encryption): Trong phương án này, người dùng mã hóa giao dịch bằng một khóa mà khóa này được một ủy ban cụ thể (thường là một tập hợp con của các xác thực viên) cùng nắm giữ. Việc giải mã cần phải đáp ứng một số điều kiện ngưỡng nhất định (ví dụ, hai phần ba thành viên trong ủy ban đồng ý).
Khi áp dụng giải mã ngưỡng, phương tiện tin cậy chuyển từ phần cứng sang ủy ban. Những người ủng hộ cho rằng, vì hầu hết các giao thức đã mặc định rằng các xác thực có tính "đa số trung thực" trong cơ chế đồng thuận, chúng ta cũng có thể đưa ra giả định tương tự, rằng đa số các xác thực sẽ giữ trung thực và không giải mã giao dịch trước.
Tuy nhiên, cần lưu ý một sự khác biệt quan trọng ở đây: Hai giả thuyết về niềm tin này không phải là cùng một khái niệm. Các thất bại đồng thuận như phân nhánh blockchain có tính công khai (thuộc về "giả thuyết niềm tin yếu"), trong khi các ủy ban ác ý giải mã giao dịch trước một cách riêng tư sẽ không để lại bất kỳ bằng chứng công khai nào, loại tấn công này không thể bị phát hiện và cũng không thể bị trừng phạt (thuộc về "giả thuyết niềm tin mạnh"). Do đó, mặc dù nhìn bề ngoài, cơ chế đồng thuận và giả thuyết an ninh của ủy ban mã hóa có vẻ nhất quán, nhưng trong thực tế, tính khả thi của giả thuyết "ủy ban sẽ không thông đồng" lại thấp hơn nhiều.
Khóa thời gian và mã hóa trì hoãn (Time-lock and delay encryption): Là một giải pháp thay thế cho mã hóa ngưỡng, nguyên lý của mã hóa trì hoãn là: Người dùng mã hóa giao dịch đến một khóa công khai nào đó, trong khi khóa riêng tương ứng với khóa công khai đó được ẩn trong một câu đố khóa thời gian. Câu đố khóa thời gian là một câu đố mật mã học bao bọc bí mật, nội dung bí mật cần được tiết lộ sau khoảng thời gian đã định trước, cụ thể hơn, quá trình giải mã cần thực hiện lặp lại một loạt các phép toán không thể thực hiện song song. Dưới cơ chế này, bất kỳ ai cũng có thể giải câu đố để lấy khóa và giải mã giao dịch, nhưng điều kiện là phải hoàn thành một đoạn tính toán chậm thiết kế đủ dài (về bản chất là thực hiện tuần tự) nhằm đảm bảo giao dịch không thể được giải mã trước khi xác nhận cuối cùng. Hình thức mạnh nhất của nguyên thủy mã hóa này là thông qua công nghệ mã hóa trì hoãn để công khai tạo ra các câu đố như vậy; cũng có thể thông qua ủy ban đáng tin cậy với sự trợ giúp của mã hóa khóa thời gian để gần như thực hiện quá trình này, mặc dù lúc này lợi thế tương đối so với mã hóa ngưỡng đã đáng để bàn cãi.
Dù là sử dụng mã hóa trễ hay thực hiện tính toán bởi một ủy ban đáng tin cậy, các giải pháp này đều phải đối mặt với nhiều thách thức thực tiễn: trước tiên, do tính chất của độ trễ phụ thuộc vào quá trình tính toán, rất khó để đảm bảo độ chính xác của thời gian giải mã; thứ hai, các giải pháp này cần phụ thuộc vào các thực thể cụ thể để vận hành phần cứng hiệu suất cao nhằm giải quyết các câu đố một cách hiệu quả, mặc dù bất kỳ ai cũng có thể đảm nhận vai trò này, nhưng cách nào để khuyến khích thực thể đó tham gia vẫn chưa rõ ràng; cuối cùng, trong thiết kế loại này, tất cả các giao dịch được phát sóng sẽ được giải mã, bao gồm cả những giao dịch chưa bao giờ được ghi vào khối cuối cùng. Trong khi đó, các giải pháp dựa trên ngưỡng (hoặc mã hóa chứng kiến) có thể chỉ giải mã những giao dịch đã được bao gồm thành công.
Mã hóa chứng kiến (Witness encryption): Giải pháp mật mã tiên tiến nhất cuối cùng là sử dụng công nghệ «mã hóa chứng kiến». Về lý thuyết, cơ chế của mã hóa chứng kiến là: sau khi thông tin được mã hóa, chỉ những người biết mối quan hệ NP cụ thể tương ứng với «thông tin chứng kiến» mới có thể giải mã nó. Ví dụ, thông tin có thể được mã hóa như: chỉ những người có thể giải một câu đố Sudoku nhất định, hoặc có thể cung cấp một hình ảnh băm giá trị nhất định mới có thể hoàn thành việc giải mã.
(Chú ý: Mối quan hệ NP là mối quan hệ giữa "vấn đề" và "câu trả lời có thể xác minh nhanh chóng")
Đối với bất kỳ mối quan hệ NP nào, có thể thực hiện logic tương tự thông qua SNARKs. Có thể nói, chứng minh mật mã về cơ bản là mã hóa dữ liệu theo cách mà chỉ những chủ thể có thể chứng minh thông qua SNARK rằng họ thỏa mãn các điều kiện cụ thể mới có thể giải mã. Trong kịch bản bộ nhớ mã hóa, một ví dụ điển hình về các điều kiện này là: giao dịch chỉ có thể được giải mã sau khi khối được xác nhận cuối cùng.
Đây là một loại nguyên ngữ lý thuyết có tiềm năng lớn. Thực tế, nó là một giải pháp tổng quát, dựa trên phương pháp ủy ban và phương pháp dựa trên độ trễ chỉ là những hình thức ứng dụng cụ thể của nó. Thật không may, hiện tại chúng ta vẫn chưa có bất kỳ giải pháp mã hóa dựa trên chứng nhận nào có thể thực hiện được. Hơn nữa, ngay cả khi có những giải pháp như vậy, cũng khó có thể nói rằng nó có ưu thế hơn phương pháp dựa trên ủy ban trong chuỗi bằng chứng cổ phần. Ngay cả khi thiết lập mã hóa chứng nhận là "chỉ khi giao dịch được sắp xếp trong khối đã được xác nhận cuối cùng mới có thể giải mã", ủy ban độc hại vẫn có thể lén lút mô phỏng giao thức đồng thuận để giả mạo trạng thái xác nhận cuối cùng của giao dịch, sau đó sử dụng chuỗi riêng này như một "chứng nhận" để giải mã giao dịch. Lúc này, việc cùng một ủy ban sử dụng giải mã ngưỡng cũng có thể đạt được mức độ an toàn tương đương, và thao tác còn đơn giản hơn nhiều.
Tuy nhiên, trong giao thức đồng thuận chứng minh công việc, lợi thế của việc chứng thực mã hóa trở nên rõ ràng hơn. Bởi vì ngay cả khi ủy ban hoàn toàn ác ý, họ cũng không thể khai thác nhiều khối mới một cách bí mật ở đầu chuỗi khối hiện tại để giả mạo trạng thái xác nhận cuối cùng.
Những thách thức kỹ thuật mà bể nhớ mã hóa phải đối mặt
Nhiều thách thức thực tế đang hạn chế khả năng của các pool nhớ crypto trong việc phòng ngừa MEV. Tổng thể, việc bảo mật thông tin bản thân đã là một vấn đề khó khăn. Đáng chú ý là, việc ứng dụng công nghệ mã hóa trong lĩnh vực Web3 không phổ biến, nhưng hàng thập kỷ thực hành triển khai công nghệ mã hóa trong các mạng (như TLS/HTTPS) và truyền thông riêng tư (từ PGP đến Signal, WhatsApp và các nền tảng nhắn tin mã hóa hiện đại khác) đã phơi bày đầy đủ những khó khăn của nó: mã hóa mặc dù là công cụ bảo vệ tính bảo mật, nhưng không thể đảm bảo tuyệt đối.
Đầu tiên, một số chủ thể có thể trực tiếp truy cập thông tin giao dịch của người dùng dưới dạng văn bản rõ. Trong tình huống điển hình, người dùng thường không tự mã hóa giao dịch mà giao công việc này cho nhà cung cấp dịch vụ ví. Như vậy, nhà cung cấp dịch vụ ví có thể tiếp cận văn bản giao dịch, thậm chí có thể sử dụng hoặc bán những thông tin này để thu được MEV. Độ an toàn của mã hóa luôn phụ thuộc vào tất cả các chủ thể có thể tiếp cận khóa. Phạm vi kiểm soát khóa chính là ranh giới của sự an toàn.
Ngoài ra, vấn đề lớn nhất nằm ở siêu dữ liệu, tức là dữ liệu chưa mã hóa xung quanh tải trọng mã hóa (giao dịch). Các nhà tìm kiếm có thể lợi dụng những siêu dữ liệu này để suy đoán ý định giao dịch, từ đó thực hiện MEV đầu cơ. Cần biết rằng, các nhà tìm kiếm không cần phải hiểu toàn bộ nội dung giao dịch, cũng không nhất thiết phải đoán đúng mỗi lần. Ví dụ, chỉ cần họ có thể xác định với xác suất hợp lý rằng một giao dịch nào đó đến từ một lệnh mua của sàn giao dịch phi tập trung (DEX) cụ thể, là đủ để phát động tấn công.
Chúng ta có thể phân loại siêu dữ liệu thành vài loại: một loại là các vấn đề cổ điển vốn có của công nghệ mã hóa, loại còn lại là các vấn đề đặc thù của bộ nhớ mã hóa.
Kích thước giao dịch: Chính bản thân mã hóa không thể ẩn kích thước của bản rõ (đáng lưu ý rằng, trong định nghĩa chính thức về an toàn ngữ nghĩa, việc ẩn kích thước bản rõ bị loại trừ). Đây là một vectơ tấn công phổ biến trong giao tiếp mã hóa, ví dụ điển hình là, ngay cả khi đã được mã hóa, kẻ nghe lén vẫn có thể xác định nội dung đang phát trên Netflix theo kích thước của từng gói dữ liệu trong luồng video theo thời gian thực. Trong bộ nhớ mã hóa, các loại giao dịch cụ thể có thể có kích thước độc đáo, từ đó rò rỉ thông tin.
Thời gian phát sóng: Mã hóa cũng không thể che giấu thông tin thời gian (đây là một vector tấn công cổ điển khác). Trong bối cảnh Web3, một số người gửi (như trong các tình huống bán tháo có cấu trúc) có thể khởi tạo giao dịch theo khoảng thời gian cố định. Thời gian giao dịch cũng có thể liên quan đến các thông tin khác, chẳng hạn như hoạt động của các sàn giao dịch bên ngoài hoặc các sự kiện tin tức. Một cách sử dụng thông tin thời gian tinh vi hơn là chênh lệch giá giữa sàn giao dịch tập trung (CEX) và sàn giao dịch phi tập trung (DEX): Người sắp xếp có thể lợi dụng thông tin giá CEX mới nhất bằng cách chèn các giao dịch được tạo ra muộn nhất có thể; đồng thời, người sắp xếp có thể loại trừ tất cả các giao dịch khác được phát sóng sau một thời điểm nhất định (dù có mã hóa), đảm bảo giao dịch của mình độc quyền lợi thế về giá mới nhất.
Địa chỉ IP nguồn: Người tìm kiếm có thể suy luận danh tính người gửi giao dịch bằng cách theo dõi mạng ngang hàng và lần theo địa chỉ IP nguồn. Vấn đề này đã được phát hiện từ những ngày đầu của Bitcoin (đến nay đã hơn mười năm). Nếu người gửi cụ thể có một mô hình hành vi cố định, điều này có giá trị rất lớn đối với người tìm kiếm. Ví dụ, khi biết danh tính người gửi, có thể liên kết giao dịch tiền mã hóa với các giao dịch lịch sử đã được giải mã.
Thông tin người gửi giao dịch và phí / gas: Phí giao dịch là một loại siêu dữ liệu đặc trưng cho bộ nhớ tiền điện tử. Trong Ethereum, giao dịch truyền thống bao gồm địa chỉ người gửi trên chuỗi (để thanh toán phí), ngân sách gas tối đa và phí gas mà người gửi sẵn sàng trả. Tương tự như địa chỉ mạng nguồn, địa chỉ người gửi có thể được sử dụng để liên kết nhiều giao dịch và thực thể thực tế; ngân sách gas có thể ám chỉ ý định giao dịch. Ví dụ, việc tương tác với một DEX cụ thể có thể yêu cầu một lượng gas cố định có thể nhận dạng.
Những người tìm kiếm phức tạp có thể kết hợp nhiều loại siêu dữ liệu như đã nêu ở trên để dự đoán nội dung giao dịch.
Về lý thuyết, tất cả những thông tin này đều có thể được ẩn đi, nhưng phải trả giá bằng hiệu suất và độ phức tạp. Ví dụ, việc làm đầy giao dịch đến độ dài tiêu chuẩn có thể ẩn kích thước, nhưng sẽ lãng phí băng thông và không gian trên chuỗi; tăng độ trễ trước khi gửi có thể ẩn thời gian, nhưng sẽ làm tăng độ trễ; nộp giao dịch qua mạng ẩn danh như Tor có thể ẩn địa chỉ IP, nhưng điều này lại mang đến những thách thức mới.
Dữ liệu metadata khó ẩn nhất là thông tin phí giao dịch. Dữ liệu phí mã hóa gây ra một loạt vấn đề cho các nhà xây dựng khối: đầu tiên là vấn đề thông tin rác, nếu dữ liệu phí giao dịch được mã hóa, bất kỳ ai cũng có thể phát sóng giao dịch mã hóa có định dạng sai, những giao dịch này sẽ được sắp xếp nhưng không thể thanh toán phí, và khi giải mã sẽ không thể thực hiện nhưng không ai có thể bị truy cứu trách nhiệm. Điều này có thể được giải quyết thông qua SNARKs, tức là chứng minh định dạng giao dịch là đúng và có đủ tiền, nhưng sẽ làm tăng đáng kể chi phí.
Thứ hai là vấn đề hiệu quả trong việc xây dựng khối và đấu giá phí. Người xây dựng dựa vào thông tin phí để tạo ra khối tối đa hóa lợi nhuận và xác định giá thị trường hiện tại của tài nguyên trên chuỗi. Dữ liệu phí mã hóa có thể phá vỡ quá trình này. Một giải pháp là đặt phí cố định cho mỗi khối, nhưng điều này về mặt kinh tế là kém hiệu quả và có thể gây ra một thị trường thứ cấp cho việc đóng gói giao dịch, trái với mục đích thiết kế của bộ nhớ mã hóa. Một giải pháp khác là đấu giá phí thông qua tính toán đa bên an toàn hoặc phần cứng đáng tin cậy, nhưng cả hai phương pháp này đều có chi phí rất cao.
Cuối cùng, một bể nhớ mã hóa an toàn sẽ làm tăng chi phí hệ thống từ nhiều khía cạnh: mã hóa sẽ làm tăng độ trễ của chuỗi, khối lượng tính toán và tiêu thụ băng thông; cách kết hợp với các mục tiêu quan trọng trong tương lai như phân mảnh hoặc thực thi song song vẫn chưa rõ ràng; cũng có thể đưa ra các điểm lỗi mới cho tính khả dụng (liveness) (như ủy ban giải mã trong các kế hoạch ngưỡng, bộ giải hàm độ trễ); đồng thời, độ phức tạp thiết kế và thực hiện cũng sẽ tăng đáng kể.
Nhiều vấn đề của bể nhớ crypto có liên quan đến những thách thức mà blockchain nhằm bảo vệ quyền riêng tư giao dịch (như Zcash, Monero) đang phải đối mặt. Nếu có điều gì tích cực, thì đó là: Giải quyết tất cả các thách thức của công nghệ mã hóa trong việc giảm thiểu MEV sẽ đồng thời dọn đường cho quyền riêng tư giao dịch.
Những thách thức kinh tế mà bể nhớ mã hóa phải đối mặt
Cuối cùng, các bể nhớ mã hóa còn phải đối mặt với những thách thức về mặt kinh tế. Khác với những thách thức về công nghệ, những thách thức này có thể được giảm bớt dần dần thông qua việc đầu tư kỹ thuật đủ. Những thách thức kinh tế này thuộc về những hạn chế cơ bản, rất khó để giải quyết.
Vấn đề cốt lõi của MEV xuất phát từ sự bất đối xứng thông tin giữa người tạo giao dịch (người dùng) và những người khai thác cơ hội MEV (người tìm kiếm và người xây dựng khối). Người dùng thường không nhận thức được giá trị có thể khai thác trong giao dịch của họ, vì vậy ngay cả khi có một bộ nhớ mã hóa hoàn hảo, họ vẫn có thể bị dụ dỗ tiết lộ khóa giải mã để đổi lấy một phần thưởng thấp hơn giá trị thực tế của MEV, hiện tượng này được gọi là "giải mã có động lực".
Cảnh tượng này không khó để tưởng tượng, vì cơ chế tương tự như MEV Share đã tồn tại trong thực tế. MEV Share là một cơ chế đấu giá luồng đơn hàng, cho phép người dùng chọn lọc gửi thông tin giao dịch vào một bể, và các tìm kiếm cạnh tranh để có quyền khai thác cơ hội MEV từ giao dịch đó. Người thắng thầu sau khi khai thác MEV sẽ hoàn trả một phần lợi nhuận (tức là số tiền thầu hoặc tỷ lệ nhất định của nó) cho người dùng.
Mô hình này có thể thích ứng trực tiếp với bể nhớ mã hóa: Người dùng cần tiết lộ khóa giải mã (hoặc một phần thông tin) để tham gia. Nhưng hầu hết người dùng không nhận ra chi phí cơ hội của việc tham gia vào cơ chế này, họ chỉ thấy lợi ích trước mắt và sẵn lòng tiết lộ thông tin. Trong tài chính truyền thống cũng có những trường hợp tương tự: chẳng hạn như nền tảng giao dịch không hoa hồng Robinhood, mô hình lợi nhuận của nó chính là thông qua "thanh toán cho dòng lệnh" (payment-for-order-flow) bán dòng lệnh người dùng cho bên thứ ba.
Một kịch bản khả thi khác là: các nhà xây dựng lớn, với lý do kiểm duyệt, buộc người dùng phải tiết lộ nội dung giao dịch (hoặc thông tin liên quan). Khả năng chống kiểm duyệt là một chủ đề quan trọng và gây tranh cãi trong lĩnh vực Web3, nhưng nếu các xác thực viên lớn hoặc các nhà xây dựng bị ràng buộc bởi pháp luật (như quy định của Văn phòng Kiểm soát Tài sản Nước ngoài Hoa Kỳ - OFAC) phải thực hiện danh sách kiểm tra kiểm duyệt, họ có thể từ chối xử lý bất kỳ giao dịch tiền điện tử nào. Về mặt kỹ thuật, người dùng có thể chứng minh giao dịch tiền điện tử của họ tuân thủ yêu cầu kiểm duyệt thông qua bằng chứng không kiến thức, nhưng điều này sẽ làm tăng chi phí và độ phức tạp. Ngay cả khi blockchain có khả năng chống kiểm duyệt mạnh (đảm bảo rằng giao dịch tiền điện tử nhất định sẽ được ghi nhận), các nhà xây dựng vẫn có thể ưu tiên đưa các giao dịch có văn bản rõ ràng đã biết lên đầu khối, trong khi các giao dịch mã hóa bị xếp ở cuối. Do đó, những người cần đảm bảo ưu tiên thực hiện giao dịch cuối cùng có thể vẫn bị buộc phải tiết lộ nội dung cho các nhà xây dựng.
Các thách thức khác về hiệu quả
Bể nhớ mã hóa sẽ làm tăng chi phí hệ thống theo nhiều cách rõ ràng. Người dùng cần mã hóa giao dịch, hệ thống cũng cần giải mã theo một cách nào đó, điều này sẽ làm tăng chi phí tính toán và có thể làm tăng kích thước giao dịch. Như đã đề cập trước đó, việc xử lý siêu dữ liệu sẽ làm trầm trọng thêm những chi phí này. Tuy nhiên, còn một số chi phí hiệu quả không rõ ràng như vậy. Trong lĩnh vực tài chính, nếu giá cả có thể phản ánh tất cả thông tin có sẵn, thị trường được coi là hiệu quả; trong khi đó, độ trễ và thông tin không đối xứng sẽ dẫn đến sự kém hiệu quả của thị trường. Đây chính là kết quả tất yếu của bể nhớ mã hóa.
Sự kém hiệu quả này sẽ dẫn đến một hậu quả trực tiếp: tăng độ không chắc chắn về giá, đây là sản phẩm trực tiếp của việc tăng độ trễ trong các bể nhớ tiền mã hóa. Do đó, số lượng giao dịch thất bại do vượt quá mức độ chấp nhận trượt giá có thể gia tăng, từ đó lãng phí không gian trên chuỗi.
Tương tự, sự không chắc chắn về giá cả này cũng có thể tạo ra các giao dịch MEV đầu cơ, loại giao dịch này cố gắng kiếm lợi từ việc chênh lệch giá trên chuỗi. Cần lưu ý rằng, bộ nhớ trong của tiền điện tử có thể làm cho các cơ hội này trở nên phổ biến hơn: do độ trễ trong việc thực hiện, trạng thái hiện tại của sàn giao dịch phi tập trung (DEX) trở nên mơ hồ hơn, điều này rất có thể dẫn đến sự giảm hiệu quả của thị trường và xuất hiện sự chênh lệch giá giữa các nền tảng giao dịch khác nhau. Các giao dịch MEV đầu cơ như vậy cũng sẽ lãng phí không gian khối, vì một khi không phát hiện được cơ hội chênh lệch giá, chúng thường sẽ dừng thực hiện.
Tóm tắt
Bài viết này nhằm mục đích tổng hợp những thách thức mà các bể nhớ tiền điện tử đang đối mặt, để mọi người có thể chuyển sự chú ý sang việc phát triển các giải pháp khác, nhưng bể nhớ tiền điện tử vẫn có thể trở thành một phần của các giải pháp quản trị MEV.
Một hướng đi khả thi là thiết kế hỗn hợp: một phần giao dịch được thực hiện thông qua bể nhớ mã hóa để đạt được "sắp xếp mù", phần còn lại sử dụng các phương án sắp xếp khác. Đối với các loại giao dịch cụ thể (ví dụ như lệnh mua bán của các nhà đầu tư lớn, những người có khả năng mã hóa hoặc làm đầy giao dịch một cách cẩn thận và sẵn sàng trả chi phí cao hơn để tránh MEV), thiết kế hỗn hợp có thể là lựa chọn phù hợp. Đối với các giao dịch nhạy cảm cao (như giao dịch sửa lỗi các hợp đồng an toàn có lỗ hổng), thiết kế này cũng có ý nghĩa thực tiễn.
Tuy nhiên, do các hạn chế về công nghệ, độ phức tạp cao của các kỹ thuật và chi phí hiệu suất, bộ nhớ mã hóa khó có khả năng trở thành "giải pháp toàn diện cho MEV" như người ta mong đợi. Cộng đồng cần phát triển các giải pháp khác, bao gồm đấu giá MEV, cơ chế phòng thủ ứng dụng và rút ngắn thời gian xác nhận cuối cùng. MEV vẫn sẽ là một thách thức trong một khoảng thời gian tới, cần tìm ra điểm cân bằng giữa các giải pháp thông qua nghiên cứu sâu sắc nhằm đối phó với những tác động tiêu cực của nó.
Trang này có thể chứa nội dung của bên thứ ba, được cung cấp chỉ nhằm mục đích thông tin (không phải là tuyên bố/bảo đảm) và không được coi là sự chứng thực cho quan điểm của Gate hoặc là lời khuyên về tài chính hoặc chuyên môn. Xem Tuyên bố từ chối trách nhiệm để biết chi tiết.
a16z: Tại sao mã hóa memory pool lại khó trở thành thuốc giải cứu vạn năng cho MEV?
Tác giả | Pranav Garimidi, Joseph Bonneau, Lioba Heimbach, a16z
Biên dịch | Saoirse, Foresight News
Trong blockchain, việc kiếm tiền thông qua việc quyết định giao dịch nào được đóng gói vào khối, giao dịch nào bị loại trừ, hoặc điều chỉnh thứ tự giao dịch, giá trị tối đa có thể kiếm được từ những hoạt động này được gọi là "Giá trị có thể trích xuất tối đa", viết tắt là MEV. MEV tồn tại phổ biến trong hầu hết các blockchain và luôn là chủ đề được ngành công nghiệp quan tâm và thảo luận.
Nhiều nhà nghiên cứu khi quan sát hiện tượng MEV đã đặt ra một câu hỏi rõ ràng: Liệu công nghệ mã hóa có thể giải quyết vấn đề này không? Một trong những giải pháp là sử dụng bộ nhớ giao dịch mã hóa: Người dùng phát sóng giao dịch đã được mã hóa, và những giao dịch này chỉ được giải mã và công khai sau khi hoàn tất việc sắp xếp. Như vậy, giao thức đồng thuận sẽ phải "chọn mù" thứ tự giao dịch, điều này dường như có thể ngăn chặn việc lợi dụng cơ hội MEV trong giai đoạn sắp xếp.
Nhưng thật không may, cả về mặt ứng dụng thực tế và lý thuyết, bộ nhớ pool mã hóa không thể cung cấp giải pháp chung cho vấn đề MEV. Bài viết này sẽ trình bày những khó khăn trong đó và khám phá hướng thiết kế khả thi cho bộ nhớ pool mã hóa.
Cách hoạt động của bể nhớ tiền mã hóa
Về bộ nhớ crypto, đã có nhiều đề xuất, nhưng khung chung của nó như sau:
Người dùng phát sóng giao dịch đã được mã hóa.
Giao dịch mã hóa được gửi lên chuỗi (trong một số đề xuất, giao dịch cần phải trải qua quá trình xáo trộn ngẫu nhiên có thể xác minh trước).
Khi các khối chứa các giao dịch này được xác nhận cuối cùng, giao dịch sẽ được giải mã.
Cuối cùng thực hiện các giao dịch này.
Cần lưu ý rằng, bước 3 (Giải mã giao dịch) có một vấn đề quan trọng: Ai sẽ chịu trách nhiệm giải mã? Nếu giải mã không hoàn thành thì sao? Một ý tưởng đơn giản là để người dùng tự giải mã giao dịch của họ (trong trường hợp này thậm chí không cần mã hóa, chỉ cần ẩn cam kết là đủ). Nhưng cách này có lỗ hổng: Kẻ tấn công có thể thực hiện MEV đầu cơ.
Trong MEV đầu cơ, kẻ tấn công sẽ đoán rằng một giao dịch tiền điện tử nào đó chứa cơ hội MEV, sau đó mã hóa giao dịch của mình và cố gắng chèn nó vào vị trí thuận lợi (chẳng hạn như trước hoặc sau giao dịch mục tiêu). Nếu các giao dịch được sắp xếp theo thứ tự mong đợi, kẻ tấn công sẽ giải mã và thông qua giao dịch của mình để trích xuất MEV; nếu không đạt được mong đợi, họ sẽ từ chối giải mã và giao dịch của họ sẽ không được đưa vào chuỗi khối cuối cùng.
Có thể áp dụng hình phạt đối với người dùng không giải mã thành công, nhưng việc thực hiện cơ chế này rất khó khăn. Nguyên nhân là: tất cả hình phạt cho các giao dịch mã hóa phải đồng nhất (dù sao cũng không thể phân biệt giao dịch sau khi mã hóa), và hình phạt phải đủ nghiêm khắc, ngay cả khi đối mặt với mục tiêu có giá trị cao cũng có thể kiềm chế MEV đầu cơ. Điều này sẽ dẫn đến một lượng lớn vốn bị khóa lại, và những khoản tiền này cần phải giữ tính ẩn danh (để tránh tiết lộ mối liên hệ giữa giao dịch và người dùng). Thậm chí phức tạp hơn, nếu do lỗi chương trình hoặc sự cố mạng khiến người dùng thực không thể giải mã bình thường, họ cũng sẽ chịu tổn thất vì điều đó.
Do đó, hầu hết các giải pháp đề xuất khi mã hóa giao dịch, cần đảm bảo rằng chúng có thể được giải mã vào một thời điểm nào đó trong tương lai, ngay cả khi người dùng khởi tạo giao dịch ngoại tuyến hoặc từ chối hợp tác. Mục tiêu này có thể được đạt được thông qua một vài cách sau:
Môi trường thực thi đáng tin cậy (TEE): Người dùng có thể mã hóa giao dịch bằng khóa được lưu trữ trong khu vực bảo mật của môi trường thực thi đáng tin cậy (TEE). Trong một số phiên bản cơ bản, TEE chỉ được sử dụng để giải mã giao dịch sau một thời điểm nhất định (điều này yêu cầu TEE phải có khả năng cảm nhận thời gian bên trong). Các giải pháp phức tạp hơn cho phép TEE chịu trách nhiệm giải mã giao dịch và xây dựng khối, sắp xếp giao dịch dựa trên thời gian đến, phí và các tiêu chuẩn khác. So với các giải pháp bộ nhớ mã hóa khác, lợi thế của TEE là khả năng xử lý trực tiếp giao dịch ở dạng rõ, giảm thông tin dư thừa trên chuỗi bằng cách lọc các giao dịch có thể bị quay lại. Tuy nhiên, nhược điểm của phương pháp này là phụ thuộc vào độ tin cậy của phần cứng.
Chia sẻ bí mật và mã hóa ngưỡng (Secret-sharing and threshold encryption): Trong phương án này, người dùng mã hóa giao dịch bằng một khóa mà khóa này được một ủy ban cụ thể (thường là một tập hợp con của các xác thực viên) cùng nắm giữ. Việc giải mã cần phải đáp ứng một số điều kiện ngưỡng nhất định (ví dụ, hai phần ba thành viên trong ủy ban đồng ý).
Khi áp dụng giải mã ngưỡng, phương tiện tin cậy chuyển từ phần cứng sang ủy ban. Những người ủng hộ cho rằng, vì hầu hết các giao thức đã mặc định rằng các xác thực có tính "đa số trung thực" trong cơ chế đồng thuận, chúng ta cũng có thể đưa ra giả định tương tự, rằng đa số các xác thực sẽ giữ trung thực và không giải mã giao dịch trước.
Tuy nhiên, cần lưu ý một sự khác biệt quan trọng ở đây: Hai giả thuyết về niềm tin này không phải là cùng một khái niệm. Các thất bại đồng thuận như phân nhánh blockchain có tính công khai (thuộc về "giả thuyết niềm tin yếu"), trong khi các ủy ban ác ý giải mã giao dịch trước một cách riêng tư sẽ không để lại bất kỳ bằng chứng công khai nào, loại tấn công này không thể bị phát hiện và cũng không thể bị trừng phạt (thuộc về "giả thuyết niềm tin mạnh"). Do đó, mặc dù nhìn bề ngoài, cơ chế đồng thuận và giả thuyết an ninh của ủy ban mã hóa có vẻ nhất quán, nhưng trong thực tế, tính khả thi của giả thuyết "ủy ban sẽ không thông đồng" lại thấp hơn nhiều.
Khóa thời gian và mã hóa trì hoãn (Time-lock and delay encryption): Là một giải pháp thay thế cho mã hóa ngưỡng, nguyên lý của mã hóa trì hoãn là: Người dùng mã hóa giao dịch đến một khóa công khai nào đó, trong khi khóa riêng tương ứng với khóa công khai đó được ẩn trong một câu đố khóa thời gian. Câu đố khóa thời gian là một câu đố mật mã học bao bọc bí mật, nội dung bí mật cần được tiết lộ sau khoảng thời gian đã định trước, cụ thể hơn, quá trình giải mã cần thực hiện lặp lại một loạt các phép toán không thể thực hiện song song. Dưới cơ chế này, bất kỳ ai cũng có thể giải câu đố để lấy khóa và giải mã giao dịch, nhưng điều kiện là phải hoàn thành một đoạn tính toán chậm thiết kế đủ dài (về bản chất là thực hiện tuần tự) nhằm đảm bảo giao dịch không thể được giải mã trước khi xác nhận cuối cùng. Hình thức mạnh nhất của nguyên thủy mã hóa này là thông qua công nghệ mã hóa trì hoãn để công khai tạo ra các câu đố như vậy; cũng có thể thông qua ủy ban đáng tin cậy với sự trợ giúp của mã hóa khóa thời gian để gần như thực hiện quá trình này, mặc dù lúc này lợi thế tương đối so với mã hóa ngưỡng đã đáng để bàn cãi.
Dù là sử dụng mã hóa trễ hay thực hiện tính toán bởi một ủy ban đáng tin cậy, các giải pháp này đều phải đối mặt với nhiều thách thức thực tiễn: trước tiên, do tính chất của độ trễ phụ thuộc vào quá trình tính toán, rất khó để đảm bảo độ chính xác của thời gian giải mã; thứ hai, các giải pháp này cần phụ thuộc vào các thực thể cụ thể để vận hành phần cứng hiệu suất cao nhằm giải quyết các câu đố một cách hiệu quả, mặc dù bất kỳ ai cũng có thể đảm nhận vai trò này, nhưng cách nào để khuyến khích thực thể đó tham gia vẫn chưa rõ ràng; cuối cùng, trong thiết kế loại này, tất cả các giao dịch được phát sóng sẽ được giải mã, bao gồm cả những giao dịch chưa bao giờ được ghi vào khối cuối cùng. Trong khi đó, các giải pháp dựa trên ngưỡng (hoặc mã hóa chứng kiến) có thể chỉ giải mã những giao dịch đã được bao gồm thành công.
Mã hóa chứng kiến (Witness encryption): Giải pháp mật mã tiên tiến nhất cuối cùng là sử dụng công nghệ «mã hóa chứng kiến». Về lý thuyết, cơ chế của mã hóa chứng kiến là: sau khi thông tin được mã hóa, chỉ những người biết mối quan hệ NP cụ thể tương ứng với «thông tin chứng kiến» mới có thể giải mã nó. Ví dụ, thông tin có thể được mã hóa như: chỉ những người có thể giải một câu đố Sudoku nhất định, hoặc có thể cung cấp một hình ảnh băm giá trị nhất định mới có thể hoàn thành việc giải mã.
(Chú ý: Mối quan hệ NP là mối quan hệ giữa "vấn đề" và "câu trả lời có thể xác minh nhanh chóng")
Đối với bất kỳ mối quan hệ NP nào, có thể thực hiện logic tương tự thông qua SNARKs. Có thể nói, chứng minh mật mã về cơ bản là mã hóa dữ liệu theo cách mà chỉ những chủ thể có thể chứng minh thông qua SNARK rằng họ thỏa mãn các điều kiện cụ thể mới có thể giải mã. Trong kịch bản bộ nhớ mã hóa, một ví dụ điển hình về các điều kiện này là: giao dịch chỉ có thể được giải mã sau khi khối được xác nhận cuối cùng.
Đây là một loại nguyên ngữ lý thuyết có tiềm năng lớn. Thực tế, nó là một giải pháp tổng quát, dựa trên phương pháp ủy ban và phương pháp dựa trên độ trễ chỉ là những hình thức ứng dụng cụ thể của nó. Thật không may, hiện tại chúng ta vẫn chưa có bất kỳ giải pháp mã hóa dựa trên chứng nhận nào có thể thực hiện được. Hơn nữa, ngay cả khi có những giải pháp như vậy, cũng khó có thể nói rằng nó có ưu thế hơn phương pháp dựa trên ủy ban trong chuỗi bằng chứng cổ phần. Ngay cả khi thiết lập mã hóa chứng nhận là "chỉ khi giao dịch được sắp xếp trong khối đã được xác nhận cuối cùng mới có thể giải mã", ủy ban độc hại vẫn có thể lén lút mô phỏng giao thức đồng thuận để giả mạo trạng thái xác nhận cuối cùng của giao dịch, sau đó sử dụng chuỗi riêng này như một "chứng nhận" để giải mã giao dịch. Lúc này, việc cùng một ủy ban sử dụng giải mã ngưỡng cũng có thể đạt được mức độ an toàn tương đương, và thao tác còn đơn giản hơn nhiều.
Tuy nhiên, trong giao thức đồng thuận chứng minh công việc, lợi thế của việc chứng thực mã hóa trở nên rõ ràng hơn. Bởi vì ngay cả khi ủy ban hoàn toàn ác ý, họ cũng không thể khai thác nhiều khối mới một cách bí mật ở đầu chuỗi khối hiện tại để giả mạo trạng thái xác nhận cuối cùng.
Những thách thức kỹ thuật mà bể nhớ mã hóa phải đối mặt
Nhiều thách thức thực tế đang hạn chế khả năng của các pool nhớ crypto trong việc phòng ngừa MEV. Tổng thể, việc bảo mật thông tin bản thân đã là một vấn đề khó khăn. Đáng chú ý là, việc ứng dụng công nghệ mã hóa trong lĩnh vực Web3 không phổ biến, nhưng hàng thập kỷ thực hành triển khai công nghệ mã hóa trong các mạng (như TLS/HTTPS) và truyền thông riêng tư (từ PGP đến Signal, WhatsApp và các nền tảng nhắn tin mã hóa hiện đại khác) đã phơi bày đầy đủ những khó khăn của nó: mã hóa mặc dù là công cụ bảo vệ tính bảo mật, nhưng không thể đảm bảo tuyệt đối.
Đầu tiên, một số chủ thể có thể trực tiếp truy cập thông tin giao dịch của người dùng dưới dạng văn bản rõ. Trong tình huống điển hình, người dùng thường không tự mã hóa giao dịch mà giao công việc này cho nhà cung cấp dịch vụ ví. Như vậy, nhà cung cấp dịch vụ ví có thể tiếp cận văn bản giao dịch, thậm chí có thể sử dụng hoặc bán những thông tin này để thu được MEV. Độ an toàn của mã hóa luôn phụ thuộc vào tất cả các chủ thể có thể tiếp cận khóa. Phạm vi kiểm soát khóa chính là ranh giới của sự an toàn.
Ngoài ra, vấn đề lớn nhất nằm ở siêu dữ liệu, tức là dữ liệu chưa mã hóa xung quanh tải trọng mã hóa (giao dịch). Các nhà tìm kiếm có thể lợi dụng những siêu dữ liệu này để suy đoán ý định giao dịch, từ đó thực hiện MEV đầu cơ. Cần biết rằng, các nhà tìm kiếm không cần phải hiểu toàn bộ nội dung giao dịch, cũng không nhất thiết phải đoán đúng mỗi lần. Ví dụ, chỉ cần họ có thể xác định với xác suất hợp lý rằng một giao dịch nào đó đến từ một lệnh mua của sàn giao dịch phi tập trung (DEX) cụ thể, là đủ để phát động tấn công.
Chúng ta có thể phân loại siêu dữ liệu thành vài loại: một loại là các vấn đề cổ điển vốn có của công nghệ mã hóa, loại còn lại là các vấn đề đặc thù của bộ nhớ mã hóa.
Kích thước giao dịch: Chính bản thân mã hóa không thể ẩn kích thước của bản rõ (đáng lưu ý rằng, trong định nghĩa chính thức về an toàn ngữ nghĩa, việc ẩn kích thước bản rõ bị loại trừ). Đây là một vectơ tấn công phổ biến trong giao tiếp mã hóa, ví dụ điển hình là, ngay cả khi đã được mã hóa, kẻ nghe lén vẫn có thể xác định nội dung đang phát trên Netflix theo kích thước của từng gói dữ liệu trong luồng video theo thời gian thực. Trong bộ nhớ mã hóa, các loại giao dịch cụ thể có thể có kích thước độc đáo, từ đó rò rỉ thông tin.
Thời gian phát sóng: Mã hóa cũng không thể che giấu thông tin thời gian (đây là một vector tấn công cổ điển khác). Trong bối cảnh Web3, một số người gửi (như trong các tình huống bán tháo có cấu trúc) có thể khởi tạo giao dịch theo khoảng thời gian cố định. Thời gian giao dịch cũng có thể liên quan đến các thông tin khác, chẳng hạn như hoạt động của các sàn giao dịch bên ngoài hoặc các sự kiện tin tức. Một cách sử dụng thông tin thời gian tinh vi hơn là chênh lệch giá giữa sàn giao dịch tập trung (CEX) và sàn giao dịch phi tập trung (DEX): Người sắp xếp có thể lợi dụng thông tin giá CEX mới nhất bằng cách chèn các giao dịch được tạo ra muộn nhất có thể; đồng thời, người sắp xếp có thể loại trừ tất cả các giao dịch khác được phát sóng sau một thời điểm nhất định (dù có mã hóa), đảm bảo giao dịch của mình độc quyền lợi thế về giá mới nhất.
Địa chỉ IP nguồn: Người tìm kiếm có thể suy luận danh tính người gửi giao dịch bằng cách theo dõi mạng ngang hàng và lần theo địa chỉ IP nguồn. Vấn đề này đã được phát hiện từ những ngày đầu của Bitcoin (đến nay đã hơn mười năm). Nếu người gửi cụ thể có một mô hình hành vi cố định, điều này có giá trị rất lớn đối với người tìm kiếm. Ví dụ, khi biết danh tính người gửi, có thể liên kết giao dịch tiền mã hóa với các giao dịch lịch sử đã được giải mã.
Thông tin người gửi giao dịch và phí / gas: Phí giao dịch là một loại siêu dữ liệu đặc trưng cho bộ nhớ tiền điện tử. Trong Ethereum, giao dịch truyền thống bao gồm địa chỉ người gửi trên chuỗi (để thanh toán phí), ngân sách gas tối đa và phí gas mà người gửi sẵn sàng trả. Tương tự như địa chỉ mạng nguồn, địa chỉ người gửi có thể được sử dụng để liên kết nhiều giao dịch và thực thể thực tế; ngân sách gas có thể ám chỉ ý định giao dịch. Ví dụ, việc tương tác với một DEX cụ thể có thể yêu cầu một lượng gas cố định có thể nhận dạng.
Những người tìm kiếm phức tạp có thể kết hợp nhiều loại siêu dữ liệu như đã nêu ở trên để dự đoán nội dung giao dịch.
Về lý thuyết, tất cả những thông tin này đều có thể được ẩn đi, nhưng phải trả giá bằng hiệu suất và độ phức tạp. Ví dụ, việc làm đầy giao dịch đến độ dài tiêu chuẩn có thể ẩn kích thước, nhưng sẽ lãng phí băng thông và không gian trên chuỗi; tăng độ trễ trước khi gửi có thể ẩn thời gian, nhưng sẽ làm tăng độ trễ; nộp giao dịch qua mạng ẩn danh như Tor có thể ẩn địa chỉ IP, nhưng điều này lại mang đến những thách thức mới.
Dữ liệu metadata khó ẩn nhất là thông tin phí giao dịch. Dữ liệu phí mã hóa gây ra một loạt vấn đề cho các nhà xây dựng khối: đầu tiên là vấn đề thông tin rác, nếu dữ liệu phí giao dịch được mã hóa, bất kỳ ai cũng có thể phát sóng giao dịch mã hóa có định dạng sai, những giao dịch này sẽ được sắp xếp nhưng không thể thanh toán phí, và khi giải mã sẽ không thể thực hiện nhưng không ai có thể bị truy cứu trách nhiệm. Điều này có thể được giải quyết thông qua SNARKs, tức là chứng minh định dạng giao dịch là đúng và có đủ tiền, nhưng sẽ làm tăng đáng kể chi phí.
Thứ hai là vấn đề hiệu quả trong việc xây dựng khối và đấu giá phí. Người xây dựng dựa vào thông tin phí để tạo ra khối tối đa hóa lợi nhuận và xác định giá thị trường hiện tại của tài nguyên trên chuỗi. Dữ liệu phí mã hóa có thể phá vỡ quá trình này. Một giải pháp là đặt phí cố định cho mỗi khối, nhưng điều này về mặt kinh tế là kém hiệu quả và có thể gây ra một thị trường thứ cấp cho việc đóng gói giao dịch, trái với mục đích thiết kế của bộ nhớ mã hóa. Một giải pháp khác là đấu giá phí thông qua tính toán đa bên an toàn hoặc phần cứng đáng tin cậy, nhưng cả hai phương pháp này đều có chi phí rất cao.
Cuối cùng, một bể nhớ mã hóa an toàn sẽ làm tăng chi phí hệ thống từ nhiều khía cạnh: mã hóa sẽ làm tăng độ trễ của chuỗi, khối lượng tính toán và tiêu thụ băng thông; cách kết hợp với các mục tiêu quan trọng trong tương lai như phân mảnh hoặc thực thi song song vẫn chưa rõ ràng; cũng có thể đưa ra các điểm lỗi mới cho tính khả dụng (liveness) (như ủy ban giải mã trong các kế hoạch ngưỡng, bộ giải hàm độ trễ); đồng thời, độ phức tạp thiết kế và thực hiện cũng sẽ tăng đáng kể.
Nhiều vấn đề của bể nhớ crypto có liên quan đến những thách thức mà blockchain nhằm bảo vệ quyền riêng tư giao dịch (như Zcash, Monero) đang phải đối mặt. Nếu có điều gì tích cực, thì đó là: Giải quyết tất cả các thách thức của công nghệ mã hóa trong việc giảm thiểu MEV sẽ đồng thời dọn đường cho quyền riêng tư giao dịch.
Những thách thức kinh tế mà bể nhớ mã hóa phải đối mặt
Cuối cùng, các bể nhớ mã hóa còn phải đối mặt với những thách thức về mặt kinh tế. Khác với những thách thức về công nghệ, những thách thức này có thể được giảm bớt dần dần thông qua việc đầu tư kỹ thuật đủ. Những thách thức kinh tế này thuộc về những hạn chế cơ bản, rất khó để giải quyết.
Vấn đề cốt lõi của MEV xuất phát từ sự bất đối xứng thông tin giữa người tạo giao dịch (người dùng) và những người khai thác cơ hội MEV (người tìm kiếm và người xây dựng khối). Người dùng thường không nhận thức được giá trị có thể khai thác trong giao dịch của họ, vì vậy ngay cả khi có một bộ nhớ mã hóa hoàn hảo, họ vẫn có thể bị dụ dỗ tiết lộ khóa giải mã để đổi lấy một phần thưởng thấp hơn giá trị thực tế của MEV, hiện tượng này được gọi là "giải mã có động lực".
Cảnh tượng này không khó để tưởng tượng, vì cơ chế tương tự như MEV Share đã tồn tại trong thực tế. MEV Share là một cơ chế đấu giá luồng đơn hàng, cho phép người dùng chọn lọc gửi thông tin giao dịch vào một bể, và các tìm kiếm cạnh tranh để có quyền khai thác cơ hội MEV từ giao dịch đó. Người thắng thầu sau khi khai thác MEV sẽ hoàn trả một phần lợi nhuận (tức là số tiền thầu hoặc tỷ lệ nhất định của nó) cho người dùng.
Mô hình này có thể thích ứng trực tiếp với bể nhớ mã hóa: Người dùng cần tiết lộ khóa giải mã (hoặc một phần thông tin) để tham gia. Nhưng hầu hết người dùng không nhận ra chi phí cơ hội của việc tham gia vào cơ chế này, họ chỉ thấy lợi ích trước mắt và sẵn lòng tiết lộ thông tin. Trong tài chính truyền thống cũng có những trường hợp tương tự: chẳng hạn như nền tảng giao dịch không hoa hồng Robinhood, mô hình lợi nhuận của nó chính là thông qua "thanh toán cho dòng lệnh" (payment-for-order-flow) bán dòng lệnh người dùng cho bên thứ ba.
Một kịch bản khả thi khác là: các nhà xây dựng lớn, với lý do kiểm duyệt, buộc người dùng phải tiết lộ nội dung giao dịch (hoặc thông tin liên quan). Khả năng chống kiểm duyệt là một chủ đề quan trọng và gây tranh cãi trong lĩnh vực Web3, nhưng nếu các xác thực viên lớn hoặc các nhà xây dựng bị ràng buộc bởi pháp luật (như quy định của Văn phòng Kiểm soát Tài sản Nước ngoài Hoa Kỳ - OFAC) phải thực hiện danh sách kiểm tra kiểm duyệt, họ có thể từ chối xử lý bất kỳ giao dịch tiền điện tử nào. Về mặt kỹ thuật, người dùng có thể chứng minh giao dịch tiền điện tử của họ tuân thủ yêu cầu kiểm duyệt thông qua bằng chứng không kiến thức, nhưng điều này sẽ làm tăng chi phí và độ phức tạp. Ngay cả khi blockchain có khả năng chống kiểm duyệt mạnh (đảm bảo rằng giao dịch tiền điện tử nhất định sẽ được ghi nhận), các nhà xây dựng vẫn có thể ưu tiên đưa các giao dịch có văn bản rõ ràng đã biết lên đầu khối, trong khi các giao dịch mã hóa bị xếp ở cuối. Do đó, những người cần đảm bảo ưu tiên thực hiện giao dịch cuối cùng có thể vẫn bị buộc phải tiết lộ nội dung cho các nhà xây dựng.
Các thách thức khác về hiệu quả
Bể nhớ mã hóa sẽ làm tăng chi phí hệ thống theo nhiều cách rõ ràng. Người dùng cần mã hóa giao dịch, hệ thống cũng cần giải mã theo một cách nào đó, điều này sẽ làm tăng chi phí tính toán và có thể làm tăng kích thước giao dịch. Như đã đề cập trước đó, việc xử lý siêu dữ liệu sẽ làm trầm trọng thêm những chi phí này. Tuy nhiên, còn một số chi phí hiệu quả không rõ ràng như vậy. Trong lĩnh vực tài chính, nếu giá cả có thể phản ánh tất cả thông tin có sẵn, thị trường được coi là hiệu quả; trong khi đó, độ trễ và thông tin không đối xứng sẽ dẫn đến sự kém hiệu quả của thị trường. Đây chính là kết quả tất yếu của bể nhớ mã hóa.
Sự kém hiệu quả này sẽ dẫn đến một hậu quả trực tiếp: tăng độ không chắc chắn về giá, đây là sản phẩm trực tiếp của việc tăng độ trễ trong các bể nhớ tiền mã hóa. Do đó, số lượng giao dịch thất bại do vượt quá mức độ chấp nhận trượt giá có thể gia tăng, từ đó lãng phí không gian trên chuỗi.
Tương tự, sự không chắc chắn về giá cả này cũng có thể tạo ra các giao dịch MEV đầu cơ, loại giao dịch này cố gắng kiếm lợi từ việc chênh lệch giá trên chuỗi. Cần lưu ý rằng, bộ nhớ trong của tiền điện tử có thể làm cho các cơ hội này trở nên phổ biến hơn: do độ trễ trong việc thực hiện, trạng thái hiện tại của sàn giao dịch phi tập trung (DEX) trở nên mơ hồ hơn, điều này rất có thể dẫn đến sự giảm hiệu quả của thị trường và xuất hiện sự chênh lệch giá giữa các nền tảng giao dịch khác nhau. Các giao dịch MEV đầu cơ như vậy cũng sẽ lãng phí không gian khối, vì một khi không phát hiện được cơ hội chênh lệch giá, chúng thường sẽ dừng thực hiện.
Tóm tắt
Bài viết này nhằm mục đích tổng hợp những thách thức mà các bể nhớ tiền điện tử đang đối mặt, để mọi người có thể chuyển sự chú ý sang việc phát triển các giải pháp khác, nhưng bể nhớ tiền điện tử vẫn có thể trở thành một phần của các giải pháp quản trị MEV.
Một hướng đi khả thi là thiết kế hỗn hợp: một phần giao dịch được thực hiện thông qua bể nhớ mã hóa để đạt được "sắp xếp mù", phần còn lại sử dụng các phương án sắp xếp khác. Đối với các loại giao dịch cụ thể (ví dụ như lệnh mua bán của các nhà đầu tư lớn, những người có khả năng mã hóa hoặc làm đầy giao dịch một cách cẩn thận và sẵn sàng trả chi phí cao hơn để tránh MEV), thiết kế hỗn hợp có thể là lựa chọn phù hợp. Đối với các giao dịch nhạy cảm cao (như giao dịch sửa lỗi các hợp đồng an toàn có lỗ hổng), thiết kế này cũng có ý nghĩa thực tiễn.
Tuy nhiên, do các hạn chế về công nghệ, độ phức tạp cao của các kỹ thuật và chi phí hiệu suất, bộ nhớ mã hóa khó có khả năng trở thành "giải pháp toàn diện cho MEV" như người ta mong đợi. Cộng đồng cần phát triển các giải pháp khác, bao gồm đấu giá MEV, cơ chế phòng thủ ứng dụng và rút ngắn thời gian xác nhận cuối cùng. MEV vẫn sẽ là một thách thức trong một khoảng thời gian tới, cần tìm ra điểm cân bằng giữa các giải pháp thông qua nghiên cứu sâu sắc nhằm đối phó với những tác động tiêu cực của nó.