Makina Finance đã mất 1.299 ETH, tương đương khoảng 4,13 triệu đô la, trong một vụ tấn công bằng hình thức cho vay chớp nhoáng và thao túng hệ thống oracle.
Kẻ tấn công đã rút hết tiền trong giao thức và phát tán giao dịch đó lên mempool công khai của Ethereum, nơi lẽ ra các trình xác thực sẽ nhận được và đưa vào khối tiếp theo.
Thay vào đó, một người xây dựng MEV được xác định bằng địa chỉ 0xa6c2 đã chặn trước giao dịch rút tiền, chuyển hướng phần lớn số tiền vào tài khoản do người xây dựng kiểm soát trước khi tin tặc có thể chuyển chúng ra khỏi chuỗi.
Giao dịch của hacker đã thất bại. Số tiền đã được chuyển đến hai địa chỉ có liên quan đến nhà sản xuất MEV.
Điều đáng chú ý ngay lập tức là người dùng của Makina đã tránh được tổn thất hoàn toàn. Tín hiệu sâu sắc hơn là ai đã nắm giữ số tiền đó và điều đó có ý nghĩa gì đối với kiến trúc ứng phó khẩn cấp đang nổi lên của tiền điện tử.
Nhân tố quan trọng nhất trong câu chuyện này không phải là kẻ tấn công hay giao thức, mà là chuỗi cung ứng xây dựng khối đã chặn được lỗ hổng và hiện đang kiểm soát việc người dùng có được hoàn tiền hay không, theo điều kiện nào và nhanh đến mức nào.
Các bot và người xây dựng MEV đang trở thành tuyến phòng thủ cuối cùng của tiền điện tử, không phải do thiết kế mà do vị trí cấu trúc. Đó là một vấn đề, bởi vì khả năng giải cứu đang tập trung trong tay các trung gian tối đa hóa lợi nhuận hoạt động với trách nhiệm giải trình không rõ ràng.
MEV đóng vai trò như một biện pháp hỗ trợ đã trở thành một mô hình phổ biến.
Vụ việc Makina không phải là trường hợp cá biệt. Chainalysis đã ghi nhận một diễn biến tương tự trong vụ tấn công Curve và Vyper năm 2023, lưu ý rằng các hacker mũ trắng và người điều hành bot MEV đã giúp thu hồi tiền, làm giảm thiệt hại thực tế xuống dưới mức ước tính ban đầu.
Mô hình này mang tính cơ học: miễn là các cuộc tấn công hoặc nỗ lực giải cứu vẫn hiển thị trên các kênh giao dịch công khai, những người tìm kiếm và xây dựng hệ thống tinh vi có thể cạnh tranh để sắp xếp lại các giao dịch.
Đôi khi họ giúp tiết kiệm tiền. Đôi khi họ thu giữ tiền. Dù bằng cách nào, họ cũng đang đóng vai trò như một lớp ứng phó khẩn cấp trên thực tế.
Khi một giao dịch khai thác được đưa vào mempool công khai, các công cụ tìm kiếm MEV sẽ theo dõi để tìm kiếm các cơ hội sinh lời. Nếu tin tặc rút hết tiền từ một giao thức và phát tán giao dịch đó công khai, công cụ tìm kiếm có thể tạo ra một giao dịch cạnh tranh được thực thi trước, chuyển hướng tiền đến một địa chỉ khác.
Người tìm kiếm gom giao dịch lại và gửi cho người xây dựng khối, người này sẽ đưa giao dịch vào nếu lợi nhuận vượt quá các giá thầu cạnh tranh. Nếu khối của người xây dựng được người xác thực chọn, giao dịch của người tìm kiếm sẽ được thực thi và giao dịch của hacker sẽ thất bại.
Đây là hình thức thu lợi nhuận với tác dụng phụ có lợi chứ không phải là lòng vị tha thuần túy. Nhưng đây cũng là cơ chế đáng tin cậy nhất mà tiền điện tử đã phát triển để ngăn chặn các cuộc tấn công khai thác lỗ hổng trong thời gian thực, bởi vì nó hoạt động ở lớp sắp xếp giao dịch chứ không dựa vào các bộ ngắt mạch ở cấp độ giao thức hoặc sự can thiệp của quản trị.
Vì sao việc phụ thuộc vào các nhà sản xuất xe điện cỡ nhỏ lại gây khó chịu
Vấn đề với các hoạt động cứu hộ dựa trên MEV là chúng tập trung năng lực ứng phó khẩn cấp vào một chuỗi cung ứng trung gian phức tạp.
Trên Ethereum, MEV-Boost chiếm ưu thế trong việc tạo khối. Biểu đồ mạng chuyển tiếp của Rated cho thấy khoảng 93,5% các khối gần đây được định tuyến thông qua MEV-Boost, so với khoảng 6% sử dụng phương pháp tạo khối thông thường.

