Thiên nga đen tái diễn: Vòng lặp 5 năm của lỗ hổng oracle

Một đợt bán tháo trị giá 60 triệu đô la đã khiến 19.3 tỷ đô la vốn hóa thị trường bốc hơi.

Tác giả: YQ

Biên dịch và tổng hợp: Saoirse, Foresight News

(Nội dung gốc đã được điều chỉnh và rút gọn)

Từ ngày 10 đến 11 tháng 10 năm 2025, một đợt bán tháo trị giá 60 triệu đô la đã khiến 19.3 tỷ đô la vốn hóa thị trường bốc hơi. Điều này không xuất phát từ sự sụp đổ của thị trường, cũng không phải do các vị thế hợp pháp bị thiệt hại dẫn đến chuỗi gọi bổ sung ký quỹ, mà là do sự cố của oracle.

Đây không phải là chuyện mới. Kể từ tháng 2 năm 2020, cùng một mô hình tấn công đã được khai thác thành công, gây thiệt hại hàng trăm triệu đô la cho ngành trong hàng chục sự kiện. Cuộc tấn công vào tháng 10 năm 2025 có quy mô lớn gấp 160 lần vụ tấn công oracle lớn nhất trước đó – không phải vì công nghệ phức tạp hơn, mà do hệ thống cơ sở hạ tầng khi mở rộng quy mô vẫn giữ nguyên lỗ hổng cơ bản.

Năm năm bài học đau đớn, nhưng vẫn bị bỏ qua. Bản phân tích này sẽ tìm hiểu nguyên nhân của vấn đề.

2020-2022: “Kịch bản cố định” của các cuộc tấn công oracle

Trước khi phân tích sự kiện tháng 10 năm 2025, cần làm rõ một điều: những tình huống tương tự đã từng xảy ra.

Tháng 2 năm 2020: Sự kiện bZx (thiệt hại 350,000 đô la + 630,000 đô la)

Sử dụng oracle nguồn đơn, kẻ tấn công đã thao túng giá WBTC trên nền tảng Uniswap thông qua flash loan, chuyển 14.6% tổng nguồn cung token này, từ đó thao túng dữ liệu giá mà bZx hoàn toàn phụ thuộc.

Tháng 10 năm 2020: Sự kiện Harvest Finance (24 triệu đô la bị đánh cắp, gây ra làn sóng rút vốn 570 triệu đô la)

Chỉ trong 7 phút, kẻ tấn công sử dụng flash loan 50 triệu đô la để thao túng giá stablecoin trên nền tảng Curve, không chỉ khiến tiền bị đánh cắp mà còn làm sụp đổ hạ tầng và dòng thanh khoản rút đi, tác động vượt xa số tiền bị đánh cắp ban đầu.

Tháng 11 năm 2020: Sự kiện Compound (89 triệu đô la tài sản bị thanh lý)

Giá stablecoin DAI trên sàn Coinbase Pro tăng vọt lên 1.30 đô la, trong khi các sàn khác không có hiện tượng này. Do oracle của Compound lấy giá từ Coinbase, người dùng bị thanh lý cưỡng chế chỉ trong 1 giờ do giá bất thường trên sàn này. Khi đó chỉ cần 100,000 đô la là có thể thao túng sổ lệnh có độ sâu 300,000 đô la.

Tháng 10 năm 2022: Sự kiện Mango Markets (thiệt hại 117 triệu đô la)

Kẻ tấn công dùng 5 triệu đô la ban đầu để đẩy giá token MNGO trên nhiều nền tảng tăng 2394%, sau đó vay 117 triệu đô la bằng tài sản thế chấp bị định giá quá cao, và sử dụng token quản trị bị đánh cắp để tự bỏ phiếu, lừa lấy 47 triệu đô la “tiền thưởng lỗ hổng”. Đây là lần đầu tiên Ủy ban Giao dịch Hàng hóa Tương lai Hoa Kỳ (CFTC) thực hiện hành động pháp lý đối với hành vi thao túng oracle.

Tất cả các cuộc tấn công đều tuân theo cùng một quy trình:

1. Xác định sự phụ thuộc của oracle vào “nguồn dữ liệu có thể thao túng”;
2. Tính toán xác minh: chi phí thao túng < giá trị có thể rút;
3. Thực hiện thao túng;
4. Rút lợi nhuận và rời khỏi thị trường.

