Sự thật đằng sau các bot tiền điện tử phát nổ, đứng trước các tên trộm để "cứu" quỹ — nhưng họ quyết định ai sẽ được hoàn trả

Nguồn: CryptoNewsNet Tiêu đề gốc: Sự thật bùng nổ đằng sau các bot crypto đứng trước để “cứu” quỹ — nhưng chúng quyết định ai được hoàn trả Liên kết gốc:

Sự cố Makina Finance

Makina Finance mất 1.299 ETH, khoảng 4,13 triệu đô la, trong một vụ khai thác thao túng flash-loan và oracle.

Kẻ tấn công đã rút sạch quỹ của giao thức và phát tán giao dịch ra mempool công cộng của Ethereum, nơi các validator đáng lẽ ra phải bắt được và đưa vào block tiếp theo.

Thay vào đó, một builder MEV được xác định bởi địa chỉ 0xa6c2 đã đứng trước giao dịch rút tiền, chuyển hướng phần lớn quỹ vào kho bạc do builder kiểm soát trước khi hacker có thể chuyển chúng ra khỏi chuỗi.

Giao dịch của hacker thất bại. Quỹ đã về hai địa chỉ liên quan đến builder MEV.

Điều cần rút ra ngay lập tức là người dùng của Makina đã tránh được mất mát toàn bộ. Tín hiệu sâu hơn là ai đang giữ tiền và điều đó có ý nghĩa gì đối với kiến trúc phản ứng khẩn cấp mới nổi của crypto.

Nhân vậ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 block đã chặn đứng vụ khai thác và hiện kiểm soát việc người dùng có lấy lại được quỹ hay không, theo điều kiện nào, và nhanh đến mức nào.

Bot và builder MEV đang trở thành tuyến phòng thủ cuối cùng của crypto, không phải theo thiết kế mà do vị trí cấu trúc của chúng. Đó là một vấn đề, vì khả năng cứu hộ tập trung vào tay các trung gian tối đa hóa lợi nhuận hoạt động với trách nhiệm không rõ ràng.

MEV như một biện pháp dự phòng đã trở thành mẫu hình

Sự cố Makina không phải là một trường hợp duy nhất. Chainalysis đã ghi nhận một động thái tương tự trong vụ khai thác Curve và Vyper năm 2023, lưu ý rằng các hacker white hat và các nhà vận hành bot MEV đã giúp phục hồi quỹ, làm giảm thiệt hại thực tế xuống dưới ước tính ban đầu.

Mô hình này mang tính cơ học: miễn là các vụ khai thác hoặc nỗ lực cứu hộ còn rõ ràng trong các kênh giao dịch công cộng, các nhà tìm kiếm và xây dựng phức tạp có thể cạnh tranh để sắp xếp lại các giao dịch.

Đôi khi họ cứu được quỹ. Đôi khi họ chiếm đoạt chúng. Dù thế nào đi nữa, họ đang hoạt động như một lớp phản ứng khẩn cấp thực tế.

Khi một giao dịch khai thác vào mempool công cộng, các nhà tìm kiếm MEV sẽ theo dõi các cơ hội có lợi nhuận. Nếu hacker rút sạch một giao thức và phát tán giao dịch ra công chúng, một nhà tìm kiếm có thể xây dựng một giao dịch cạnh tranh thực thi trước, chuyển hướng quỹ đến địa chỉ khác.

Nhà tìm kiếm gom các giao dịch lại và gửi cho builder block, người này sẽ đưa vào nếu lợi nhuận vượt quá các đề nghị cạnh tranh. Nếu block của builder được validator chọn, giao dịch của nhà tìm kiếm sẽ thực thi, và giao dịch của hacker thất bại.

Đây là việc khai thác lợi nhuận kèm theo tác dụng phụ có lợi, chứ không phải hoàn toàn vì altruism. Nhưng đó cũng là cơ chế đáng tin cậy nhất mà crypto đã phát triển để chặn đứng các vụ khai thác trong thời gian thực, vì hoạt động ở lớp sắp xếp thứ tự giao dịch thay vì dựa vào các circuit breaker hoặc can thiệp của governance ở cấp giao thức.

Tại sao phụ thuộc vào builder MEV lại gây khó chịu

Vấn đề với các vụ cứu hộ dựa trên MEV là chúng tập trung khả năng phản ứng khẩn cấp vào một chuỗi trung gian rất nhiều.

Trên Ethereum, MEV-Boost chi phối phần lớn quá trình tạo block. Bảng xếp hạng relay của Rated cho thấy khoảng 93,5% các block gần đây được định tuyến qua MEV-Boost, so với khoảng 6% qua quá trình tạo block gốc.

Trong MEV-Boost, thị phần relay còn 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%, nghĩa là hai relay lớn nhất cùng nhau xử lý hơn 54% quá trình tạo block.

Nếu phần lớn các block đi qua MEV-Boost và phần lớn lưu lượng của MEV-Boost đi qua hai relay, lớp cứu hộ về mặt cấu trúc phụ thuộc vào một số ít trung gian. Điều này nhanh chóng tạo ra các vấn đề về quản trị.

Nếu builder giữ quỹ cứu hộ, ai là người ủy quyền giữ quỹ? Ai đặt phần thưởng? Điều gì ngăn chặn tống tiền hoặc đòi tiền chuộc? Nếu builder ở nước ngoài, ẩn danh hoặc hoạt động trong một khu vực pháp lý yếu, thì sao?

Trường hợp của Makina minh họa rõ vấn đề này. Quỹ nằm trong kho của builder, nhưng không có SLA công khai, phần thưởng đã định trước hoặc cơ chế rõ ràng để hoàn trả quỹ cho Makina hoặc người dùng của nó.