Trong MEV-Boost, thị phần của Relay tập trung hơn nữa: Ultra Sound Money chiếm khoảng 29,84% lưu lượng relay, và Titan chiếm khoảng 24,24%, có nghĩa là hai relay lớn nhất này cùng nhau xử lý hơn 54% sản lượng khối.
Nếu hầu hết các khối dữ liệu được truyền qua MEV-Boost và hầu hết lưu lượng MEV-Boost lại đi qua hai bộ chuyển tiếp, thì lớp cứu hộ về mặt cấu trúc sẽ phụ thuộc vào một nhóm nhỏ các trung gian. Điều đó nhanh chóng tạo ra các vấn đề về quản trị.
Nếu một người xây dựng nắm giữ số tiền được giải cứu, ai sẽ ủy quyền quyền quản lý? Ai sẽ ấn định tiền thưởng? Điều gì ngăn chặn hành vi tống tiền hoặc đòi tiền chuộc? Điều gì xảy ra nếu người xây dựng ở nước ngoài, ẩn danh hoặc hoạt động trong một khu vực pháp lý có luật lệ thực thi yếu kém?
Trường hợp của Makina minh họa vấn đề này. Tiền đang nằm trong tay nhà phát triển, nhưng không có thỏa thuận mức dịch vụ công khai, tiền thưởng được xác định trước hoặc cơ chế rõ ràng nào để hoàn trả tiền cho Makina hoặc người dùng của họ.
Nhà thầu có thể tự nguyện hoàn trả tiền, thương lượng một khoản tiền thưởng, yêu cầu mức phí cao hơn mức thông thường trong ngành, hoặc từ chối hoàn trả tiền hoàn toàn.
Việc sử dụng định tuyến riêng làm cho vấn đề trở nên tồi tệ hơn.
Một bài báo học thuật năm 2025 có tiêu đề “Bị kẹp giữa và im lặng” đã ghi nhận việc định tuyến giao dịch riêng tư phổ biến và phát hiện ra rằng nhiều nạn nhân chuyển sang các kênh riêng tư sau khi bị các bot MEV kẹp giữa.
Tuy nhiên, định tuyến riêng không loại bỏ MEV, mà chỉ chuyển nó từ các mempool công cộng sang các kênh luồng lệnh riêng do các builder và relay kiểm soát.
Đối với các giao thức, điều đó có nghĩa là việc khôi phục mempool công khai trở nên kém tin cậy hơn vì các giao dịch khai thác ngày càng được định tuyến qua các kênh riêng tư mà chỉ một nhóm nhỏ các nhà phát triển mới có thể truy cập.
Một nỗ lực nhằm văn minh hóa sự hỗn loạn
Safe Harbor là một khuôn khổ được SEAL phát triển nhằm thay thế mô hình "nhà sản xuất MEV đóng vai trò người quản lý bất đắc dĩ" bằng các bên phản hồi được ủy quyền, các thỏa thuận mức dịch vụ (SLA) rõ ràng và các ưu đãi có giới hạn.
SEAL mô tả Safe Harbor là một khuôn khổ pháp lý và kỹ thuật cho phép các giao thức ủy quyền trước cho các hacker mũ trắng can thiệp trong quá trình khai thác lỗ hổng đang diễn ra.
Nguyên tắc hoạt động cốt lõi là các khoản tiền được giải cứu phải được gửi đến các địa chỉ thu hồi chính thức trong vòng 72 giờ, kèm theo các khoản tiền thưởng đã được xác định trước và có thể thực thi.
SEAL cho biết Safe Harbor được thúc đẩy bởi vụ tấn công mạng Nomad, trong đó các hacker mũ trắng sẵn sàng giúp đỡ nhưng bị hạn chế bởi sự mơ hồ về mặt pháp lý liên quan đến việc liệu việc hoàn trả tiền có thể bị truy tố là hành vi truy cập máy tính trái phép hay không.
Safe Harbor loại bỏ sự mơ hồ đó bằng cách cung cấp cho các giao thức một cách để ủy quyền trước cho việc can thiệp và thiết lập các điều khoản rõ ràng. SEAL tuyên bố Safe Harbor hiện đang bảo vệ hơn 16 tỷ đô la trên các giao thức lớn, bao gồm Uniswap, Pendle, PancakeSwap, Balancer và zkSync.
Immunefi, nền tảng săn tìm lỗi bảo mật, đã triển khai Safe Harbor với các điều khoản nghiêm ngặt hơn.
Immunefi mô tả Safe Harbor là một khuôn khổ do SEAL phát triển, chuyển hướng tiền đến một kho tiền được kiểm soát bởi giao thức trên nền tảng của Immunefi. Trên trang chương trình Safe Harbor của Immunefi, các điều khoản nêu rõ: “Bạn có 6 giờ để chuyển tiền trở lại.”
Vi phạm thời hạn sáu giờ là một lỗi nghiêm trọng. Thời gian này nhanh hơn gấp bốn lần so với yêu cầu tối thiểu 72 giờ của SEAL.
Thỏa thuận Safe Harbor không loại bỏ sự phụ thuộc vào cơ sở hạ tầng xe điện cỡ nhỏ (MEV). Thay vào đó, nó chỉ cố gắng chính thức hóa sự phụ thuộc đó.
Nếu một nhà phát triển phần mềm tấn công chặn trước một lỗ hổng và giao thức đã áp dụng Safe Harbor, nhà phát triển đó được kỳ vọng sẽ nhận ra sự can thiệp này là được ủy quyền và chuyển tiền đến địa chỉ phục hồi được chỉ định của giao thức trong thời hạn SLA.
Nhưng điều đó giả định rằng các nhà xây dựng theo dõi các danh sách Safe Harbor, tôn trọng các điều khoản và ưu tiên tuân thủ hơn lợi nhuận.
Phạm vi kịch bản
Tỷ lệ khôi phục người dùng dự kiến trong một vụ khai thác có thể được mô hình hóa như sau: tỷ lệ khôi phục dự kiến bằng xác suất can thiệp, nhân với một trừ đi tỷ lệ phần trăm tiền thưởng, nhân với một trừ đi tỷ lệ phần trăm thất bại hoặc rò rỉ.
Chương trình Safe Harbor hướng đến việc tăng khả năng can thiệp bằng cách giảm bớt sự mơ hồ về mặt pháp lý và ấn định trước tỷ lệ tiền thưởng.
Trong kịch bản cơ bản, việc áp dụng Safe Harbor sẽ tăng lên trong 12 tháng tới. Ngày càng nhiều giao thức bổ sung các điều khoản Safe Harbor vào khuôn khổ quản trị của họ, và ngày càng nhiều hacker mũ trắng đăng ký làm người phản hồi được ủy quyền.
Xác suất can thiệp tăng lên vì người phản hồi có sự rõ ràng về mặt pháp lý và các điều khoản tiền thưởng cố định. Tỷ lệ phục hồi được cải thiện, đặc biệt đối với các giao thức áp dụng SLA nghiêm ngặt hơn, chẳng hạn như khung thời gian sáu giờ của Immunefi.
Trong trường hợp lạc quan, lớp cứu hộ được chuyên nghiệp hóa. Các giao thức xây dựng địa chỉ kho tiền được bảo mật chặt chẽ, rút ngắn thời gian SLA xuống còn vài giờ và đàm phán trước lịch trình tiền thưởng với các nhóm bảo mật mũ trắng đã được biết đến.
Các nhà xây dựng tích hợp các hệ thống đăng ký Safe Harbor vào thuật toán sắp xếp giao dịch của họ, tự động chuyển tiền được giải cứu đến các địa chỉ được chỉ định mà không cần can thiệp thủ công.
Trong trường hợp xấu nhất, sự phụ thuộc vào nhà cung cấp dịch vụ càng trở nên gay gắt. Luồng đơn đặt hàng riêng tư và sự tập trung vào máy chủ trung gian khiến các hoạt động giải cứu trở nên kém minh bạch và mang tính độc quyền cao hơn. Các giao thức chưa áp dụng Safe Harbor cuối cùng phải đàm phán với các nhà cung cấp dịch vụ sau khi sự việc đã xảy ra, mà không có đòn bẩy rõ ràng hoặc thỏa thuận mức dịch vụ (SLA).
Quản trị trở nên phụ thuộc vào các bên trung gian nắm giữ tiền và tự ý đặt ra các điều khoản.
| Chế độ | Ai có thể can thiệp? | Nơi các khoản tiền được chi tiêu | SLA | Điều khoản tiền thưởng | Trách nhiệm giải trình | Chế độ hỏng hóc |
|---|---|---|---|---|---|---|
| Cứu hộ MEV đột xuất (không có khu vực an toàn) | Bất kỳ người tìm kiếm/xây dựng/chuyển tiếp MEV nào phát hiện ra lỗ hổng và có thể giành được quyền ưu tiên. | Thường thì tài sản sẽ nằm trong sự quản lý của bên thứ ba (người xây dựng/người tìm kiếm ) | Không có | Đang thương lượng / Không rõ ràng (có thể biến thành tình huống "trả tiền cho tôi" tùy tiện) | Không minh bạch (không cần phê duyệt trước, không có nghĩa vụ chính thức) | Rủi ro đòi tiền chuộc/tống tiền , từ chối hoàn trả tiền, tình trạng bế tắc kéo dài, các vấn đề về thực thi pháp luật. |
| Cảng an toàn (Cơ sở SEAL) | Các hacker mũ trắng được ủy quyền trước (được ủy quyền rõ ràng bởi giao thức) trong quá trình khai thác đang diễn ra. | Địa chỉ khôi phục do giao thức chỉ định (địa điểm khôi phục chính thức) | 72 giờ | Được xác định trước / có thể thực thi (được thiết lập trước bởi giao thức) | Dựa trên quy tắc (quyền hạn giới hạn phạm vi + điều khoản được thiết lập sẵn) | Vi phạm điều khoản nếu tiền không được hoàn trả đúng hạn; lộ trình giải quyết tranh chấp rõ ràng hơn so với đàm phán tùy tiện. |
| Bảo vệ an toàn (Chương trình Immunofi) | Các đơn vị phản hồi được ủy quyền trước theo quy trình Safe Harbor của Immunefi (dựa trên SEAL) | Kho lưu trữ được kiểm soát bằng giao thức trên Immunefi (quy trình lưu giữ có cấu trúc) | 6 giờ | Cấu trúc phần thưởng/tiền thưởng được xác định trước (do dự án trong chương trình thiết lập) | Hình thức chính thức hơn (điều khoản nền tảng + tuân thủ theo khung thời gian) | Vi phạm nghiêm trọng nếu không trả lại trong vòng 6 giờ; thỏa thuận mức dịch vụ (SLA) chặt chẽ hơn giúp giảm thời gian chờ đợi nhưng tăng áp lực thực thi. |
Nên xem gì
Các chỉ số quan trọng bao gồm tốc độ áp dụng, thỏa thuận mức dịch vụ vận hành (SLA) và áp lực tập trung hóa.
Chu kỳ áp dụng có nghĩa là theo dõi số lượng giao thức bổ sung các đề xuất quản trị Safe Harbor và đăng ký vào danh sách các giao thức áp dụng của SEAL.
Các thỏa thuận mức dịch vụ (SLA) về mặt vận hành có nghĩa là theo dõi xem thị trường có thu hẹp thời gian phản hồi hay không: Thời gian phản hồi cơ bản 72 giờ của SEAL so với chương trình 6 giờ của Immunefi cho thấy rằng các SLA chặt chẽ hơn đang trở thành yếu tố tạo nên sự khác biệt cạnh tranh.
Áp lực tập trung hóa có nghĩa là theo dõi xem thị phần có còn tập trung ở một mức độ nhất định hay không.
Các bot MEV đang trở thành lớp phản ứng khẩn cấp của tiền điện tử, bất kể hệ sinh thái có thích điều đó hay không. Safe Harbor là nỗ lực nhằm biến điều đó thành một hệ thống có thể dự đoán được và có trách nhiệm giải trình.
Nhưng đó cũng là một canh bạc rằng các nhà xây dựng sẽ tôn trọng các điều khoản đã được phê duyệt trước, rằng các giao thức sẽ áp dụng khuôn khổ đủ nhanh và rằng sự tập trung trong quy trình xây dựng khối sẽ không làm suy yếu tính công bằng hoặc khả năng tiếp cận của các hoạt động cứu hộ.
Vụ việc Makina cho thấy điều gì xảy ra khi những giả định đó không đúng: tiền nằm trong tay nhà xây dựng mà không có con đường rõ ràng nào để chuyển lại cho người dùng.




