Sự sụt giảm: Lỗ hổng Oracle và bài kiểm tra DeFi trị giá hàng tỷ đô la

Tác giả gốc: YQ

Bản dịch gốc: TechFlow

Vào ngày 10-11 tháng 10 năm 2025, một đợt bán tháo trên thị trường trị giá 60 triệu đô la đã phá hủy 19,3 tỷ đô la giá trị. Điều này không phải do sự sụp đổ của thị trường hay việc thanh lý hàng loạt các vị thế thực sự bị thiệt hại, mà là do lỗi của một hệ thống Oracle.

Đây không phải là điều mới mẻ. Mô hình tấn công tương tự đã bị khai thác thành công nhiều lần kể từ tháng 2 năm 2020, dẫn đến hàng chục sự cố trên toàn ngành với tổng thiệt hại lên tới hàng trăm triệu đô la. Tuy nhiên, sự cố tháng 10 năm 2025 đã khuếch đại quy mô của cuộc tấn công oracle lớn nhất trước đó lên 160 lần—không phải do sự tinh vi về mặt kỹ thuật, mà là do sự mở rộng của hệ thống cơ bản trong khi vẫn duy trì cùng một lỗ hổng cơ bản.

Trong năm năm qua, chúng ta đã phải trả giá đắt, nhưng vẫn chưa rút ra được bài học. Bài viết này sẽ phân tích những lý do.

Thế tiến thoái lưỡng nan của Oracle: Độ nhạy so với Độ ổn định

Mọi nền tảng đều phải đối mặt với một thách thức cơ bản khi sử dụng đòn bẩy: làm thế nào để định giá tài sản thế chấp chính xác đồng thời ngăn chặn thao túng giá?

• Quá nhạy cảm → dễ bị tấn công thao túng
• Quá ổn định → không thể phản ánh kịp thời những tổn thất thực tế

Sự kiện tháng 10 năm 2025 đã chọn "Độ nhạy". Oracle đã theo dõi chính xác giá thị trường giao ngay, và khi 60 triệu đô la tài sản bị bán tháo, Oracle đã điều chỉnh giá thế chấp xuống theo thời gian thực, kích hoạt thanh lý hàng loạt. Hệ thống hoạt động chính xác như thiết kế.

Tuy nhiên, thiết kế này lại là một thảm họa.

Một mô hình đã bị bỏ qua trong năm năm

Trước khi phân tích các sự kiện diễn ra vào tháng 10 năm 2025, chúng ta cần hiểu rằng đây không phải là lần đầu tiên điều này xảy ra.

Các giai đoạn trước (2020-2022)

Tháng 2 năm 2020: bZx (350.000 đô la + 630.000 đô la bị mất) sử dụng oracle nguồn đơn. Các khoản vay nhanh thao túng giá WBTC trên Uniswap. 14,6% tổng nguồn cung đã được chuyển để thao túng dữ liệu giá mà bZx dựa vào.

Tháng 10 năm 2020: Harvest Finance (24 triệu đô la bị đánh cắp, 570 triệu đô la bị rút) đã thao túng giá stablecoin của Curve bằng khoản vay nhanh 50 triệu đô la chỉ trong bảy phút. Điều này đã gây ra sự sụp đổ cơ sở hạ tầng và rút tiền ồ ạt, dẫn đến thiệt hại vượt xa số tiền bị đánh cắp ban đầu.

Tháng 11 năm 2020: Compound (89 triệu đô la bị thanh lý) chứng kiến DAI trên Coinbase Pro tăng vọt lên 1,30 đô la, một hiện tượng chưa từng thấy trên sàn giao dịch này. Oracle của Compound, vốn sử dụng giá của Coinbase làm chuẩn mực, đã dẫn đến việc người dùng bị thanh lý do giá biến động bất thường trong thời gian ngắn. Việc thao túng cần 100.000 đô la để tận dụng một sổ lệnh có độ sâu 300.000 đô la.

Tháng 10 năm 2022: Mango Markets (lỗ 117 triệu đô la) đã tận dụng nguồn vốn ban đầu 5 triệu đô la để đẩy giá token MNGO lên 2.394% trên nhiều nền tảng giao dịch. Sau đó, công ty này đã vay 117 triệu đô la với mức thế chấp cao và sử dụng số token quản trị bị đánh cắp để bỏ phiếu cho chính mình, kiếm được 47 triệu đô la tiền "tiền thưởng lỗi". Đây là hành động thực thi đầu tiên của Ủy ban Giao dịch Hàng hóa Tương lai Hoa Kỳ (CFTC) chống lại hành vi thao túng oracle.