Builder có thể tự nguyện hoàn trả quỹ, thương lượng phần thưởng, đòi phí cao hơn tiêu chuẩn ngành, hoặc từ chối hoàn trả hoàn toàn.

Định tuyến riêng tư làm vấn đề tồi tệ hơn

Một bài báo học thuật năm 2025 có tiêu đề “Sandwiched and Silent” đã ghi nhận việc định tuyến riêng tư rộng rãi các giao dịch và phát hiện rằng nhiều nạn nhân di chuyển sang các kênh riêng sau khi bị sandwiched bởi các bot MEV.

Tuy nhiên, định tuyến riêng tư không loại bỏ MEV, mà chỉ chuyển nó từ mempool công cộng sang các kênh sắp xếp riêng do builder và relay kiểm soát.

Đối với các giao thức, điều này có nghĩa là các vụ cứu hộ trong mempool công cộng trở nên ít đáng tin cậy hơn vì các giao dịch khai thác ngày càng đi qua các kênh riêng chỉ có thể truy cập bởi một số builder nhất định.

Nỗ lực làm dịu đi hỗn loạn

Safe Harbor là một khung pháp lý do SEAL phát triển, nhằm thay thế mô hình “builder MEV như người giữ hộ tình cờ” bằng các phản ứng viên được ủy quyền, SLA rõ ràng và các động lực giới hạn.

SEAL mô tả Safe Harbor như một khung pháp lý và kỹ thuật cho phép các giao thức ủy quyền trước cho các white hat can thiệp trong các vụ khai thác đang diễn ra.

Quy tắc vận hành cốt lõi là quỹ cứu hộ phải được gửi đến các địa chỉ phục hồi chính thức trong vòng 72 giờ, với phần thưởng đã định trước và có thể thực thi.

SEAL cho biết Safe Harbor được thúc đẩy bởi vụ hack Nomad, nơi các white hat sẵn sàng giúp đỡ nhưng bị hạn chế bởi sự mơ hồ pháp lý về việc có thể truy tố việc hoàn trả quỹ như truy cập trái phép máy tính hay không.

Safe Harbor loại bỏ sự mơ hồ đó bằng cách cho phép các giao thức ủy quyền trước việc can thiệp và đặt ra các điều khoản rõ ràng. SEAL tuyên bố Safe Harbor đã bảo vệ hơn $16 tỷ đô la trên các giao thức lớn, bao gồm một số DEX, Pendle, các giải pháp layer-2 nhất định, và zkSync.

Immunefi, nền tảng thưởng lỗi, đã vận hành Safe Harbor với các điều khoản nghiêm ngặt hơn.

Immunefi mô tả Safe Harbor như một khung do SEAL phát triển, chuyển hướng quỹ đến một vault do giao thức kiểm soát 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 ghi rõ: “Bạn có 6 giờ để chuyển quỹ trở lại.”

Không tuân thủ trong vòng sáu giờ là vi phạm trọng yếu. Điều này nhanh gấp bốn lần so với yêu cầu cơ bản 72 giờ của SEAL.

Safe Harbor không loại bỏ hoàn toàn sự phụ thuộc vào hạ tầng MEV. Thay vào đó, nó cố gắng chính thức hóa nó.

Nếu builder đứng trước khai thác và giao thức đã áp dụng Safe Harbor, builder dự kiến sẽ nhận diện sự can thiệp là được ủy quyền và chuyển quỹ đến địa chỉ phục hồi do giao thức chỉ định trong thời hạn SLA.

Nhưng điều đó giả định các builder theo dõi các danh sách đăng ký 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ệ người dùng có thể phục hồi trong một vụ khai thác có thể được mô hình hóa như sau: kỳ vọng phục hồi bằng xác suất can thiệp nhân với (1 trừ phần thưởng), nhân với (1 trừ tỷ lệ thất bại hoặc rò rỉ).

Safe Harbor nhằm tăng khả năng can thiệp bằng cách giảm sự mơ hồ pháp lý và giới hạn phần thưởng trước.

Trong trường hợp cơ bản, việc áp dụng Safe Harbor sẽ tăng trong 12 tháng tới. Nhiều giao thức hơn đang thêm các điều khoản Safe Harbor vào khung quản trị của họ, và nhiều white hat hơn đang đăng ký làm phản ứng viên được ủy quyền.

Xác suất can thiệp tăng lên vì các phản ứng viên có rõ ràng pháp lý và các điều khoản phần thưởng cố định. Tỷ lệ phục hồi sẽ 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, như khoảng thời gian 6 giờ của Immunefi.

Trong kịch bản lạc quan, lớp cứu hộ chuyên nghiệp hơn. Các giao thức xây dựng các địa chỉ vault chặt chẽ, rút ngắn SLA xuống còn một chữ số giờ, và thương lượng trước các lịch trình phần thưởng với các nhóm white hat đã biết.

Các builder tích hợp danh sách đăng ký Safe Harbor vào thuật toán sắp xếp giao dịch của họ, tự động chuyển hướng quỹ cứu hộ đến các địa chỉ chỉ định mà không cần can thiệp thủ công.

Trong kịch bản bi quan, phụ thuộc vào builder trở nên cứng nhắc hơn. Các kênh đặt hàng riêng tư và sự tập trung relay làm cho các vụ cứu hộ ít minh bạch hơn và mang tính oligopol hơn. Các giao thức chưa áp dụng Safe Harbor sẽ phải thương lượng với builder sau khi sự cố xảy ra, mà không có đòn bẩy hoặc SLA rõ ràng.

Quản trị trở nên phụ thuộc vào các trung gian giữ quỹ và đặt điều khoản một chiều.