a16z: Tại sao mempool mã hóa khó trở thành giải pháp vạn năng cho MEV?
Tuyển chọn TechFlowTuyển chọn TechFlow
a16z: Tại sao mempool mã hóa khó trở thành giải pháp vạn năng cho MEV?
Công nghệ, kinh tế, hiệu suất: Ba ngọn núi lớn không thể tránh khỏi.
Chuyên sâu báo cáo Web3Tác giả: Pranav Garimidi, Joseph Bonneau, Lioba Heimbach, a16z
Dịch: Saoirse, Foresight News
Trong blockchain, giá trị tối đa có thể khai thác (MEV) là lượng giá trị lớn nhất mà các thợ đào hoặc trình xác thực có thể kiếm được bằng cách quyết định giao dịch nào được đưa vào khối, giao dịch nào bị loại bỏ, hoặc điều chỉnh thứ tự sắp xếp giao dịch. MEV phổ biến trong hầu hết các blockchain và là chủ đề được quan tâm và thảo luận rộng rãi trong ngành.
Lưu ý: Bài viết này giả định người đọc đã có hiểu biết cơ bản về MEV. Một số độc giả có thể muốn đọc trước bài giải thích MEV của chúng tôi.
Nhiều nhà nghiên cứu khi quan sát hiện tượng MEV đều đặt ra một câu hỏi rõ ràng: Liệu mật mã học có thể giải quyết vấn đề này? Một phương án được đề xuất là sử dụng mempool mã hóa: người dùng phát đi các giao dịch đã mã hóa, chỉ được giải mã 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, dường như ngăn chặn khả năng tận dụng MEV trong giai đoạn sắp xếp.
Tuy nhiên, đáng tiếc là cả trên lý thuyết lẫn thực tế, mempool mã hóa đều không thể cung cấp giải pháp tổng quát cho vấn đề MEV. Bài viết này sẽ trình bày những khó khăn và thảo luận hướng thiết kế khả thi cho mempool mã hóa.
Cơ chế hoạt động của mempool mã hóa
Đã có nhiều đề xuất về mempool mã hóa, nhưng khung tổng quát thường bao gồm:
-
Người dùng phát đi các giao dịch đã mã hóa.
-
Các giao dịch mã hóa được gửi lên chuỗi (trong một số đề xuất, giao dịch cần trải qua quá trình xáo trộn ngẫu nhiên có thể kiểm chứng).
-
Khi khối chứa các giao dịch này được xác nhận cuối cùng, các giao dịch sẽ được giải mã.
-
Cuối cùng, các giao dịch được thực thi.
Lưu ý rằng bước 3 (giải mã giao dịch) đặt ra một vấn đề then chốt: Ai chịu trách nhiệm giải mã? Nếu việc giải mã thất bại thì sao? Một cách đơn giản là để người dùng tự giải mã giao dịch của mình (trong trường hợp này thậm chí không cần mã hóa, chỉ cần ẩn cam kết). Tuy nhiên, cách này có lỗ hổng: kẻ tấn công có thể thực hiện MEV mang tính đầu cơ.
Trong MEV đầu cơ, kẻ tấn công đoán rằng một giao dịch mã hóa tiềm ẩn cơ hội MEV, sau đó mã hóa giao dịch của mình và cố gắng chèn vào vị trí có lợi (ví dụ trước hoặc sau giao dịch mục tiêu). Nếu giao dịch được sắp xếp đúng theo mong đợi, kẻ tấn công sẽ giải mã và rút MEV thông qua giao dịch của mình; nếu không đạt kỳ vọng, họ từ chối giải mã, và giao dịch của họ sẽ không được đưa vào blockchain cuối cùng.
Có thể áp dụng hình phạt với người dùng giải mã thất bại, nhưng việc triển khai cơ chế này cực kỳ khó. Bởi vì: mức phạt phải giống nhau với mọi giao dịch mã hóa (do không thể phân biệt sau khi mã hóa), và phải đủ nghiêm khắc để ngăn chặn MEV đầu cơ ngay cả với mục tiêu giá trị cao. Điều này dẫn đến lượng lớn vốn bị khóa, vốn này phải duy trì ẩn danh (để tránh tiết lộ mối liên hệ giữa giao dịch và người dùng). Khó khăn hơn nữa là nếu người dùng thật sự không thể giải mã do lỗi phần mềm hoặc sự cố mạng, họ cũng sẽ chịu tổn thất.
Do đó, hầu hết các phương án đề xuất rằng khi mã hóa giao dịch, cần đảm bảo rằng giao dịch chắc chắn có thể được giải mã tại một thời điểm trong tương lai, ngay cả khi người gửi ngoại tuyến hoặc từ chối hợp tác. Mục tiêu này có thể đạt được bằng một số cách sau:
Môi trường thực thi đáng tin cậy (TEEs): Người dùng có thể mã hóa giao dịch tới khóa do khu vực an toàn của môi trường thực thi đáng tin cậy (TEE) nắm giữ. Trong phiên bản cơ bản, TEE chỉ dùng để giải mã giao dịch sau một thời điểm cụ thể (yêu cầu TEE có khả năng cảm nhận thời gian). Các phương án phức tạp hơn để TEE phụ trách 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.v. So với các phương án mempool mã hóa khác, ưu điểm của TEE là xử lý trực tiếp giao dịch dạng rõ, giảm dữ liệu dư thừa trên chuỗi bằng cách lọc các giao dịch sẽ rollback. Nhưng nhược điểm là phụ thuộc vào độ tin cậy 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 tới một khóa do một ủy ban cụ thể (thường là tập con các trình xác thực) cùng nắm giữ. Việc giải mã yêu cầu thỏa mãn điều kiện ngưỡng (ví dụ, ít nhất hai phần ba thành viên ủy ban đồng ý).
Khi dùng giải mã ngưỡng, đối tượng tin cậy chuyển từ phần cứng sang ủy ban. Người ủng hộ lập luận rằng vì hầu hết các giao thức mặc định đặc tính "đa số trung thực" của trình xác thực trong cơ chế đồng thuận, ta cũng có thể giả định tương tự rằng đa số sẽ trung thực và không giải mã sớm.
Tuy nhiên, cần lưu ý một khác biệt then chốt: Hai giả định tin cậy này không giống nhau. Sự thất bại đồng thuận như fork blockchain có thể quan sát công khai (thuộc "giả định tin cậy yếu"), trong khi ủy ban ác ý âm thầm giải mã sớm không để lại bằng chứng công khai, cuộc tấn công này vừa không thể phát hiện, vừa không thể trừng phạt (thuộc "giả định tin cậy mạnh"). Do đó, dù bề ngoài có vẻ giả định an toàn của cơ chế đồng thuận và ủy ban mã hóa là như nhau, trong thực tế, giả định "ủy ban không cấu kết" đáng tin cậy thấp hơn nhiều.
Khóa thời gian và mã hóa trì hoãn (Time-lock and delay encryption): Là phương án thay thế cho mã hóa ngưỡng, nguyên lý mã hóa trì hoãn là: người dùng mã hóa giao dịch tới một khóa công khai, trong khi khóa riêng tương ứng bị ẩ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 đóng gói bí mật, chỉ có thể tiết lộ sau thời gian đã định—cụ thể hơn, quá trình giải mã yêu cầu thực hiện hàng loạt phép toán không thể song song hóa. Trong 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 phải hoàn thành một chuỗi phép toán chậm (về cơ bản là tuần tự) với thời gian tính toán được thiết kế đủ dài để đảm bảo giao dịch không thể giải mã trước khi xác nhận cuối cùng. Dạng mạnh nhất của nguyên thủy mã hóa này là tạo câu đố công khai bằng kỹ thuật mã hóa trì hoãn; cũng có thể gần似 thực hiện bằng ủy ban đáng tin cậy dùng mã hóa khóa thời gian, tuy nhiên lúc này lợi thế so với mã hóa ngưỡng đã trở nên đáng nghi ngờ.
Dù dùng mã hóa trì hoãn hay ủy ban đáng tin cậy thực hiện tính toán, các phương án này đều đối mặt nhiều thách thức thực tế: thứ nhất, do trì hoãn phụ thuộc vào quá trình tính toán, khó đảm bảo độ chính xác về thời gian giải mã; thứ hai, các phương án này phụ thuộc vào thực thể cụ thể chạy phần cứng hiệu suất cao để giải câu đố hiệu quả, mặc dù bất kỳ ai cũng có thể đảm nhận vai trò này, nhưng động lực để tham gia vẫn chưa rõ ràng; cuối cùng, trong thiết kế này, mọi giao dịch phát đi đều bị giải mã, kể cả những giao dịch chưa từng được ghi vào khối cuối cùng. Trong khi các phương án dựa trên ngưỡng (hoặc mã hóa bằng bằng chứng) có khả năng chỉ giải mã những giao dịch được đưa vào thành công.
Mã hóa bằng bằng chứng (Witness encryption): Phương án mật mã học tiên tiến nhất là dùng kỹ thuật "mã hóa bằng bằng chứng". Về lý thuyết, cơ chế mã hóa bằng bằng chứng là: mã hóa thông tin sao cho chỉ những người biết "bằng chứng" tương ứng với một quan hệ NP cụ thể mới có thể giải mã. Ví dụ, mã hóa thông tin sao cho chỉ người giải được câu đố Sudoku hoặc cung cấp ảnh gốc của một giá trị băm mới có thể giải mã.
(Ghi chú: Quan hệ NP là mối tương ứng giữa "câu hỏi" và "câu trả lời có thể xác minh nhanh")
Với mọi quan hệ NP, có thể thực hiện logic tương tự thông qua SNARKs. Có thể nói, mã hóa bằng bằng chứng về cơ bản là mã hóa dữ liệu sao cho chỉ chủ thể có thể chứng minh qua SNARK rằng thỏa mãn điều kiện cụ thể mới có thể giải mã. Trong bối cảnh mempool mã hóa, một ví dụ điển hình là: giao dịch chỉ có thể giải mã sau khi khối được xác nhận cuối cùng.
Đây là một nguyên thủy lý thuyết đầy tiềm năng. Thực tế, nó là một giải pháp tổng quát, trong đó các phương pháp dựa trên ủy ban và trì hoãn chỉ là các hình thức ứng dụng cụ thể. Đáng tiếc, hiện tại chúng ta chưa có phương án mã hóa bằng bằng chứng nào có thể triển khai thực tế. Hơn nữa, ngay cả khi tồn tại, cũng khó nói rằng nó có lợi thế hơn phương pháp dựa trên ủy ban trong chuỗi proof-of-stake. Ngay cả khi thiết lập mã hóa bằng bằng chứng là "chỉ giải mã khi giao dịch đã được sắp xếp trong khối xác nhận cuối cùng", ủy ban ác ý vẫn có thể mô phỏng riêng giao thức đồng thuận để giả mạo trạng thái xác nhận cuối cùng, rồi dùng chuỗi riêng tư này làm "bằng chứng" để giải mã giao dịch. Lúc này, dùng giải mã ngưỡng bởi cùng ủy ban vừa đạt được mức an toàn tương đương, vừa đơn giản hơn nhiều về thao tác.
Tuy nhiên, trong giao thức đồng thuận proof-of-work, lợi thế của mã hóa bằng bằng chứng rõ rệt hơn. Vì ngay cả khi ủy ban hoàn toàn ác ý, họ cũng không thể đào riêng nhiều khối mới tại đỉnh blockchain hiện tại để giả mạo trạng thái xác nhận cuối cùng.
Thách thức kỹ thuật đối với mempool mã hóa
Nhiều thách thức thực tế hạn chế khả năng của mempool mã hóa trong việc ngăn chặn MEV. Tổng thể, việc bảo mật thông tin bản thân đã là một khó khăn. Cần lưu ý rằng mật mã học không được sử dụng rộng rãi trong Web3, nhưng hàng thập kỷ thực hành triển khai mật mã trong mạng (như TLS/HTTPS) và truyền thông riêng tư (từ PGP đến các nền tảng tin nhắn hiện đại như Signal, WhatsApp) đã phơi bày rõ những điểm khó: mật mã là công cụ bảo vệ tính bí mật, nhưng không thể đảm bảo tuyệt đối.
Thứ nhất, một số chủ thể có thể trực tiếp thu được nội dung rõ của giao dịch người dùng. Trong kịch bản điển hình, người dùng thường không tự mã hóa giao dịch, mà ủy quyền việc này cho nhà cung cấp ví. Khi đó, nhà cung cấp ví có thể tiếp cận nội dung rõ của giao dịch, thậm chí có thể tận dụng hoặc bán thông tin này để khai thác MEV. Độ an toàn của mã hóa luôn phụ thuộc vào mọi 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 an toàn.
Bên cạnh đó, vấn đề lớn nhất nằm ở siêu dữ liệu – dữ liệu chưa mã hóa xung quanh tải trọng đã mã hóa (giao dịch). Những người tìm kiếm có thể sử dụng siêu dữ liệu để suy đoán ý định giao dịch, từ đó thực hiện MEV đầu cơ. Cần biết rằng, người tìm kiếm không cần hiểu hoàn toàn nội dung giao dịch, cũng không cần luôn đoán đúng. Ví dụ, chỉ cần họ có thể phán đoán với xác suất hợp lý rằng một giao dịch là lệnh mua từ một sàn giao dịch phi tập trung (DEX) cụ thể, điều đó đã đủ để phát động tấn công.
Chúng ta có thể chia siêu dữ liệu thành vài loại: một loại là những bài toán cổ điển vốn có của mật mã học, loại còn lại là vấn đề đặc thù của mempool mã hóa.
-
Kích thước giao dịch: Bản thân mã hóa không thể che giấu kích thước văn bản rõ (lưu ý rằng định nghĩa chính thức về an toàn ngữ nghĩa rõ ràng loại trừ việc ẩn kích thước văn bản rõ). Đây là vector tấn công phổ biến trong truyền thông mã hóa, ví dụ điển hình là ngay cả khi đã mã hóa, kẻ nghe lén vẫn có thể xác định nội dung đang phát trên Netflix dựa trên kích thước từng gói dữ liệu trong luồng video. Trong mempool mã hóa, các loại giao dịch cụ thể có thể có kích thước đặc trưng, từ đó rò rỉ thông tin.
-
Thời gian phát đi: Mã hóa cũng không thể che giấu thông tin thời gian (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 trường hợp bán tháo có cấu trúc) có thể gửi 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, ví dụ như hoạt động trên sàn giao dịch bên ngoài hoặc sự kiện tin tức. 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ể chèn giao dịch được tạo càng muộn càng tốt để tận dụng thông tin giá CEX mới nhất; đồng thời, người sắp xếp có thể loại bỏ mọi giao dịch khác được phát đi sau một thời điểm nhất định (dù đã mã hóa), đảm bảo giao dịch của họ độc hưởng lợi thế về giá mới nhất.
-
Địa chỉ IP nguồn: Người tìm kiếm có thể suy đoán danh tính người gửi giao dịch bằng cách giám sát mạng ngang hàng và theo dõi địa chỉ IP nguồn. Vấn đề này đã được phát hiện từ những ngày đầu của Bitcoin (hơn mười năm trước). Nếu một người gửi cụ thể có mẫu hành vi cố định, điều này rất có giá trị với người tìm kiếm. Ví dụ, sau khi biết danh tính người gửi, có thể liên kết giao dịch mã hóa với các giao dịch lịch sử đã giải mã.
-
Người gửi giao dịch và thông tin phí/gas: Phí giao dịch là một loại siêu dữ liệu đặc thù của mempool mã hóa. Trên Ethereum, giao dịch truyền thống bao gồm địa chỉ người gửi trên chuỗi (dùng để thanh toán phí), ngân sách gas tối đa và mức phí gas đơn vị 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ể dùng để liên kết nhiều giao dịch với thực thể thực tế; ngân sách gas có thể ám chỉ ý định giao dịch. Ví dụ, tương tác với một DEX cụ thể có thể yêu cầu lượng gas cố định có thể nhận diện.
Những người tìm kiếm tinh vi có thể kết hợp nhiều loại siêu dữ liệu trên để dự đoán nội dung giao dịch.
Lý thuyết mà nói, mọi thông tin này đều có thể ẩn giấu, nhưng phải đánh đổi bằng hiệu suất và độ phức tạp. Ví dụ, thêm dữ liệu thặng dư để đưa giao dịch về độ dài 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; thêm độ trễ trước khi gửi có thể ẩn thời gian, nhưng sẽ làm tăng độ trễ; gửi giao dịch qua mạng ẩn danh như Tor có thể ẩn địa chỉ IP, nhưng lại tạo ra thách thức mới.
Siêu dữ liệu khó ẩn nhất là thông tin phí giao dịch. Mã hóa dữ liệu phí sẽ gây ra hàng loạt vấn đề cho người xây dựng khối: thứ nhất là vấn đề spam, nếu dữ liệu phí bị mã hóa, bất kỳ ai cũng có thể phát đi giao dịch mã hóa sai định dạng, những giao dịch này dù được sắp xếp nhưng không thể thanh toán phí, sau khi giải mã không thể thực thi mà không ai bị truy cứu trách nhiệm. Điều này có thể giải quyết bằng SNARKs, tức là chứng minh giao dịch đúng định dạng và đủ tiền, nhưng sẽ làm tăng chi phí đáng kể.
Thứ hai là hiệu quả xây dựng khối và đấu giá phí. Người xây dựng phụ thuộc vào thông tin phí để tạo 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. Việc mã hóa dữ liệu phí sẽ phá vỡ quá trình này. Một giải pháp là đặt mức phí cố định cho mỗi khối, nhưng điều này kém hiệu quả về kinh tế và có thể khiến thị trường cấp hai cho việc đóng gói giao dịch xuất hiện, trái với mục đích thiết kế của mempool mã hóa. Giải pháp khác là dùng tính toán đa bên an toàn hoặc phần cứng đáng tin cậy để đấu giá phí, nhưng cả hai cách này đều tốn kém cực cao.
Cuối cùng, một mempool mã hóa an toàn sẽ làm tăng chi phí hệ thống trên nhiều mặt: mã hóa làm tăng độ trễ, khối lượng tính toán và tiêu thụ băng thông của chuỗi; cách kết hợp với các mục tiêu tương lai quan trọng như phân mảnh hoặc thực thi song song vẫn chưa rõ ràng; đồng thời có thể tạo điểm lỗi mới cho tính sẵn sàng (liveness) (như ủy ban giải mã trong phương án ngưỡng, bộ giải hàm trì hoãn); độ phức tạp thiết kế và triển khai cũng tăng đáng kể.
Nhiều vấn đề của mempool mã hóa tương đồng với thách thức mà các blockchain nhằm bảo vệ quyền riêng tư giao dịch (như Zcash, Monero) đang đối mặt. Nếu có điểm tích cực, thì đó là: giải quyết mọi thách thức của mật mã học trong giảm thiểu MEV sẽ đồng thời dọn sạch trở ngại cho quyền riêng tư giao dịch.
Thách thức kinh tế đối với mempool mã hóa
Cuối cùng, mempool mã hóa còn đối mặt thách thức về kinh tế. Khác với thách thức kỹ thuật, cái này có thể từng bước giảm nhẹ bằng đủ nỗ lực kỹ thuật. Những thách thức kinh tế này là giới hạn căn bản, cực kỳ khó giải quyết.
Vấn đề cốt lõi của MEV bắt nguồn từ sự bất cân xứng thông tin giữa người tạo giao dịch (người dùng) và 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 biết rõ giao dịch của mình tiềm ẩn bao nhiêu giá trị có thể khai thác, do đó ngay cả với mempool 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 khoản thù lao thấp hơn giá trị MEV thực tế, hiện tượng này có thể gọi là "giải mã theo động lực".
Kịch bản 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á dòng lệnh, cho phép người dùng chọn lọc gửi thông tin giao dịch vào một nhóm, người tìm kiếm cạnh tranh để giành quyền tận dụng cơ hội MEV từ giao dịch đó. Người thắng thầu sau khi rút MEV sẽ hoàn lại một phần lợi nhuận (tức giá thầu hoặc tỷ lệ nhất định) cho người dùng.
Mô hình này có thể áp dụng trực tiếp cho mempool mã hóa: người dùng phải tiết lộ khóa giải mã (hoặc một phần thông tin) để tham gia. Nhưng đa số người dùng không nhận ra chi phí cơ hội khi tham gia cơ chế này, họ chỉ thấy phần thưởng trước mắt và sẵn sàng tiết lộ thông tin. Trong tài chính truyền thống cũng có ví dụ tương tự: ví dụ nền tảng giao dịch không hoa hồng Robinhood, mô hình sinh lời của họ chính là bán dòng lệnh người dùng cho bên thứ ba thông qua "thanh toán cho dòng lệnh" (payment-for-order-flow).
Một kịch bản khả dĩ khác là: các nhà xây dựng lớn ép người dùng tiết lộ nội dung giao dịch (hoặc thông tin liên quan) dưới danh nghĩa kiểm duyệt. Tính chống kiểm duyệt là chủ đề quan trọng và gây tranh cãi trong lĩnh vực Web3, nhưng nếu các trình xác thực hoặc nhà xây dựng lớn bị ràng buộc pháp lý (như quy định của OFAC Hoa Kỳ) phải thực hiện danh sách kiểm duyệt, họ có thể từ chối xử lý mọi giao dịch mã hóa. Về mặt kỹ thuật, người dùng có thể dùng chứng minh không kiến thức để xác nhận giao dịch mã hóa của họ tuân thủ yêu cầu kiểm duyệt, nhưng điều này làm tăng chi phí và độ phức tạp bổ sung. Ngay cả khi blockchain đảm bảo chống kiểm duyệt mạnh (đảm bảo giao dịch mã hóa chắc chắn được đưa vào), người xây dựng vẫn có thể ưu tiên đặt giao dịch rõ đã biết ở đầu khối, còn giao dịch mã hóa thì xếp cuối. Do đó, những giao dịch cần đảm bảo ưu tiên thực thi cuối cùng có thể vẫn bị buộc phải tiết lộ nội dung cho người xây dựng.
Những thách thức khác về hiệu suất
Mempool mã hóa 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 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ư đã nói, 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, vẫn có một số chi phí hiệu suất không dễ thấy. Trong lĩnh vực tài chính, nếu giá phản ánh mọi thông tin khả dụng, thị trường được coi là hiệu quả; độ trễ và bất cân xứng thông tin dẫn đến thị trường kém hiệu quả. Đây chính là hệ quả tất yếu mà mempool mã hóa mang lại.
Những tình trạng kém hiệu quả này gây ra hậu quả trực tiếp: độ bất định giá tăng, sản phẩm trực tiếp của độ trễ bổ sung do mempool mã hóa. Do đó, số lượng giao dịch thất bại do vượt ngưỡng trượt giá có thể tăng, từ đó lãng phí không gian trên chuỗi.
Tương tự, độ bất định giá này cũng có thể thúc đẩy giao dịch MEV đầu cơ, nhằm kiếm lời từ chênh lệch giá trên chuỗi. Lưu ý rằng, mempool mã hóa có thể khiến cơ hội này phổ biến hơn: do độ trễ thực thi, 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, rất có thể dẫn đến hiệu quả thị trường giảm, xuất hiện chênh lệch giá giữa các nền tảng giao dịch. Những giao dịch MEV đầu cơ này cũng lãng phí không gian khối, vì khi không phát hiện cơ hội arbitrage, chúng thường ngừng thực thi.
Tổng kết
Mục đích bài viết này là hệ thống hóa các thách thức mà mempool mã hóa đối mặt, để cộng đồng có thể chuyển trọng tâm sang phát triển các giải pháp khác, nhưng mempool mã hóa vẫn có thể trở thành một phần của chiến lược quản lý MEV.
Một hướng khả thi là thiết kế hỗn hợp: một phần giao dịch dùng mempool mã hóa để "sắp xếp mù", phần còn lại dùng các phương án sắp xếp khác. Với các loại giao dịch cụ thể (ví dụ lệnh mua/bán của các nhà tham gia thị trường lớn, có khả năng mã hóa hoặc thêm dữ liệu thặng dư 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. Với các giao dịch cực kỳ nhạy cảm (ví dụ giao dịch sửa hợp đồng an toàn có lỗ hổng), thiết kế này cũng có ý nghĩa thực tế.
Tuy nhiên, do hạn chế kỹ thuật, độ phức tạp kỹ thuật cao và chi phí hiệu suất lớn, mempool mã hóa khó có thể trở thành "giải pháp vạn năng cho MEV" như 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ủ tầng ứng dụng và rút ngắn thời gian xác nhận cuối cùng. MEV trong một thời gian tới vẫn sẽ là thách thức, cần nghiên cứu sâu để tìm điểm cân bằng giữa các giải pháp nhằm đối phó tác động tiêu cực của nó.
Chào mừng tham gia cộng đồng chính thức TechFlow
Nhóm Telegram:https://t.me/TechFlowDaily
Tài khoản Twitter chính thức:https://x.com/TechFlowPost
Tài khoản Twitter tiếng Anh:https://x.com/BlockFlow_News
a16z