Điểm chung

Mỗi cuộc tấn công đều tuân theo cùng một logic:

1. Xác định các nguồn dữ liệu bị thao túng mà oracle dựa vào
2. Tính toán: Chi phí thao tác < Giá trị có thể trích xuất
3. Thực hiện cuộc tấn công
4. Lợi nhuận

2020-2022: 41 cuộc tấn công thao túng Oracle gây ra thiệt hại 403,2 triệu đô la.

Phản hồi của ngành: Phản hồi còn rời rạc, chậm chạp và chưa đầy đủ. Hầu hết các nền tảng vẫn đang sử dụng các oracle cục bộ với độ dự phòng không đủ.

Sau đó, sự kiện tháng 10 năm 2025 đã xảy ra.

Giải phẫu của một lỗi Oracle: Phiên bản 2025

Ngày 10 tháng 10 năm 2025, 5:43 sáng: 60 triệu đô la USDe được bán ra thị trường giao ngay.

Trong một hệ thống oracle được thiết kế hợp lý: nhiều nguồn dữ liệu độc lập sẽ hấp thụ cú sốc và tác động sẽ ở mức tối thiểu.

Trong lời sấm truyền này: Thảm họa sẽ xảy ra.

Bán tháo giao ngay 60 triệu đô la → Oracles hạ giá tài sản thế chấp (wBETH, BNSOL, USDe) → Thanh lý hàng loạt được kích hoạt → Quá tải cơ sở hạ tầng → Khoảng trống thanh khoản → 19,3 tỷ đô la tài sản bốc hơi

Hiệu ứng khuếch đại

• Mango Markets (2022) : 5 triệu đô la bị thao túng → 117 triệu đô la bị rút (gấp 23 lần)
• Tháng 10 năm 2025 : 60 triệu đô la bị thao túng → 19,3 tỷ đô la bị phá hủy (322 lần)

Điều này không phải do sự gia tăng tính phức tạp về mặt công nghệ, mà là do những lỗ hổng tương tự đang được phóng đại lên quy mô tổ chức.

Vấn đề phân phối trọng lượng

Oracle này phụ thuộc rất nhiều vào giá giao ngay từ các sàn giao dịch lớn. Khi một sàn giao dịch duy nhất thống trị khối lượng giao dịch:

• Khối lượng giao dịch cao dường như cho thấy việc phát hiện giá đáng tin cậy (có vẻ hợp lý)
• Sự tập trung hóa làm tăng nguy cơ bị thao túng (gót chân Achilles)
• Một mức giá nội bộ duy nhất tạo ra một chu kỳ tự duy trì (làm trầm trọng thêm vấn đề)

Bình luận của một nhà phân tích cho thấy sai sót trong logic này: "Vì [sàn giao dịch] có khối lượng giao dịch lớn nhất đối với usde/bnsol/wbeth, theo phân bổ trọng số của oracle, nó phải đề cập đến giá giao ngay."

Bản năng này - tin vào thị trường lớn nhất - đã dẫn đến hàng tỷ đô la thua lỗ trong năm năm. Khối lượng giao dịch tập trung không phải là bằng chứng cho thấy giá chính xác; nó báo hiệu cơ hội thao túng.

Cửa sổ lỗ hổng được lên lịch

Bản cập nhật phương thức Oracle được công bố tám ngày trước khi triển khai. Điều này đã mang lại cho kẻ tấn công:

• Phụ thuộc Oracle
• Thời gian chuyển đổi có thể dự đoán được
• Tám ngày chuẩn bị

Trong khi các cuộc tấn công Oracle trước đây khai thác các lỗ hổng hiện có, thì cuộc tấn công vào tháng 10 năm 2025 đã khai thác một lỗ hổng trong quá trình chuyển đổi phương thức Oracle—một lỗ hổng chỉ tồn tại vì cải tiến được công bố sớm.

Kiểm tra cách ly địa điểm

Bằng chứng rõ ràng nhất cho thấy sự cố này là do lỗi của Oracle chứ không phải do mất tài sản:

