Phân tích chuyên sâu MEV: Từ trò chơi tổng bằng không đến tam quyền phân lập
Tuyển chọn TechFlowTuyển chọn TechFlow
Phân tích chuyên sâu MEV: Từ trò chơi tổng bằng không đến tam quyền phân lập
MEV đang dần chuyển từ giai đoạn đấu đá kiểu rừng rậm ban đầu, trò chơi zero-sum sang giai đoạn tam quyền phân lập và cân bằng, và có lẽ đang tiến tới quyền riêng tư toàn diện.
Chuyên sâu báo cáo Web3Tóm tắt
-
MEV là gì: MEV viết đầy đủ là Miner Extractable Value (cũng có thể gọi là Maximal Extractable Value – Giá trị Tối đa Có thể Khai thác), chỉ khoản lợi nhuận bổ sung mà các thợ đào (miner) có thể thu được bằng cách thao túng thứ tự giao dịch (thêm, xóa, sắp xếp lại). Các hình thức khai thác MEV bao gồm: chênh lệch giá trên DEX, thanh lý khoản vay, Front-Running, Back-Running, tấn công Sandwich.
-
Tác động của MEV: Front-Running và giao dịch sandwich gây trải nghiệm người dùng kém và tổn thất lớn hơn; nhưng đồng thời, chênh lệch giá DEX và thanh lý nợ giúp thị trường DeFi nhanh đạt trạng thái cân bằng, duy trì ổn định thị trường.
-
Quy mô thị trường MEV: Sau The Merge của Ethereum, riêng phần thưởng MEV nhận bởi Block Proposer sử dụng Flashbots trên Ethereum đã vượt quá 206.450 ETH.
-
Flashbots: MEV-Geth giúp miner và searcher chia sẻ lợi nhuận MEV; MEV-Boost phân phối MEV giữa Proposer, Builder và Searcher, đồng thời bảo vệ giao dịch khỏi bị front-run; MEV-share hướng tới việc cho phép người dùng, ví và dApp thu về phần MEV sinh ra từ giao dịch của họ; MEV-SGX sử dụng phần cứng tin cậy SGX nhằm thay thế hoàn toàn vai trò trung gian Relay đáng tin cậy, hướng tới không cần cấp phép; SUAVE cố gắng giải quyết rủi ro tập trung do MEV gây ra. Với tư cách là một chuỗi chuyên dụng, cung cấp dịch vụ sắp xếp giao dịch và xây dựng khối cho mọi chuỗi hiện tại.
-
Chainlink: Là nền tảng orácle lớn nhất thị trường, đang cố gắng giảm thiểu vấn đề MEV ở cấp độ mạng lưới orácle thông qua việc sắp xếp giao dịch.
MEV là gì
MEV là viết tắt của Miner Extractable Value (hoặc còn gọi là Maximal Extractable Value - Giá trị Tối đa Có thể Khai thác), chỉ khoản lợi nhuận bổ sung mà các thợ đào hoặc trình xác thực (validator) có thể kiếm được bằng cách thao túng thứ tự giao dịch (thêm, xóa, thay đổi vị trí). Trong các chuỗi công cộng thông thường, tất cả giao dịch trước tiên phải gửi vào bộ nhớ đệm (mempool) để chờ được đưa vào khối. Thợ đào/Trình xác thực, với tư cách là những thực thể chịu trách nhiệm tạo khối trong hệ sinh thái blockchain, có quyền lực rất lớn khi quyết định khối nào sẽ chứa giao dịch nào.
Ban đầu, thợ đào chỉ sắp xếp giao dịch theo mức phí từ cao đến thấp để quyết định thứ tự đưa vào khối. Về sau, người ta nhận thấy rằng bằng cách giám sát mempool, thợ đào có thể thêm, xóa hoặc thay đổi thứ tự giao dịch để kiếm lợi nhuận ngoài phần thưởng tạo khối — từ đó xuất hiện khái niệm MEV.
Trong thực tế, thường có những "searcher" chuyên biệt sử dụng các thuật toán phức tạp để tìm cơ hội sinh lời. Vì các searcher cạnh tranh nhau trong mempool công khai, nên khi phát hiện cơ hội MEV, họ sẽ tăng phí giao dịch để đảm bảo giao dịch của mình được đưa vào khối. Do đó, lợi nhuận MEV được chia sẻ giữa miner và searcher. Tùy theo chiến lược, các phương pháp khai thác MEV bao gồm: arbitrage DEX, thanh lý khoản vay, Front-Running, Back-Running, tấn công sandwich... Trên các chuỗi sử dụng cơ chế đồng thuận xác suất cuối cùng (probabilistic finality) như Bitcoin hay Ethereum 1.0 (PoW), còn có thể xảy ra tấn công Fee Sniping.
-
Arbitrage DEX: Giá cả giữa các DEX khác nhau có thể chênh lệch. Tận dụng đặc tính giao dịch nguyên tử trên blockchain, có thể mua ở DEX giá thấp và bán ngay ở DEX giá cao để kiếm lợi nhuận không rủi ro.
-
Thanh lý khoản vay: Khi tỷ lệ thế chấp trong các giao thức cho vay thấp hơn ngưỡng quy định, giao thức cho phép bất kỳ ai thanh lý tài sản đảm bảo và thu hồi nợ. Người thanh lý thường nhận được một khoản phí lớn, một phần trong đó thuộc về họ — đây chính là cơ hội MEV.
-
Front Running: Hiểu đơn giản là “đi trước”, khi phát hiện một giao dịch sinh lời, kẻ tấn công sẽ gửi một giao dịch tương tự với mức phí cao hơn để được xử lý trước, từ đó chiếm lợi nhuận. Front-Running không chỉ đơn thuần là sao chép giao dịch, mà rộng hơn là chèn một giao dịch trước giao dịch mục tiêu để kiếm lời.
-
Back Running: Với các DEX sử dụng cơ chế AMM, các giao dịch lớn sẽ gây trượt giá đáng kể. Sau khi giao dịch lớn xảy ra, thị trường tạm mất cân bằng. Back Running là hành động chèn giao dịch ngay sau đó để mua tài sản với giá thấp hơn giá cân bằng.
-
Giao dịch sandwich: Kết hợp Front-Running và Back-Running. Trước giao dịch lớn, kẻ tấn công mua vào với giá thấp; sau khi giao dịch lớn đẩy giá lên, họ bán ra với giá cao để thu lợi nhuận lớn.
-
Tấn công Fee Sniping: Gần đây, cơn sốt BRC-20 khiến mạng Bitcoin tắc nghẽn, phí giao dịch liên tục tăng, làm người ta quan tâm trở lại loại tấn công này. Trên mạng blockchain PoW, nếu lợi nhuận tiềm năng đủ lớn, thợ đào có thể đảo ngược hoặc tái cấu trúc vài khối gần nhất, bằng cách sắp xếp lại hoặc thêm vào các giao dịch cụ thể để kiếm thêm lợi nhuận. Lưu ý: Trước The Merge, Ethereum cũng dùng cơ chế PoW, nhưng thuật ngữ tương ứng ở đây là Time Bandit.
Tác động của MEV
MEV vừa gây hại cho người dùng, thậm chí cả mạng lưới blockchain, nhưng đồng thời cũng giúp thị trường hoạt động hiệu quả hơn.
1. Lợi ích
Việc arbitrage DEX và thanh lý khoản vay giúp thị trường DeFi nhanh đạt trạng thái cân bằng, duy trì sự ổn định. Giống như tài chính truyền thống, các searcher MEV thực chất là điều kiện tiên quyết để tồn tại một thị trường tài chính hiệu quả. Với các dạng MEV này, lợi nhuận mà searcher thu được đến từ chính thị trường.
2. Tác hại
Front-Running và giao dịch sandwich gây trải nghiệm người dùng tồi tệ và tổn thất nghiêm trọng hơn. Các searcher MEV cạnh tranh nhau bằng cách đấu giá phí gas, dẫn đến tắc nghẽn mạng và đẩy giá gas lên cao. Với các chuỗi PoW có tính cuối cùng xác suất, nghiêm trọng hơn là nguy cơ tấn công Fee Sniping – các cuộc tấn công Time-Bandit vi phạm nguyên tắc "bất biến" (Immutability) của blockchain, gây tổn hại nghiêm trọng đến an ninh và ổn định mạng lưới. Đây là lý do cộng đồng BTC gần đây lo ngại về ảnh hưởng của giao thức Ordinals. Với các chuỗi PoS, đặc biệt là Ethereum hiện tại (ETH2.0), MEV có thể dẫn đến tập trung hóa trình xác thực. Các nhóm stake lớn hơn sẽ thu được nhiều MEV hơn, từ đó có thêm nguồn lực nâng cao khả năng khai thác MEV, tạo ra hiệu ứng Matthew, cuối cùng dẫn đến tập trung hóa trình xác thực và làm giảm an ninh hệ thống.
Lịch sử phát triển của MEV
MEV phát triển song hành với sự phức tạp ngày càng tăng.
Giai đoạn sơ khai (2010–2017)
Năm 2015, Peter Todd – nhà phát triển lõi của Bitcoin – giới thiệu khái niệm "Replace By Fee (RBF)" trên Twitter, tiền thân của Front-Running, cho phép người dùng thay thế giao dịch cũ bằng một giao dịch mới có ít nhất một đầu vào giống nhau nhưng phí cao hơn. Từ RBF, cộng đồng Bitcoin dần phát triển nghiên cứu về Fee Sniping – thợ đào cố tình đào lại một hoặc nhiều khối trước đó để chiếm phí mà thợ đào ban đầu nhận được. Mặc dù khả năng thành công thấp hơn so với việc mở rộng chuỗi bằng khối mới, nhưng nếu khối cũ mang lại giá trị phí cao hơn lượng giao dịch trong mempool hiện tại, thì hành động này vẫn có lợi nhuận. Fee Sniping sau đó được mở rộng sang mô hình EVM và được mô tả trong bài báo "Flash Boys 2.0" dưới dạng tấn công "Time Bandit".
Chính thức ra đời (2018–2019)
MEV chỉ xuất hiện khi có tranh chấp trạng thái hoặc chuyển tiếp trạng thái chưa được xác nhận. Bitcoin hầu như không có trạng thái chung và việc chuyển tiếp trạng thái bị giới hạn chặt chẽ, nên MEV trên Bitcoin chủ yếu giới hạn ở Fee Sniping và thử nghiệm double-spend. Trong khi đó, trên Ethereum với hợp đồng thông minh Turing-complete, cơ hội MEV tăng đáng kể.
Năm 2016, DEX đầu tiên của Ethereum – EtherDelta – ra mắt với thiết kế sổ lệnh con, thực tế đã tạo ra nhiều cơ hội MEV nhưng chưa được tận dụng. Năm 2017, stablecoin thuật toán đầu tiên trên Ethereum – DAI – xuất hiện, cung cấp chức năng thanh lý, tạo ra cơ hội MEV lớn nhưng không thường xuyên (Spike MEV). Năm 2018, Hayden Adams sáng lập Uniswap – DEX đầu tiên trên Ethereum sử dụng cơ chế AMM. Chính cơ chế AMM phụ thuộc vào các bên khai thác MEV để duy trì hiệu quả thị trường, làm gia tăng mạnh mẽ cơ hội MEV. Cuốn sách "Flash Boys 2.0" xuất bản tháng 4/2019 đưa nghiên cứu MEV vào dòng chính. Cuối năm 2019, một nhóm những người du mục kỹ thuật số cùng chí hướng thành lập Pirate Ship, sau đổi tên thành Flashbots, lấy biểu tượng robot làm logo.
Ý tưởng logo ban đầu của flashbots
Tháng 1/2021, Flashbots Auction (mev-geth và flashbots relay) chính thức ra mắt, nhân đà nóng lên của mùa DeFi, lượng MEV được khai thác tăng mạnh.
Hiện trạng: MEV nở rộ, Flashbots dẫn đầu
Khi thị trường MEV ngày càng lớn, nhiều dự án bắt đầu tham gia. Flashbots hiện chỉ hỗ trợ mạng chính Ethereum, nên các Layer 1 và Layer 2 thay thế chủ lưu đều học hỏi Flashbots, cố gắng triển khai chức năng đấu giá MEV. Một số dự án chọn con đường khác, thí dụ mã hóa mempool để giải quyết triệt để MEV. Bản thân Flashbots cũng không ngừng đổi mới: sau Flashbots Alpha đầu 2021, lần lượt ra mắt Flashbots Protect, MEV-Boost, MEV-Share, và đang phát triển thế hệ tiếp theo là SUAVE. Quy mô thị trường MEV lớn đến đâu? Về lý thuyết, lợi nhuận MEV tiềm tàng trong giao dịch người dùng là vô hạn. Tuy nhiên, không thể tính toán chính xác con số này, nên người ta dùng "MEV đã hiện thực hóa" (Realized EV – REV) để ước lượng.
Theo dữ liệu từ Flashbots, sau The Merge của Ethereum, tổng REV đã khai thác vượt quá 206.450 ETH. Tuy nhiên, đây chỉ là phần lợi nhuận mà Block Proposer nhận được, chưa tính phần lợi nhuận của các Searcher.
Không có cạnh tranh thị trường thì sẽ tốt hơn?
Dựa trên kinh nghiệm lịch sử của xã hội loài người, "bàn tay vô hình" thường là lựa chọn tốt hơn trong hầu hết trường hợp. Tuy nhiên, gần như không ai phủ nhận rằng trong một số lĩnh vực nhất định, kinh tế thị trường không phù hợp, và lạm dụng thị trường có thể gây hậu quả nghiêm trọng. Vấn đề phí gas tăng do Front-Running bắt nguồn từ cơ chế định giá gas của Ethereum. Liệu có thể giữ phí gas ở mức cố định để tránh cuộc đấu giá gas ưu tiên (Priority Gas Auction)? Nhưng điều này dễ dẫn đến thỏa thuận ngầm ngoài chuỗi: các Searcher có cơ hội MEV sẽ hối lộ thợ đào để giao dịch của họ được đưa vào sớm hơn, từ đó hình thành thị trường nhỏ lẻ ngoài chuỗi, trái với tinh thần mở và phi cấp phép của Ethereum. Tất nhiên, chúng ta có thể yêu cầu thợ đào/trình xác thực phải được chứng nhận bởi một tổ chức uy tín để đảm bảo họ không làm điều xấu, nhưng điều này tạo ra giả định tin cậy cực mạnh, biến chuỗi thành chuỗi được cấp phép. Tóm lại, trong khuôn khổ duy trì các đặc điểm hiện tại của Ethereum, có lẽ rất khó để loại bỏ hoàn toàn MEV.
Cách giảm thiểu tác động tiêu cực của MEV
PBS cấp giao thức – Giải pháp của cộng đồng Ethereum
Trong PoS, các trình xác thực luân phiên đóng vai trò đề xuất khối (proposer), và cùng nhau đạt đồng thuận để quyết định khối có được ghi vào chuỗi hay không. Trong PoW, công việc tạo khối và đạt đồng thuận do thợ đào thực hiện – về bản chất là tương đương. PBS (Proposer-Builder Separation) chủ yếu nhằm giải quyết vấn đề tập trung hóa trình xác thực do MEV gây ra. Trong quy trình MEV mặc định, người tạo khối có hai nhiệm vụ: (1) xây dựng khối tối ưu từ các giao dịch khả dụng (block building), và (2) đề xuất khối đó cùng bằng chứng công việc hoặc cổ phần lên mạng (block proposing). Khi MEV chưa được khai thác sâu, bước (1) đơn giản là sắp xếp giao dịch theo phí từ cao xuống thấp. Nhưng khi lợi nhuận MEV ngày càng lớn, các nhóm thợ đào/trình xác thực lớn hơn thực tế thu được nhiều MEV hơn tỷ lệ thị phần, tạo hiệu ứng Matthew, khiến mạng lưới ngày càng tập trung. Hơn nữa, thực thể thực sự tạo khối trong các nhóm khai thác phi tập trung sẽ nắm cơ hội MEV, trong khi các thành viên khác không chia được lợi nhuận. Cơ chế bất công này làm giảm tỷ lệ tham gia vào các nhóm phi tập trung, làm tăng thêm mức độ tập trung. Các vai trò có thể liên quan đến MEV bao gồm:
-
Producer: Người tạo khối (Miners, Validators)
-
Proposer: Người đề xuất khối (chọn khối do Builder có MEV cao nhất xây dựng)
-
Builder: Người xây dựng khối (quyết định nội dung khối)
-
Searcher: Tìm kiếm cơ hội MEV trong giao dịch
-
User: Người gửi giao dịch có thể tạo MEV. Tất nhiên, hiện tại nhiều vai trò thường do cùng một thực thể đảm nhận, ví dụ trong quy trình đồng thuận Ethereum thông thường, Producer, Proposer và Builder là cùng một vai trò.
Giải pháp ban đầu của Vitalik
Vitalik đã đề xuất hai giải pháp từ đầu năm 2021, mỗi cái nhấn mạnh khác nhau. Cần lưu ý, các giải pháp trong phần này là ở cấp giao thức Ethereum, do giao thức ép buộc thực thi PBS, chứ không phải các thỏa thuận riêng như Flashbots. PBS nhằm đạt năm mục tiêu sau:
-
Không cần tin tưởng Proposer: Builder không cần tin tưởng Proposer
-
Không cần tin tưởng Builder: Proposer không cần tin tưởng Builder
-
Proposer nhẹ: Proposer không cần tài nguyên tính toán hay kỹ thuật cao
-
Bundle không bị đánh cắp: Proposer không thể tự chiếm lợi nhuận từ bundle mà Builder gửi
-
Đơn giản và an toàn trong đồng thuận: Giữ an toàn, tốt nhất là không thay đổi cơ chế đề xuất khối hiện tại
Giải pháp 1
-
Builder tạo các bundle, gửi header bundle cho Proposer, trong đó chứa hash của body bundle, khoản thanh toán cho Proposer và chữ ký của Builder
-
Proposer chọn header bundle có lợi nhuận cao nhất, ký và công bố proposal chứa header đó
-
Sau khi thấy proposal đã ký, Builder mới công bố bundle đầy đủ
Phân tích theo năm mục tiêu:
-
Proposer có thể nhận phí từ Builder nhưng không cho Builder nhận được lợi nhuận MEV, ví dụ bằng cách chỉ công bố proposal ở cuối slot, khiến Builder không kịp công bố bundle đầy đủ → không đạt mục tiêu 1
-
Chỉ cần gửi header bundle là đảm bảo nhận được tiền từ Builder, Proposer không cần tin tưởng Builder → đạt mục tiêu 2
-
Chỉ cần giao tiếp mạng đơn giản và ký cơ bản → đạt mục tiêu 3
-
Proposer không thể biết nội dung bundle, chỉ thấy header → đạt mục tiêu 4
-
Do thêm vai trò Builder, cần sửa luật phân nhánh, và tăng số trường hợp từ 2 lên 3, làm phức tạp lựa chọn phân nhánh, gây bất ổn mới → không đạt mục tiêu 5
Giải pháp 2
-
Builder tạo bundle, gửi header cho Proposer, chứa hash body, khoản thanh toán và chữ ký
-
Proposer chọn một danh sách các header đã thấy, ký một tuyên bố (commitment)
-
Builder thấy commitment, công bố body bundle tương ứng
-
Proposer chọn một header trong danh sách đã ký, công bố proposal chứa header đó
Phân tích theo năm mục tiêu:
-
Chỉ khi bundle được đưa đầy đủ vào proposal thì Builder mới thanh toán cho Proposer → đạt mục tiêu 1
-
Builder có thể gửi nhiều header với phí cao nhưng không công bố body thật, khiến Proposer không thể đưa bundle hợp lệ → không đạt mục tiêu 2
-
Nếu không giới hạn số bundle nhận được, Proposer có thể bị quá tải băng thông mạng → không đạt mục tiêu 3
-
Proposer đã ký cam kết, chỉ có thể chọn trong danh sách đó, không thể chiếm lợi nhuận → đạt mục tiêu 4
-
Builder không tham gia trực tiếp vào đồng thuận, hành vi Proposer không đổi, không làm tăng phân nhánh → đạt mục tiêu 5
Hai hướng phát triển – Two Slot PBS vs Single Slot PBS
Hai hướng này là cải tiến và chi tiết hóa từ hai giải pháp ban đầu của Vitalik: Two Slot PBS và Single Slot PBS tương ứng với giải pháp 1 và 2.
Trong Two Slot PBS, sẽ thêm một loại khối mới gọi là "khối trung gian" (Intermediate Block), để chứa nội dung khối do Builder thắng cuộc xây dựng. Tại slot n, Proposer sẽ đề xuất một Beacon Block thông thường, trong đó chứa commitment tới nội dung khối của Builder thắng. Sau đó, tại slot n+1, Builder thắng sẽ đề xuất Intermediate Block, chứa nội dung khối thật sự. Hai khối này có thể coi là hai phần của một khối lớn, chỉ chia thành hai giai đoạn (slot). Giai đoạn đầu giống như header khối (Block Header), giai đoạn sau mới là thân khối thật sự (Block Body). Nếu không có Beacon Block, nghĩa là không có Builder thắng đấu giá, thì sẽ không có Intermediate Block.
Cả hai khối đều cần attestation từ Committee. Beacon Block có một committee bỏ phiếu, Intermediate Block do tất cả committee còn lại trong slot bỏ phiếu. Phiếu bầu cho mỗi khối (Beacon hay Intermediate) sẽ xuất hiện trong khối của slot tiếp theo.
Nếu Builder không thấy Beacon Block, có thể do nó không được công bố kịp, thì Builder sẽ không công bố Intermediate Block. Ngoài ra, để tránh thiệt hại cho Builder nếu Beacon Block xuất hiện muộn, cơ chế dùng Fork Choice Rule rõ ràng để từ chối Beacon Block đó.
Thiết kế Two Slot PBS
Single Slot PBS sử dụng committee phi tập trung làm trung gian lưu trữ nội dung khối. Builder gửi header bundle tới mạng con đấu giá (auction subnet), đồng thời gửi body bundle đã chia nhỏ và mã hóa tới committee. Khi committee bỏ phiếu vượt ngưỡng, Proposer gửi proposal, committee nhận được sẽ giải mã và phát tán body bundle, từ đó hoàn tất việc tạo khối PBS trong một slot duy nhất.
Thiết kế Single Slot PBS
Ethereum cần PBS cấp giao thức, không chỉ vì MEV
Việc triển khai PBS ở cấp giao thức Ethereum có thể làm lung lay nền tảng đồng thuận và tạo ra nhiều vấn đề mới. Vậy tại sao phải sửa giao thức, thay vì dùng giải pháp ở lớp trên? Có thể nói, cộng đồng Ethereum thực chất muốn đạt nhiều mục đích hơn là chỉ giải quyết MEV. PBS không chỉ giảm thiểu MEV, mà còn có ý nghĩa lâu dài với sự phát triển của Ethereum.
Trong PBS, Proposer không cần xử lý sắp xếp giao dịch, từ đó trở nên "vô trạng thái" (stateless), không cần lưu trữ toàn bộ trạng thái Ethereum, mà chỉ cần dùng Merkle Proof để kiểm tra tính hợp lệ của giao dịch trong khối do Builder đóng gói. Khi Danksharding ngày càng được đưa vào lộ trình, gánh nặng lưu trữ sẽ càng lớn. Tính vô trạng thái rất quan trọng, giúp giảm yêu cầu lưu trữ cho Proposer, cho phép nhiều người hơn tham gia, tăng tính phi tập trung.
Cộng đồng Ethereum đề xuất PBS cũng giống như EIP-1559 trước đây. Thợ đào/Trình xác thực với quyền lực lớn trong việc quyết định nội dung khối, nếu thu lợi quá nhiều sẽ dẫn đến tập trung hóa, quyền lực lớn đến mức ảnh hưởng an ninh toàn bộ mạng. PBS nhằm mục đích làm suy yếu vị thế của thợ đào/trình xác thực, giảm thu nhập, phân tán quyền lực ra cộng đồng.
Ngoài ra, trong giải pháp PBS do Flashbots MEV-Boost thực hiện, do giả định tin cậy vào Relay, nên có thể xảy ra vấn đề kiểm duyệt giao dịch – điều này phá hoại nghiêm trọng tầm nhìn kháng kiểm duyệt và phi cấp phép của Ethereum.
Giao dịch bị kiểm duyệt có thể chiếm tới 80%
PBS cấp giao thức Ethereum không cần tin tưởng Relay, có thể buộc Builder phải đưa vào hoặc tự đưa vào các giao dịch bị kiểm duyệt thông qua cơ chế kiểm soát của Proposer đối với Builder, từ đó tăng tính kháng kiểm duyệt của Ethereum.
Tóm lại: PBS cấp giao thức Ethereum phân phối lợi ích giữa Builder và Proposer, giảm门槛 cho Proposer, tăng tính phi tập trung và khả năng kháng kiểm duyệt cho Ethereum, nhưng không cải thiện trải nghiệm người dùng bình thường.
Flashbots – Ách thống trị tuyệt đối trong lĩnh vực MEV
Flashbots sử dụng đấu giá thị trường để giảm thiểu MEV, mang lại lợi ích cho các bên tham gia. Trong tài liệu chính thức của Flashbots, họ phân loại thành: 1) Flashbots Auction, 2) Flashbots Data, 3) Flashbots Protect, 4) Flashbots MEV-Boost, 5) Flashbots MEV-Share. Tuy nhiên, thực tế MEV-Boost chỉ là một giai đoạn của Flashbots Auction. Tôi sẽ trình bày theo trình tự thời gian.
Flashbots Auction gồm hai giai đoạn: MEV-Geth dành cho ETH1.0 (trước The Merge) và MEV-Boost dành cho ETH2.0 (sau The Merge).
MEV-Geth
Đầu 2021, Flashbots ra mắt MEV-Geth và MEV-Relay. MEV-Geth là bản vá cho client Go-Ethereum, chỉ khoảng trăm dòng code; MEV-Relay là bộ chuyển tiếp bundle, chịu trách nhiệm chuyển tiếp bundle giao dịch giữa Searchers và Miners. MEV-Geth và MEV-Relay cung cấp một mempool riêng tư và đấu giá không gian khối theo kiểu "gói kín", biến MEV từ "rừng đen" thành một thị trường kinh tế. Bundle là một loại giao dịch mới, thể hiện sở thích về thứ tự giao dịch. Flashbots Auction giới thiệu RPC mới tên "eth_sendBundle" để chuẩn hóa việc truyền thông bundle. Bundle bao gồm chuỗi giao dịch đã ký và các điều kiện để đưa vào khối.
Đồng thời, Flashbots cũng cung cấp nút RPC Flashbots Protect, cho phép người dùng chỉ cần thay đổi nút RPC trong ví để tránh bị Front-Running trên mempool công khai. Ngoài ra, do Flashbots Protect gửi giao dịch qua một quy trình tạo khối riêng, nên không xảy ra revert, người dùng không phải trả phí cho giao dịch thất bại (nhưng dẫn đến luồng đơn hàng độc quyền EOF).
MEV-Geth nhanh chóng được hơn 90% thợ đào Ethereum áp dụng và giúp họ tăng lợi nhuận đáng kể. Tuy nhiên, thiết kế đấu giá đơn giản này có một số nhược điểm rõ rệt: 1) Cần tin tưởng thợ đào, 2) Chỉ tương thích Geth, thiếu đa dạng, 3) Dịch vụ đấu giá chạy trên máy chủ tập trung, có rủi ro điểm lỗi đơn lẻ. Ngoài ra, do sự cạnh tranh phổ biến giữa các searcher, phần lớn lợi nhuận rơi vào tay thợ đào, gây rủi ro tập trung cho Ethereum.
MEV-Boost
Sau The Merge, Ethereum chuyển sang đồng thuận PoS, vấn đề tập trung do MEV càng rõ rệt hơn. Flashbots thiết kế MEV-Boost để giải quyết vấn đề này. MEV-Boost có thể coi là một biến thể của Single Slot PBS. Khác với PBS cấp giao thức, MEV-Boost là một phần mềm trung gian tùy chọn, không ép buộc bằng giao thức, không thay đổi quy trình đồng thuận. Relay không còn là trung gian giữa User/Searcher và Miner, mà trở thành nút trung gian giữa Builder và Validator. Theo luồng giao dịch từ User/Searcher, mỗi bên Builder, Relay, Validator đều chọn khối nào có lợi nhuận cao nhất để gửi xuống.
MEV-Boost áp dụng cơ chế commit-reveal như trong Single Slot PBS: chỉ khi Validator commit vào header khối, Builder mới reveal toàn bộ nội dung khối. Quy trình cụ thể như hình dưới: Trước khi đề xuất, Validator cần đăng ký với MEV-Boost và các relay để đảm bảo các block builder có thể xây dựng khối cho validator đó.
-
Người dùng/Searcher gửi giao dịch tới block builders qua mempool công khai/riêng tư
-
Block builders xây dựng execution payload từ giao dịch nhận được. Về phân phối lợi nhuận: builder đặt địa chỉ của mình làm coinbase address, và giao dịch cuối cùng là chuyển tiền tới địa chỉ proposer. Khối được gửi tới relay
-
Relay kiểm tra tính hợp lệ của khối, gửi ExecutionPayloadHeader tới MEV-Boost. MEV-Boost chọn header có lợi nhuận cao nhất từ các relay và chuyển tới Validator
-
Validator ký vào header, gọi submitBlindedBlock gửi lại MEV-Boost, chuyển tiếp tới relay. Relay kiểm tra chữ ký, gửi payload body đầy đủ tới MEV-Boost và chuyển tiếp tới consensus, để Validator sử dụng khi đề xuất SignedBeaconBlock lên mạng.
So với MEV-Geth, MEV-Boost linh hoạt hơn, dùng như plugin cho Consensus Client, hỗ trợ nhiều client khác nhau, đồng thời giảm bớt vấn đề tập trung thợ đào. Tuy nhiên, sau PBS, Builder có quyền lực lớn hơn, và Builder chiếm ưu thế trên thị trường có thể kiểm soát việc kiểm duyệt và độc quyền luồng giao dịch. Hiện tại chỉ có thể giảm rủi ro tập trung bằng cách khuyến khích cạnh tranh giữa các Builder. Mức độ tin cậy của Relay cũng giảm, nhưng vẫn có thể tạo rủi ro cho Builder và Proposer bằng cách gửi giá thầu ảo. Hiện tại dùng cách giám sát tính trung thực của Relay, để Validator và Builder tự do lựa chọn Relay.
MEV-Share
MEV-Geth giúp miner và searcher chia sẻ lợi nhuận MEV; MEV-Boost phân phối MEV giữa Proposer, Builder và Searcher, đồng thời bảo vệ giao dịch người dùng khỏi bị front-run. Tuy nhiên, cả hai đều chưa xét đến lợi ích người dùng. Trong triết lý Web3, giá trị do dữ liệu người dùng tạo ra nên được hoàn trả cho chính họ. MEV-Share là hiện thân của tri
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
@CynicSong
