Ngày 15/07/2026, The Flashbots Ship đăng The MEV Letter #147 trên diễn đàn Flashbots Collective. Số này tổng hợp nhiều tài liệu độc lập, trong đó có một nghiên cứu về cơ chế đấu giá block dưới mô hình enshrined proposer builder separation (ePBS), một đề xuất sắp xếp giao dịch nhằm hạn chế front running và bài phân tích về lệnh swap Ethereum quy mô lớn được định tuyến qua các pool thanh khoản mỏng.
Những điểm chính cần nắm
- MEV Letter #147 là bản tin tổng hợp tài liệu về MEV, không phải thông báo triển khai một bản nâng cấp Ethereum.
- Nghiên cứu về ePBS cho rằng việc dùng giá thầu sớm làm tín hiệu có thể khiến builder giảm hoặc che giấu giá thầu. Nhóm tác giả đề xuất TEE sidecar để ràng buộc quy tắc dừng và công bố thông tin.
- PRECEDE dùng cơ chế xổ số ngẫu nhiên có trọng số theo giá thầu để làm giảm động lực front running. Đây là kết quả nghiên cứu, chưa phải quy tắc sắp xếp giao dịch đã được Ethereum áp dụng.
- Ví dụ khoảng 1,94 triệu USD đổi thành lượng token được định giá khoảng 14.000 USD cho thấy rủi ro từ định tuyến và thanh khoản mỏng. Bản tin không đưa ra bằng chứng rằng MEV hoặc sandwich attack là nguyên nhân.
- MEV Letter #147 là bản tin tổng hợp, không phải một báo cáo nghiên cứu duy nhất
- Cách ePBS thay đổi quan hệ giữa proposer và builder
- Vấn đề được chỉ ra trong nghiên cứu đấu giá block ePBS
- PRECEDE là đề xuất riêng nhằm giảm động lực front running
- Giao dịch khoảng 1,94 triệu USD cho thấy rủi ro định tuyến và thanh khoản
- Tác động đối với validator, builder và người dùng DeFi
- Câu hỏi thường gặp
MEV Letter #147 là bản tin tổng hợp, không phải một báo cáo nghiên cứu duy nhất
Theo The MEV Letter #147, mục tiêu của ấn phẩm là tập hợp các bài nghiên cứu, thảo luận và tài nguyên mới liên quan đến MEV. Số ngày 15/07 dẫn nhiều chủ đề khác nhau, từ ePBS, sắp xếp giao dịch, thị trường dự đoán và chain abstraction đến finality của Ethereum.
Điểm này quan trọng khi diễn giải nội dung. Việc một tài liệu xuất hiện trong MEV Letter không đồng nghĩa Flashbots là tác giả, đã kiểm chứng độc lập mọi kết quả hoặc có kế hoạch đưa cơ chế đó vào sản phẩm. Với các nghiên cứu mới, người đọc cần phân biệt giữa mô hình lý thuyết, thử nghiệm trên devnet và dữ liệu thu được từ mạng chính.
Số 147 cũng không chỉ tập trung vào ePBS. Bản tin dẫn một nghiên cứu riêng về front running và một bài đăng riêng về định tuyến swap. Việc gộp các nội dung này thành một kết luận chung dễ tạo cảm giác rằng ePBS trực tiếp giải quyết mọi vấn đề về thứ tự giao dịch hoặc thanh khoản, trong khi phạm vi của từng tài liệu khác nhau.
Cách ePBS thay đổi quan hệ giữa proposer và builder
Trong mô hình đang được dùng phổ biến, proposer thường thuê builder bên ngoài xây dựng execution payload và dựa vào middleware để thực hiện việc trao đổi block cùng khoản thanh toán. EIP-7732 về ePBS đề xuất đưa builder vào giao thức, dùng cam kết có chữ ký cho execution payload và tách thời điểm xác thực phần đồng thuận khỏi phần thực thi.
Thiết kế này bổ sung Payload Timeliness Committee (PTC), một nhóm validator có nhiệm vụ xác nhận builder đã công bố payload đúng thời hạn và dữ liệu blob có sẵn theo góc nhìn của họ. EIP cũng mô tả cơ chế thanh toán từ số dư của builder cho proposer. Mục tiêu là giảm sự phụ thuộc vào middleware đáng tin cậy và dành thêm thời gian cho việc xác thực execution payload.
Không nên diễn giải ePBS thành việc validator hoàn toàn mất vai trò trong xây dựng block. Đặc tả vẫn có lựa chọn proposer tự xây payload, còn validator tiếp tục thực hiện nhiệm vụ đồng thuận và có thể được phân công vào PTC. Thay đổi chính nằm ở cách proposer chọn cam kết của builder, cách payload được công bố và cách mạng xác nhận tính kịp thời của payload.
Tính đến thời điểm đối chiếu ngày 31/07/2026, EIP-7732 có trạng thái Review. Chương trình All Core Devs Consensus #183 ngày 23/07 vẫn theo dõi trạng thái devnet 7 và lên kế hoạch cho devnet 8, trong đó có các thay đổi liên quan đến builder API. Đây là quá trình thử nghiệm kỹ thuật, không phải bằng chứng ePBS đã hoạt động trên Ethereum mainnet.
Vấn đề được chỉ ra trong nghiên cứu đấu giá block ePBS
Nghiên cứu From PBS to ePBS, được gửi lên arXiv ngày 13/07/2026, mô hình hóa quá trình xây dựng block như một cuộc đấu giá hai giai đoạn trong điều kiện thông tin không hoàn hảo. Giá thầu sớm vừa là đề nghị thanh toán, vừa tiết lộ thông tin cho proposer và các builder khác.
Theo mô hình của nhóm tác giả, proposer có thể trì hoãn quyết định và sử dụng thông tin từ giá thầu sớm để tăng cạnh tranh ở giai đoạn sau. Builder dự đoán được hành vi này có thể giảm giá thầu hoặc đưa ra các mức giá khó phân biệt. Nhóm nghiên cứu gọi đây là ratchet effect, một dạng thất bại cam kết có thể tạo ra vùng kém hiệu quả về phân bổ và doanh thu trong một số cấu hình của mô hình.
Giải pháp được đề xuất là TEE sidecar, dùng môi trường thực thi tin cậy để buộc proposer tuân thủ trước quy tắc dừng đấu giá và công bố thông tin. Trong các benchmark hữu hạn thận trọng, nhóm tác giả báo cáo doanh thu của proposer tăng khoảng 25% so với mức chuẩn trong mô hình người thắng trả đúng giá đã đặt. Đây là kết quả từ mô hình và benchmark của nghiên cứu, không phải mức tăng đã đo trên mạng Ethereum.
Kênh Telegram chính thức của NIHONCASI: cập nhật tin crypto nhanh và gọn
PRECEDE là đề xuất riêng nhằm giảm động lực front running
Một tài liệu khác được MEV Letter #147 dẫn là nghiên cứu Time Is Money. Nhóm tác giả giới thiệu PRECEDE, cơ chế sắp xếp giao dịch bằng xổ số ngẫu nhiên có trọng số. Xác suất được xếp trước tăng theo lũy thừa của giá thầu thay vì chỉ ưu tiên tuyệt đối cho giao dịch trả phí cao nhất.
Mục tiêu của PRECEDE là làm cho chiến lược front running không còn hấp dẫn về mặt kinh tế trong trạng thái cân bằng mà nghiên cứu mô tả. Theo nhóm tác giả, người dùng có thể đặt một mức giá đủ để đối thủ không có động lực cạnh tranh, còn cơ chế ngẫu nhiên giúp tránh việc biến quá trình này thành cuộc đua tăng phí. Bài nghiên cứu cũng cho rằng cơ chế có thể chặn dạng sandwich attack phụ thuộc vào việc chèn giao dịch phía trước.
Tuy nhiên, PRECEDE không phải một phần của EIP-7732 và MEV Letter không cho biết cơ chế đã được đưa vào lộ trình nâng cấp Ethereum. Kết quả của bài báo nên được hiểu là đề xuất thiết kế cùng phân tích cân bằng, không phải bằng chứng mọi hình thức MEV có thể bị loại bỏ trong môi trường thực tế.
Giao dịch khoảng 1,94 triệu USD cho thấy rủi ro định tuyến và thanh khoản
MEV Letter #147 còn dẫn bài phân tích của Markus Schmitt về một lệnh đổi 1.126,44 ETH, được định giá khoảng 1,94 triệu USD tại thời điểm phân tích, sang LIT. Theo bài đăng, người dùng nhận 5.775 LIT có giá trị khoảng 14.000 USD sau khi lệnh được định tuyến qua các pool thanh khoản mỏng.
Tác giả so sánh kết quả thực tế với các mô phỏng dùng một tuyến duy nhất hoặc chia giao dịch qua nhiều tuyến và cho rằng các phương án khác có thể tạo đầu ra tốt hơn. Đây là ví dụ về việc một lệnh quá lớn so với độ sâu của pool có thể tự đẩy giá đi xa khi được thực thi.
Trường hợp này cần được tách khỏi nghiên cứu PRECEDE. Bản tin không nêu bằng chứng một searcher đã chèn giao dịch trước và sau lệnh swap, cũng không xác nhận người dùng bị sandwich attack. Dữ liệu được mô tả phù hợp trực tiếp hơn với rủi ro định tuyến, tác động giá và slippage. Muốn kết luận có MEV, cần phân tích thứ tự giao dịch, các địa chỉ liên quan và thay đổi trạng thái trong cùng block.
Giá trị USD trong tiêu đề bài phân tích cũng là con số ước tính tại một thời điểm. Nó không thay thế việc kiểm tra số token đầu vào, đầu ra, giá thị trường và mã giao dịch trên trình khám phá blockchain.
Tác động đối với validator, builder và người dùng DeFi
- Validator và proposer: ePBS thay đổi cách chọn cam kết từ builder, thanh toán và xác nhận payload. Nhiều proposer hiện đã thuê builder bên ngoài, nên đây không đơn thuần là việc lấy quyền sắp xếp giao dịch khỏi validator.
- Builder: nghiên cứu mới cho thấy thời điểm đặt giá, thông tin được công bố và khả năng cam kết của proposer có thể ảnh hưởng đến chiến lược đấu giá. Kết quả thực tế còn phụ thuộc vào đặc tả cuối cùng và hành vi trên mạng.
- Người dùng DeFi: ePBS không thay thế các bước kiểm tra trước khi swap. Với lệnh lớn, người dùng vẫn cần xem lượng nhận tối thiểu, tác động giá, độ sâu thanh khoản và khả năng chia nhỏ giao dịch.
- Nhà phát triển ứng dụng: cơ chế định tuyến cần xử lý trường hợp pool không đủ thanh khoản và giới hạn đầu ra tối thiểu. Một aggregator có thể so sánh nhiều tuyến, nhưng kết quả vẫn phụ thuộc dữ liệu giá cùng thanh khoản tại thời điểm thực thi.
Với các giao thức DeFi, bài học thực tế từ số 147 không nằm ở một giải pháp duy nhất. Thiết kế block, quy tắc sắp xếp giao dịch và chất lượng định tuyến tác động ở các lớp khác nhau. Mỗi vấn đề cần dữ liệu và tiêu chí đánh giá riêng.
📎 Độc giả có thể theo dõi thêm tin tức về Ethereum, DeFi và hạ tầng blockchain tại trang chủ NIHONCASI.
Tuyên bố miễn trừ trách nhiệm: Bài viết dựa trên thông tin công khai được đối chiếu đến ngày 31/07/2026. EIP, nghiên cứu, lịch thử nghiệm và đặc tả Ethereum có thể thay đổi sau thời điểm này. Các giá trị USD trong ví dụ giao dịch là ước tính tại thời điểm phân tích và không phải mức giá được bảo đảm. Nội dung chỉ nhằm cung cấp thông tin, không phải lời khuyên đầu tư, tài chính hoặc kỹ thuật; người dùng nên kiểm tra nguồn chính thức, thanh khoản và điều kiện giao dịch trước khi thực hiện swap.
Câu hỏi thường gặp
Không. Đây là bản tin định kỳ tổng hợp nhiều bài nghiên cứu, thảo luận và tài nguyên về MEV. Các tài liệu nổi bật trong số 147 do nhiều nhóm tác giả khác nhau thực hiện.
Chưa. Tại thời điểm đối chiếu ngày 31/07/2026, EIP-7732 có trạng thái Review, còn các nhóm phát triển vẫn theo dõi devnet và thay đổi liên quan đến builder API. Người đọc nên kiểm tra lại EIP cùng thông báo nâng cấp chính thức sau ngày này.
Chưa thể kết luận như vậy. Nhóm tác giả cho rằng PRECEDE có thể làm mất động lực front running trong mô hình của họ và ngăn dạng sandwich attack dựa vào front running. Cơ chế này chưa được xác nhận là đã triển khai trên Ethereum.
Không. Bài phân tích được MEV Letter dẫn tập trung vào lệnh lớn bị định tuyến qua pool thanh khoản mỏng và so sánh với các tuyến mô phỏng tốt hơn. Muốn xác định MEV hoặc sandwich attack cần thêm bằng chứng về thứ tự giao dịch cùng hoạt động của các địa chỉ trong block.