• Các sàn giao dịch chính : Giá USDe là 0,6567 đô la, giá wBETH là 430 đô la
• Các nền tảng giao dịch khác : độ lệch giá nhỏ hơn 30 điểm cơ bản
• Nhóm thanh khoản trên chuỗi : tác động tối thiểu

Như Guy của Ethena đã lưu ý: “Trong sự kiện này, hơn 9 tỷ đô la tiền thế chấp stablecoin vẫn có thể được rút ngay lập tức.”

Giá cả biến động mạnh trên các sàn giao dịch mà Oracle lấy dữ liệu, trong khi vẫn ổn định ở những nơi khác. Oracle báo cáo giá bị thao túng, dẫn đến việc thanh lý dựa trên mức giá không tồn tại ở nơi khác trên thị trường.

Đây chính xác là mô hình tương tự như sự cố Compound năm 2020: thao túng giá tại các địa điểm giao dịch riêng lẻ được các nhà tiên tri ghi nhận, gây ra thiệt hại mang tính hệ thống.

Hiệu ứng lan tỏa của cơ sở hạ tầng

Nhà phân tích agintender chỉ ra cơ chế khuếch đại:

“Việc thanh lý liên tục khiến máy chủ bị quá tải với hàng triệu yêu cầu. Các nhà tạo lập thị trường không thể đấu giá kịp thời, tạo ra khoảng trống thanh khoản.”

Đây chính xác là phiên bản mở rộng của sự cố Harvest Finance năm 2020. Cuộc tấn công đã gây ra tình trạng thanh lý nhanh hơn khả năng xử lý của cơ sở hạ tầng, các nhà tạo lập thị trường không thể phản ứng, thanh khoản biến mất và phản ứng dây chuyền tự củng cố.

Sau sự sụp đổ cơ sở hạ tầng của Harvest Finance vào tháng 10 năm 2020 (TVL giảm từ 1 tỷ đô la xuống còn 599 triệu đô la khi người dùng rút tiền), bài học rút ra rất rõ ràng: các hệ thống oracle phải tính đến năng lực cơ sở hạ tầng trong các sự kiện căng thẳng.

Tuy nhiên, các sự kiện diễn ra vào tháng 10 năm 2025 đã chứng minh rằng chúng ta vẫn chưa rút ra được bài học.

Sự đánh đổi về độ nhạy: Hai cách tiếp cận, một thảm họa

Guy từ Ethena đã nêu rõ thách thức thiết kế cốt lõi: hệ thống tiên tri phải phân biệt giữa các sai lệch tạm thời ngắn hạn (nhiễu thị trường) và suy giảm tài sản dài hạn (tổn thất thực sự).

Tháng 10 năm 2025 đưa ra hai phản ứng có thể xảy ra:

Phương pháp có độ nhạy cao (trao đổi không thành công)

• Theo dõi giá giao ngay theo thời gian thực
• Phản ứng nhanh với những thay đổi của thị trường
• Kết quả : hiệu ứng lan tỏa trị giá 19,3 tỷ đô la

Đây là cách tiếp cận của bZx/Harvest: tin tưởng vào thị trường giao ngay, chỉ để bị phá hủy bởi sự thao túng.

Phương pháp ổn định cao (Nền tảng DeFi tồn tại)

• USDe được viết cứng = USDT
• Bỏ qua tiếng ồn thị trường ngắn hạn
• Kết quả : Không thanh lý

Đây là sự điều chỉnh quá mức, tốt hơn là thất bại, nhưng vẫn chưa phải là tối ưu.

Ngành công nghiệp có năm năm để phát triển một giải pháp tinh tế. Chúng tôi không tìm thấy giải pháp tối ưu cũng không có giải pháp chấp nhận được—chúng tôi rơi vào hai thái cực, và quy mô tổ chức cuối cùng đã chọn giải pháp thảm khốc.

Định lý tấn công Oracle: Đã được chứng minh bằng thực nghiệm

Định lý : Trong bất kỳ hệ đòn bẩy nào, nếu các điều kiện sau được đáp ứng:

1. Giá Oracle phụ thuộc rất nhiều vào thị trường giao ngay có thể thao túng
2. Điều kiện kích hoạt thanh lý là xác định
3. Cơ sở hạ tầng có hạn chế về năng lực