Trong giai đoạn 2020-2022, 41 cuộc tấn công thao túng oracle đã khiến 403.2 triệu đô la bị đánh cắp. Tuy nhiên, phản ứng của ngành lại rời rạc, chậm chạp và không triệt để – phần lớn nền tảng vẫn sử dụng oracle dựa trên giá spot với mức dự phòng thấp.

Sau đó, thảm họa tháng 10 năm 2025 đã xảy ra.

Phân tích lỗ hổng “10.11”

Vào lúc 5:43 sáng ngày 10 tháng 10 năm 2025, đợt bán tháo tập trung 60 triệu đô la USDe đã kích hoạt một chuỗi phản ứng chết người:

Bán tháo spot 60 triệu đô la → oracle giảm định giá tài sản thế chấp (wBETH, BNSOL, USDe) → thanh lý hàng loạt → cơ sở hạ tầng quá tải → khoảng trống thanh khoản → 19.3 tỷ đô la vốn hóa thị trường bốc hơi

Đây không phải là thất bại của một nền tảng đơn lẻ, mà là sự phơi bày lỗ hổng tồn tại lâu dài trong toàn ngành – dù đã trả giá đắt trong 5 năm, những lỗ hổng này vẫn chưa được khắc phục:

1. Quá phụ thuộc vào giá spot

Mặc dù mọi cuộc tấn công lớn kể từ năm 2020 đều khai thác lỗ hổng “giá spot có thể bị thao túng”, phần lớn nền tảng vẫn sử dụng thiết kế oracle dựa trên giá spot. Ngành biết rõ rủi ro thao túng giá spot, cũng biết “giá trung bình trọng số theo thời gian (TWAP)” và “oracle đa nguồn” có thể bảo vệ tốt hơn, nhưng vẫn chưa thể triển khai triệt để các giải pháp này.

Gốc rễ nằm ở chỗ: “Tốc độ và độ nhạy” trước khi trở thành lỗ hổng đều được coi là ưu điểm. Cập nhật giá theo thời gian thực có vẻ chính xác hơn – cho đến khi có ai đó thao túng nó.

2. Rủi ro tập trung hóa

Các sàn giao dịch chiếm ưu thế sẽ tạo ra “điểm lỗi đơn”: bZx phụ thuộc vào Uniswap, Compound phụ thuộc vào Coinbase, các nền tảng tháng 1 và tháng 10 năm 2025 phụ thuộc vào sổ lệnh của chính mình, về bản chất đều là cùng một vấn đề – nền tảng thay đổi, nhưng lỗ hổng vẫn còn.

Khi một sàn giao dịch chiếm ưu thế về khối lượng giao dịch, việc lấy nó làm nguồn dữ liệu chính cho oracle có vẻ hợp lý. Nhưng rủi ro tập trung trong nguồn cấp giá cũng giống như mọi rủi ro tập trung khác: trước khi bị khai thác, mọi thứ đều có vẻ bình thường.

3. Sai lệch giả định về cơ sở hạ tầng

Hệ thống được thiết kế cho “thị trường bình thường” sẽ thất bại thảm hại khi gặp áp lực. Harvest Finance năm 2020 đã chứng minh điều này, nhưng sự kiện tháng 10 năm 2025 cho thấy ngành vẫn “thiết kế hệ thống theo điều kiện bình thường và hy vọng sự kiện áp lực sẽ không bao giờ xảy ra”.

Nhưng “hy vọng” không phải là chiến lược đối phó.

4. Nghịch lý minh bạch

Công bố các giải pháp cải tiến kỹ thuật lại tạo ra cửa sổ tấn công. Khoảng thời gian “công bố trước 8 ngày, sau đó mới triển khai” đối với cập nhật thuật toán oracle đã cung cấp cho các hacker chuyên nghiệp một lộ trình và thời gian rõ ràng – họ biết chính xác khi nào nên tấn công và khai thác lỗ hổng nào.

Đây là “một kiểu thất bại mới của vấn đề cũ”: các cuộc tấn công trước đây khai thác “lỗ hổng đã tồn tại”, còn cuộc tấn công tháng 10 năm 2025 khai thác “giai đoạn chuyển đổi thuật toán oracle” – lỗ hổng này chỉ tồn tại vì giải pháp cải tiến được công bố trước.

Giải pháp phá vỡ thế bế tắc

Biện pháp cải tiến tức thời

1. Thiết kế oracle lai

Kết hợp nhiều nguồn giá và bổ sung kiểm tra hợp lý thực sự hiệu quả:

• Giá từ sàn giao dịch tập trung (CEX) (trọng số theo khối lượng giao dịch liên sàn, chiếm 40%);
• Giá từ sàn giao dịch phi tập trung (DEX) (chỉ chọn các pool có thanh khoản cao, chiếm 30%);
• Bằng chứng dự trữ on-chain (chiếm 20%);
• Tỷ lệ chuyển đổi của tài sản wrapped (chiếm 10%).

Điểm mấu chốt là “tính độc lập của nguồn dữ liệu”: nếu có thể thao túng tất cả nguồn dữ liệu với chi phí hợp lý, thì “đa nguồn” về bản chất vẫn là “đơn nguồn”.

2. Điều chỉnh trọng số động

Điều chỉnh độ nhạy của oracle theo tình hình thị trường:

• Giai đoạn biến động bình thường: sử dụng trọng số tiêu chuẩn;
• Giai đoạn biến động cao: kéo dài cửa sổ tính TWAP, giảm ảnh hưởng của giá spot;
• Giai đoạn biến động cực đoan: kích hoạt cơ chế ngắt mạch, khởi động kiểm tra hợp lý.

Sự kiện Compound năm 2020 đã chứng minh: đôi khi “giá đúng” trên một sàn lại là “giá sai” đối với toàn thị trường. Oracle cần có trí tuệ để nhận diện sự sai lệch này.

3. Cơ chế ngắt mạch

Tạm dừng thanh lý khi giá biến động cực đoan – mục đích không phải ngăn “giảm đòn bẩy hợp lý”, mà là phân biệt “hành vi thao túng” với “tình hình thị trường thực tế”:

• Nếu giá trên nhiều nền tảng hội tụ trong vài phút: khả năng cao là biến động thị trường thực;
• Nếu giá chỉ bất thường trên một nền tảng: khả năng cao là thao túng;
• Nếu cơ sở hạ tầng quá tải: tạm dừng thanh lý cho đến khi phục hồi năng lực.

Mục tiêu cốt lõi không phải “cấm mọi thanh lý”, mà là “tránh chuỗi thanh lý do giá bị thao túng”.

4. Mở rộng cơ sở hạ tầng

Thiết kế hệ thống với “công suất bình thường gấp 100 lần” – vì phản ứng dây chuyền sẽ tạo ra tải trọng theo cấp số nhân:

• Xây dựng cơ sở hạ tầng riêng cho nguồn cấp giá;
• Triển khai engine thanh lý độc lập;
• Thiết lập giới hạn tốc độ yêu cầu cho từng địa chỉ;
• Xây dựng giao thức “giảm tải mượt mà” (ưu tiên chức năng cốt lõi khi tải quá cao).

Nếu hệ thống không chịu nổi tải của phản ứng dây chuyền, thảm họa sẽ càng trầm trọng. Đây là yêu cầu thiết kế bắt buộc, không phải tùy chọn tối ưu hóa.

Giải pháp lâu dài

1. Mạng lưới oracle phi tập trung

Sử dụng các giải pháp oracle đã trưởng thành (như Chainlink, Pyth, UMA), các giải pháp này tích hợp khả năng chống thao túng bằng cách tổng hợp dữ liệu từ nhiều nguồn. Chúng không hoàn hảo, nhưng tốt hơn nhiều so với oracle dựa vào giá spot “bị tấn công mỗi 18 tháng”.

bZx đã tích hợp Chainlink sau vụ tấn công năm 2020 và kể từ đó không còn bị thao túng oracle – điều này không phải ngẫu nhiên.

2. Tích hợp bằng chứng dự trữ

Đối với tài sản wrapped và stablecoin, cần xác minh giá trị tài sản thế chấp trên chuỗi. Ví dụ, định giá USDe nên dựa trên “dự trữ có thể xác minh”, thay vì “biến động sổ lệnh”. Công nghệ liên quan đã có, chỉ còn chậm ở khâu triển khai thực tế.

3. Thanh lý theo từng giai đoạn

Tránh mở rộng phản ứng dây chuyền bằng cách thanh lý theo từng giai đoạn:

• Ngưỡng đầu tiên: gửi cảnh báo, cho người dùng thời gian bổ sung tài sản thế chấp;
• Ngưỡng thứ hai: thanh lý một phần (25%);
• Ngưỡng thứ ba: thanh lý quy mô lớn hơn (50%);
• Ngưỡng cuối cùng: thanh lý hoàn toàn.

Cách này vừa cho người dùng thời gian ứng phó, vừa giảm tác động của “thanh lý đồng loạt quy mô lớn” lên hệ thống.

4. Giám sát kiểm toán thời gian thực

Giám sát hành vi thao túng oracle theo thời gian thực:

• Chênh lệch giá giữa các nền tảng;
• Khối lượng giao dịch bất thường ở các cặp thanh khoản thấp;
• Tăng trưởng nhanh quy mô vị thế trước khi oracle cập nhật;
• So khớp mẫu với các đặc điểm tấn công đã biết.

Cuộc tấn công tháng 10 năm 2025 lẽ ra phải có tín hiệu cảnh báo: bán tháo 60 triệu đô la USDe lúc 5:43 sáng, giao dịch bất thường như vậy phải kích hoạt báo động. Nếu hệ thống giám sát không phát hiện, chứng tỏ nó có thiếu sót nghiêm trọng.

Kết luận: Cảnh báo 19 tỷ đô la

Chuỗi thanh lý ngày 10-11 tháng 10 năm 2025 không phải do “quá mức đòn bẩy” hay “hoảng loạn thị trường”, mà là “thất bại thiết kế oracle ở quy mô lớn”. Việc thao túng thị trường trị giá 60 triệu đô la dẫn đến thiệt hại 19.3 tỷ đô la, cốt lõi là hệ thống nguồn cấp giá không thể phân biệt “hành vi thao túng” với “phát hiện giá hợp pháp”.

Nhưng đây không phải là vấn đề mới – những gì đã phá hủy bZx tháng 2 năm 2020, Harvest tháng 10 năm 2020, Compound tháng 11 năm 2020, Mango Markets tháng 10 năm 2022 đều là cùng một loại lỗi.

Năm năm qua, ngành đã học cùng một bài học năm lần, nhưng mỗi lần cái giá lại đắt hơn:

• 2020: Một số giao thức rút ra bài học, thực hiện sửa chữa;
• 2022: Cơ quan quản lý vào cuộc, bắt đầu thực thi pháp luật;
• 2025: Toàn thị trường trả “học phí” 19.3 tỷ đô la.

Bây giờ chỉ còn một câu hỏi: Liệu chúng ta cuối cùng có nhớ bài học này không?

Mọi nền tảng xử lý vị thế đòn bẩy đều phải đối mặt với các câu hỏi sau:

• Oracle của chúng ta có thể chống lại các vector tấn công đã được xác định rõ trong giai đoạn 2020-2022 không?
• Cơ sở hạ tầng của chúng ta có thể đối phó với các kịch bản thanh lý dây chuyền đã từng xảy ra không?
• Chúng ta đã cân bằng hợp lý giữa “độ nhạy” và “tính ổn định” chưa?
• Chúng ta có đang lặp lại những sai lầm từng khiến ngành mất hàng trăm triệu đô la không?

Lịch sử năm năm đã chứng minh: thao túng oracle không phải là “rủi ro giả định” hay “trường hợp ngoại lệ”, mà là một chiến lược tấn công “có ghi nhận, có thể lặp lại, lợi nhuận cao”, quy mô sẽ tăng cùng với sự phát triển của thị trường.

Sự kiện tháng 10 năm 2025 cho thấy, khi những bài học này bị bỏ qua ở quy mô tổ chức, thảm họa sẽ xảy ra như thế nào. Cuộc tấn công này không phức tạp, cũng không mới – chỉ là cùng một thao tác, trong “giai đoạn lỗ hổng đã biết”, được thực hiện trên hệ thống quy mô lớn hơn.

Oracle là nền tảng của cả hệ thống. Khi nền tảng nứt vỡ, mọi thứ phía trên đều sụp đổ. Từ tháng 2 năm 2020, chúng ta đã hiểu điều này và đã

chi hàng tỷ đô la để xác nhận lại bài học này nhiều lần. Bây giờ chỉ còn một câu hỏi: liệu sự kiện đau thương tháng 10 năm 2025 này có đủ để chúng ta cuối cùng biến bài học đã biết thành hành động?

Trong thị trường ngày nay với sự kết nối cao, thiết kế oracle không chỉ đơn giản là “nguồn cấp dữ liệu” – nó liên quan đến sự ổn định của cả hệ thống. Nếu thiết kế sai, 60 triệu đô la có thể phá hủy 19 tỷ đô la giá trị.

Nếu vẫn tiếp tục lặp lại sai lầm, không phải vì chúng ta không học được từ lịch sử, mà chỉ là cái giá của việc lặp lại sai lầm ngày càng đắt đỏ hơn.

Bản phân tích này dựa trên dữ liệu thị trường công khai, tuyên bố của nền tảng và nghiên cứu các trường hợp thao túng oracle trong 5 năm qua.