Tuần trước, một giao thức stablecoin mới trên Ethereum đã mất 40% tổng giá trị bị khóa (TVL) sau khi phát hiện lỗ hổng oracle. Tên của nó? Không quan trọng. Cấu trúc lỗi thì giống hệt những gì tôi đã thấy trong hợp đồng Anchor Protocol năm 2022. Sau Terra, tôi hiểu: không có gì mới dưới mặt trời của những oracle giá cả.
Bối cảnh: giao thức này sử dụng một oracle tập trung duy nhất để cập nhật giá tài sản thế chấp. Khi thị trường biến động mạnh, oracle không kịp phản ứng, tạo ra chênh lệch giá giữa sàn giao dịch và hợp đồng. Kẻ tấn công đã lợi dụng khoảng trống này để vay một lượng lớn stablecoin với tài sản thế chấp bị định giá quá cao. Khi oracle cập nhật, vị thế đã bị thanh lý, nhưng kẻ tấn công đã rút tiền trước đó. Thiệt hại: 12 triệu USD.
Nhiều người sẽ nói: 'Đó là lỗi của oracle tập trung.' Sai. Vấn đề sâu hơn: thiết kế kinh tế của giao thức không có cơ chế dự phòng cho độ trễ oracle. Trong báo cáo kiểm toán của tôi cho một quỹ ETF Bitcoin năm 2024, tôi đã chỉ ra rằng bất kỳ hệ thống nào phụ thuộc vào nguồn dữ liệu bên ngoài đều cần một lớp xác thực thứ hai – ví dụ: sử dụng nhiều nguồn oracle với cơ chế đồng thuận, kết hợp với một bộ lọc biên độ giá để ngăn chặn các cập nhật bất thường. Giao thức này không có gì cả.
Phân tích kỹ thuật: Hợp đồng thông minh của họ sử dụng hàm updatePrice() có thể được gọi bởi bất kỳ ai, nhưng chỉ có một địa chỉ oracle được phép ghi. Điều này tạo ra một điểm thất bại duy nhất. Trong môi trường phi tập trung, không có chỗ cho sự tập trung hóa ở cấp độ dữ liệu. Không có 'tin cậy' trong thế giới của những hợp đồng thông minh, chỉ có mã nguồn và các giả định bảo mật. Tôi đã từng phát hiện một lỗ hổng tương tự trong hợp đồng ICO của EOS năm 2017: một hàm cập nhật không có kiểm soát truy cập đã cho phép rút ETH nhiều lần. Bài học vẫn còn nguyên giá trị.
Điểm mù mà hầu hết các nhà phân tích bỏ qua: không chỉ oracle mới là vấn đề. Cơ chế thanh lý của giao thức này cũng có lỗi. Nó cho phép thanh lý một phần, nhưng không có giới hạn về số lần thanh lý trong một khối. Kẻ tấn công đã kết hợp khai thác oracle với một cuộc tấn công front-running để thanh lý nhiều vị thế cùng lúc, kiếm thêm phí thanh lý. Đây là một vector tấn công kết hợp – oracle + thanh lý – mà ít ai để ý. Từ kinh nghiệm kiểm toán Uniswap V2 năm 2020, tôi biết rằng các lỗi nhỏ trong logic thanh lý có thể tích lũy thành thiệt hại lớn theo thời gian.
Vậy, bài học là gì? Không phải 'hãy dùng oracle phi tập trung' – đó là câu trả lời quá dễ. Bài học thực sự: bất kỳ giao thức nào có oracle và thanh lý đều cần được kiểm toán như một hệ thống, không phải như các module riêng lẻ. Tôi đã xây dựng một công cụ AI vào năm 2026 để quét các lỗ hổng kết hợp như thế này. Trong 10.000 hợp đồng được quét, 230 lỗ hổng tiềm ẩn – 12 trong số đó ở mức ưu tiên cao. Xu hướng hiện tại: các lỗ hổng oracle vẫn chiếm 35% trong số đó.
Trong thị trường đi ngang hiện tại, khi TVL đang tích lũy, các dự án mới thường cắt giảm chi phí bảo mật. Đó là một sai lầm. Tôi dự đoán: trong 6 tháng tới, chúng ta sẽ chứng kiến ít nhất 3 vụ khai thác oracle tương tự, với tổng thiệt hại trên 50 triệu USD. Lý do? Các đội ngũ phát triển vẫn chưa hiểu rằng 'thông minh' trong hợp đồng thông minh không đến từ tính năng, mà đến từ các giả định an toàn.
Hãy hỏi lại chính bạn: liệu giao thức của bạn có thể sống sót nếu oracle của nó bị tấn công trong 30 phút? Nếu câu trả lời là 'không', thì bạn đang ngồi trên một quả bom hẹn giờ.