Sau đó: chi phí thao tác < giá trị có thể được trích xuất thông qua phản ứng dây chuyền

Bằng chứng được xác minh bằng thực hành nhiều lần:

• bZx (tháng 2 năm 2020) : Thao túng Uniswap → 350.000 đô la + 630.000 đô la bị rút
• Harvest (tháng 10 năm 2020) : Thao túng đường cong → 24 triệu đô la bị đánh cắp + gây ra cuộc rút tiền ngân hàng 570 triệu đô la
• Compound (tháng 11 năm 2020) : Thao túng Coinbase → 89 triệu đô la bị thanh lý
• Mango (tháng 10 năm 2022) : Thao túng đa nền tảng → Rút 117 triệu đô la
• Tháng 10 năm 2025 : Thao túng sàn giao dịch lớn → Mất 19,3 tỷ đô la

Khi hệ thống mở rộng tuyến tính, quy mô thiệt hại tăng theo cấp số nhân. Chi phí thao túng gần như không đổi (được xác định bởi tính thanh khoản), nhưng giá trị có thể khai thác tăng lên khi tổng đòn bẩy trong hệ thống tăng lên.

Tháng 10 năm 2025 đã xác minh định lý này ở quy mô chưa từng có.

Nguyên tắc thiết kế Oracle: Những bài học chúng ta nên học

1. Xác minh đa nguồn

Đừng bao giờ dựa vào một mức giá giao dịch duy nhất, đặc biệt là mức giá từ chính sổ lệnh của sàn. Đây chính là bài học từ sự cố bZx vào tháng 2 năm 2020. Một thiết kế oracle hợp lý đòi hỏi:

Giá Oracle = trung bình có trọng số của nhiều nguồn dữ liệu khác nhau:

• Giá trên nhiều sàn giao dịch (40%)
• Nhóm thanh khoản trên chuỗi (30%)
• Tỷ lệ chuyển đổi tài sản bao bì (20%)
• Giá lịch sử theo thời gian (10%)

Phân phối trọng số không quan trọng bằng tính độc lập của nguồn dữ liệu. Nếu tất cả các nguồn dữ liệu có thể được xử lý đồng thời bằng vốn hợp lý, thì thực tế bạn chỉ có một nguồn dữ liệu, chứ không phải nhiều nguồn.

1. Độ nhạy thích ứng

Các nhà tiên tri nên điều chỉnh độ nhạy của mình dựa trên các điều kiện thị trường:

• Thị trường bình thường : nhạy cảm hơn với sự thay đổi giá
• Thị trường biến động : Tăng cường sự ổn định thông qua trọng số thời gian
• Biến động cực độ: Bộ ngắt mạch và Kiểm tra tính hợp lý

Hệ thống oracle giá trung bình theo thời gian (TWAP) đã được áp dụng rộng rãi sau các cuộc tấn công cho vay chớp nhoáng năm 2020, đặc biệt là để ngăn chặn việc thao túng một giao dịch duy nhất. Tuy nhiên, vào tháng 10 năm 2025, oracle đã phản hồi giá giao ngay theo thời gian thực, như thể chưa từng có sự cố nào như vậy xảy ra trong năm năm qua.

1. Khả năng phục hồi của cơ sở hạ tầng

Hệ thống oracle phải duy trì hoạt động trong suốt các sự kiện chuỗi:

• Cơ sở hạ tầng dữ liệu giá độc lập
• Khả năng hỗ trợ hàng triệu truy vấn đồng thời
• Cơ chế suy thoái nhẹ nhàng dưới tải trọng cao

Sự cố sụp đổ cơ sở hạ tầng Harvest Finance vào tháng 10 năm 2020 đã làm nổi bật tầm quan trọng của năng lực hệ thống trong điều kiện áp lực. Các phản ứng dây chuyền thanh lý tạo ra tải trọng tăng theo cấp số nhân. Cơ sở hạ tầng của bạn không chỉ phải xử lý đợt thanh lý đầu tiên mà còn phải xử lý đợt thanh lý thứ 1.000 khi các nhà tạo lập thị trường không thể theo kịp và người dùng hoảng loạn.

1. Minh bạch nhưng không có lỗ hổng

Khoảng thời gian 8 ngày giữa thông báo và triển khai đã tạo ra một hướng tấn công đã biết. Các phương pháp tiếp cận tốt hơn bao gồm:

• Thực hiện thay đổi ngay sau khi công bố
• Sử dụng bản cập nhật liên tục không có ngày cố định
• Lưu giữ hồ sơ kiểm toán nhưng tránh thời gian xem trước

Đây là một bài học mới, nhưng lại rất hợp lý từ góc độ lý thuyết trò chơi: Đừng bao giờ thông báo trước những thay đổi có thể khai thác . Những kẻ tấn công vào tháng 10 năm 2025 có tám ngày để lên kế hoạch, bố trí và chuẩn bị. Chúng biết chính xác khi nào lỗ hổng sẽ xuất hiện.

Tác động hệ thống: bài học chưa được rút ra

Đây không chỉ là sự thất bại của một nền tảng duy nhất, mà còn phơi bày những lỗ hổng lan rộng mà toàn bộ ngành vẫn chưa giải quyết được ngay cả sau năm năm đào tạo tốn kém:

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

Mặc dù lỗ hổng này đã bị khai thác trong mọi cuộc tấn công lớn kể từ năm 2020, hầu hết các nền tảng vẫn sử dụng thiết kế oracle chủ yếu tập trung vào giá giao ngay. Ngành công nghiệp này biết rằng giá giao ngay dễ bị thao túng, và giá trung bình theo thời gian (TWAP) cùng oracle đa nguồn cung cấp khả năng bảo vệ tốt hơn, nhưng việc triển khai vẫn chưa hoàn thiện.

Tốc độ và độ nhạy là những lợi thế trong điều kiện bình thường, nhưng lại trở thành điểm yếu chí mạng khi bị thao túng. Cập nhật giá theo thời gian thực có vẻ chính xác hơn cho đến khi có người thao túng chúng.

1. Rủi ro tập trung

Các sàn giao dịch thống trị trở thành điểm yếu duy nhất. Điều này thể hiện rõ qua việc bZx phụ thuộc vào Uniswap, Compound phụ thuộc vào Coinbase, và vào tháng 10 năm 2025, nền tảng này lại phụ thuộc vào sổ lệnh riêng của mình. Các sàn giao dịch có thể khác nhau, nhưng các lỗ hổng vẫn như cũ.

Khi một sàn giao dịch duy nhất chiếm phần lớn khối lượng giao dịch, việc sử dụng sàn giao dịch đó làm nguồn dữ liệu oracle chính có vẻ hợp lý. Tuy nhiên, rủi ro tập trung dữ liệu giá cũng giống như rủi ro tập trung trong bất kỳ hệ thống nào: nó có vẻ vô hại cho đến khi bị khai thác, nhưng một khi bị khai thác, hậu quả có thể rất nghiêm trọng.

1. Giả định về cơ sở hạ tầng

Các hệ thống được thiết kế cho thị trường bình thường sẽ hoàn toàn sụp đổ dưới áp lực. Harvest Finance đã chứng minh điều này vào năm 2020, và tháng 10 năm 2025 một lần nữa chứng minh điều đó. Chúng tôi vẫn đang thiết kế các hệ thống cho điều kiện bình thường và hy vọng rằng áp lực sẽ không bao giờ xảy ra.

Hy vọng không phải là một chiến lược.

1. Nghịch lý minh bạch

Việc công bố các cải tiến sẽ tạo ra một khoảng thời gian tấn công. Khoảng cách tám ngày giữa thông báo và việc triển khai thay đổi Oracle đã cung cấp cho kẻ tấn công một lộ trình và mốc thời gian rõ ràng. Chúng biết chính xác thời điểm phát động cuộc tấn công và cách khai thác lỗ hổng.

Đây là một chế độ lỗi mới, nhưng vấn đề về cơ bản vẫn chưa được giải quyết. Trong khi các cuộc tấn công Oracle trước đây khai thác các lỗ hổng hiện có, thì cuộc tấn công tháng 10 năm 2025 đã khai thác một lỗ hổng trong quá trình chuyển đổi phương thức Oracle - một lỗ hổng chỉ tồn tại do thay đổi được công bố sớm.

Hướng đi tiếp theo: Liệu lần này chúng ta đã thực sự học được bài học chưa?

Cải thiện ngay bây giờ

1. Thiết kế oracle lai kết hợp nhiều nguồn giá với các kiểm tra thực tế và hiệu quả:

• Giá trao đổi tập trung (được tính theo khối lượng giao dịch trao đổi)
• Giá trao đổi phi tập trung (chỉ dành cho các nhóm thanh khoản cao)
• Bằng chứng dự trữ trên chuỗi
• Giới hạn độ lệch trao đổi chéo

Mỗi nguồn dữ liệu phải độc lập với nhau. Nếu việc thao tác một nguồn dữ liệu ảnh hưởng đến các nguồn dữ liệu khác, sẽ không có sự trùng lặp.

1. Điều chỉnh trọng số động điều chỉnh độ nhạy của oracle theo điều kiện thị trường:

• Biến động bình thường: Trọng lượng chuẩn
• Biến động cao: Tăng cửa sổ TWAP để giảm tác động tại chỗ
• Biến động cực độ: Thanh lý bị tạm dừng chờ điều tra và hành động tiếp theo

Cuộc tấn công Compound đã chứng minh rằng đôi khi giá "chính xác" trên một sàn giao dịch duy nhất có thể sai lệch với toàn bộ thị trường. Oracle của bạn phải đủ thông minh để nhận ra điều này.

1. Các công cụ ngắt mạch sẽ tạm dừng thanh lý trong thời kỳ giá cả biến động cực độ — không phải để ngăn chặn việc giảm đòn bẩy hợp pháp, mà để phân biệt thao túng với thực tế thị trường:

• Nếu giá cả hội tụ trên khắp các địa điểm trong vòng vài phút: nó có thể là sự thật
• Nếu biến động giá chỉ giới hạn ở một địa điểm: Có thể xảy ra thao túng
• Nếu cơ sở hạ tầng quá tải: tạm dừng thanh lý cho đến khi công suất được khôi phục

Mục tiêu không phải là ngăn chặn mọi vụ thanh lý mà là ngăn chặn các vụ thanh lý hàng loạt do thao túng giá gây ra.

1. Việc mở rộng cơ sở hạ tầng được thiết kế để xử lý công suất hệ thống thông thường gấp 100 lần, vì phản ứng dây chuyền sẽ tạo ra mức tải này:

• Cơ sở hạ tầng dữ liệu giá độc lập
• Công cụ thanh lý độc lập
• Giới hạn tốc độ cho một địa chỉ duy nhất
• Giao thức suy thoái duyên dáng

Nếu hệ thống của bạn không thể xử lý tải trong phản ứng dây chuyền, nó sẽ khuếch đại phản ứng dây chuyền. Đây là yêu cầu thiết kế, không phải là tùy chọn tối ưu hóa.

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

1. Các 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, Python hoặc UMA, tổng hợp nhiều nguồn dữ liệu và có khả năng chống thao túng tích hợp. Các giải pháp này không hoàn hảo, nhưng vẫn tốt hơn so với việc dựa vào các oracle spot bị khai thác 18 tháng một lần.

bZx đã tích hợp Chainlink sau cuộc tấn công năm 2020. Họ không còn dễ bị tấn công thao túng Oracle nữa. Đây không phải là sự trùng hợp ngẫu nhiên.

1. Tích hợp Bằng chứng Dự trữ: Đối với tài sản được đóng gói và stablecoin, giá trị tài sản thế chấp được xác minh trên chuỗi. USDE nên được định giá dựa trên dự trữ có thể xác minh, chứ không phải động lực sổ lệnh. Công nghệ đã có, nhưng việc triển khai còn chậm.
2. Thanh lý dần dần ngăn chặn các phản ứng dây chuyền khuếch đại bằng cách thanh lý theo từng giai đoạn:

• Giai đoạn 1: Cảnh báo và thời gian để thêm tài sản thế chấp
• Giai đoạn 2: Thanh lý một phần (25%)
• Giai đoạn 3: Thanh lý lớn hơn (50%)
• Giai đoạn cuối cùng: Thanh lý hoàn toàn

Điều này giúp người dùng có thời gian phản hồi và giảm tác động của việc thanh lý đồng thời số lượng lớn lên hệ thống.

1. Giám sát kiểm tra thời gian thực về hành vi thao túng của Oracle:

• Độ lệch giá chéo
• Khối lượng giao dịch bất thường trên các cặp giao dịch có tính thanh khoản thấp
• Tăng nhanh kích thước vị thế trước khi cập nhật Oracle
• So khớp mẫu với các dấu hiệu tấn công đã biết

Vụ tấn công tháng 10 năm 2025 có lẽ đã phát ra những dấu hiệu cảnh báo. Ai đó bán 60 triệu đô la USDe lúc 5:43 sáng lẽ ra phải kích hoạt báo động. Nếu hệ thống giám sát của bạn không phát hiện ra những tín hiệu này, thì hệ thống giám sát của bạn đã không đủ mạnh.

Kết luận: Lời nhắc nhở về 19 tỷ đô la

Phản ứng dây chuyền thanh lý ngày 10-11 tháng 10 năm 2025 không phải do đòn bẩy quá mức hay sự hoảng loạn của thị trường, mà là do lỗi thiết kế hệ thống Oracle nghiêm trọng. 60 triệu đô la biến động thị trường đã bị khuếch đại thành thiệt hại 19,3 tỷ đô la do hệ thống dữ liệu giá không thể phân biệt giữa thao túng giá và phát hiện giá thực sự.

Nhưng đây không phải là một chế độ lỗi mới. Nó chính là chế độ lỗi đã phá hủy bZx vào tháng 2 năm 2020, Harvest vào tháng 10 năm 2020, Compound vào tháng 11 năm 2020 và Mango vào tháng 10 năm 2022.

Ngành công nghiệp đã học được bài học này năm lần, với chi phí ngày càng tăng:

• 2020 : Các giao thức riêng lẻ rút kinh nghiệm và triển khai các bản sửa lỗi
• 2022 : Các cơ quan quản lý rút kinh nghiệm và bắt đầu thực thi
• 2025 : Toàn bộ thị trường đã học được bài học của mình và phải trả học phí 19,3 tỷ đô la

Câu hỏi duy nhất là liệu chúng ta có học được bài học này hay không.

Mọi nền tảng xử lý các vị thế đòn bẩy hiện phải hỏi:

• Liệu các hệ thống tiên tri của chúng ta có đủ mạnh mẽ để bảo vệ chống lại các phương thức tấn công đã biết trong giai đoạn 2020-2022 không?
• Liệu cơ sở hạ tầng của chúng ta có thể ứng phó được với những tác động lan tỏa mà chúng ta đã chứng kiến không?
• Chúng ta đã đạt được sự cân bằng phù hợp giữa độ nhạy cảm và tính ổn định chưa?
• Liệu chúng ta có đang lặp lại những sai lầm khiến ngành công nghiệp này thiệt hại hàng trăm triệu đô la không?

Năm năm lịch sử đã chứng minh rằng thao túng oracle không phải là một rủi ro giả định hay một trường hợp ngoại lệ—mà là một chiến lược tấn công có thể lặp lại, được ghi chép lại và có lợi nhuận cao, tiếp tục được khuếch đại khi thị trường phát triển.

Tháng 10 năm 2025 cho thấy điều gì sẽ xảy ra khi những bài học này không được rút ra ở quy mô tổ chức. Cuộc tấn công không hề phức tạp hay mới lạ, nó chỉ đơn giản là cùng một chiến thuật được thực hiện lại trên một hệ thống lớn hơn, khai thác một khoảng thời gian lỗ hổng đã biết.

Sấm truyền là nền tảng của hệ thống. Khi nó nứt, mọi kiến trúc thượng tầng đều sụp đổ.

Trong thị trường kết nối hiện đại, thiết kế oracle không chỉ liên quan đến việc truyền dữ liệu mà còn liên quan đến tính ổn định của hệ thống.

Một lỗi thiết kế trị giá 60 triệu đô la có thể phá hủy 19,3 tỷ đô la.

Nếu bạn liên tục mắc cùng một lỗi, bạn sẽ không học được gì từ lỗi đó; thay vào đó, bạn sẽ lặp lại lỗi đó với cái giá phải trả đắt hơn.

Phân tích dựa trên dữ liệu thị trường công khai, các tuyên bố nền tảng và năm năm nghiên cứu điển hình về thao túng Oracle. Quan điểm được trình bày là của riêng tôi và không đại diện cho bất kỳ tổ chức nào.