Nhiều người nghĩ rằng oracle là một chi tiết kỹ thuật nhỏ nhặt, có thể thay thế dễ dàng bằng một API từ CoinGecko hay Binance. Nhưng thực chất, cơ chế lấy giá quyết định tính mạng của toàn bộ hợp đồng thông minh — và tôi, với tư cách là một Smart Contract Architect đã từng đào sâu vào từng dòng mã của Kyber Network từ năm 2017, có thể khẳng định: hầu hết các giao thức DeFi hiện tại vẫn đang mắc những lỗi tương tự, chỉ là chưa ai kích hoạt chúng mà thôi.
Hãy quay lại tháng 9 năm 2017. Tôi vừa tốt nghiệp Thạc sĩ Kinh tế, nhưng tôi không đi làm ngân hàng hay tài chính truyền thống. Tôi lao vào phân tích hợp đồng thông minh của Kyber Network — một dự án DEX sớm nhất, với tuyên bố rằng họ có thuật toán oracle độc quyền cho phép lấy giá chính xác từ nhiều nguồn. Sau hai tháng kiểm tra từng dòng mã, tôi phát hiện một lỗ hổng trong logic cập nhật giá: khi một nguồn oracle bị trễ (do mạng Ethereum tắc nghẽn), thuật toán sẽ chọn mức giá thấp nhất giữa các nguồn, nhưng không có cơ chế kiểm tra độ trễ. Kết quả là, một kẻ tấn công có thể chủ động làm trễ oracle bằng cách gửi giao dịch với gas thấp, sau đó khai thác chênh lệch giá tạm thời. Tôi đã viết báo cáo 35 trang, gửi lên GitHub, nhưng đội ngũ phát triển quá tải vì ICO, phản hồi chậm. Cuối cùng, lỗ hổng này không được vá kịp thời, và nhiều tháng sau, một sự cố tương tự đã xảy ra trên một giao thức fork từ Kyber. Oracle lỗ? Tôi đã thấy trước.
Context: Bối cảnh giao thức và cơ chế oracle
Để hiểu tại sao oracle lại quan trọng đến vậy, cần nhìn vào kiến trúc của Kyber Network. Kyber là một on-chain liquidity protocol, cho phép người dùng swap token trực tiếp từ ví thông qua các reserve (bể thanh khoản). Mỗi reserve có một hợp đồng oracle riêng, chịu trách nhiệm báo giá token theo cặp. Giá được lấy từ nhiều nguồn bên ngoài (CEX, DEX khác, market maker), sau đó tổng hợp thành một giá duy nhất. Vấn đề nằm ở thuật toán tổng hợp: Kyber sử dụng weighted average dựa trên độ tin cậy của từng nguồn, nhưng độ tin cậy này lại được cập nhật định kỳ thông qua một admin key. Nói cách khác, oracle của Kyber không phải là phi tập trung thuần túy — nó phụ thuộc vào một tập hợp nhỏ các admin để đánh giá chất lượng nguồn. Đây chính là điểm yếu kinh điển: thiết kế lai giữa tập trung và phi tập trung, dẫn đến cả hai mặt xấu: không đủ nhanh để cập nhật khi thị trường biến động, và không đủ an toàn vì admin key có thể bị compromised.
Tôi đã từng phân tích chi tiết cơ chế này trong báo cáo 35 trang của mình. Điều thú vị là lỗ hổng tôi tìm thấy không nằm ở việc admin key bị đánh cắp, mà nằm ở logic xử lý độ trễ. Cụ thể, khi một nguồn oracle gửi giá mới, hợp đồng sẽ kiểm tra timestamp, nhưng nó chỉ so sánh với block timestamp hiện tại, chứ không kiểm tra xem nguồn đó có bị trễ so với các nguồn khác hay không. Nếu một nguồn bị trễ 10 block (khoảng 2 phút trong điều kiện Ethereum thường), và trong 2 phút đó giá thị trường thực tế đã biến động mạnh (ví dụ do một sự kiện flash crash), thì giá trễ đó sẽ được chấp nhận và đưa vào weighted average. Kết quả: giá oracle bị lệch so với thị trường, mở ra cơ hội arbitrage cho bot. Bot có thể mua token từ Kyber với giá cũ (rẻ hơn) và bán lại trên thị trường khác. Nghe có vẻ là lợi nhuận cho bot, nhưng thực chất là thất thoát cho các liquidity provider (LP) và người dùng thông thường. Đây là lý do tại sao hàng triệu USD đã bị mất trong các sự kiện oracle manipulation sau này.
Core: Phân tích kỹ thuật cấp code và trade-offs
Hãy đi sâu vào mã nguồn giả định của Kyber oracle (tôi sẽ dùng pseudocode vì mã thật đã được archive nhiều năm trước). Hợp đồng KyberOracle.sol có một hàm updatePrice:
function updatePrice(address source, uint256 price, uint256 timestamp) external onlyAdmin {
require(timestamp <= block.timestamp, "Future timestamp");
// ...
latestPrice[source] = price;
latestTimestamp[source] = timestamp;
// recompute aggregate price
_aggregatePrice();
}function _aggregatePrice() internal { uint256 totalWeight = 0; uint256 weightedPrice = 0; for (uint i = 0; i < sources.length; i++) { address source = sources[i]; uint256 weight = getWeight(source); if (weight > 0 && latestPrice[source] != 0) { // Check staleness? // No check! weightedPrice += latestPrice[source] * weight; totalWeight += weight; } } currentPrice = weightedPrice / totalWeight; } ```
Bạn thấy không? Không có kiểm tra độ trễ (staleness) trong _aggregatePrice. Mỗi nguồn chỉ được cập nhật bởi admin, nhưng admin có thể quên hoặc bị trễ do mạng. Trong thực tế, admin thường là bot tự động gọi updatePrice mỗi vài phút. Nhưng nếu bot gặp sự cố (RPC fail, gas price tăng đột biến), thì oracle sẽ dùng giá cũ. Giải pháp thông thường là thêm một MAX_STALENESS (ví dụ 1 giờ) — nếu timestamp của nguồn cũ hơn block.timestamp - MAX_STALENESS, thì loại bỏ nguồn đó. Nhưng tại sao Kyber không làm vậy? Có lẽ vì trade-off: nếu loại bỏ nguồn cũ, thì có thể không đủ nguồn để tổng hợp, dẫn đến giá oracle không được cập nhật. Nhưng trade-off này có thể được giải quyết bằng cách dùng một fallback oracle (như MakerDAO đã làm với medianizer). Tuy nhiên, Kyber đã chọn phương án đơn giản hơn: tin tưởng admin sẽ luôn cập nhật kịp thời. Đây là một sai lầm thiết kế điển hình của giai đoạn 2017 — khi mà bảo mật oracle chưa được hiểu rõ.
Từ kinh nghiệm audit của tôi, tôi thấy rằng bài toán oracle luôn xoay quanh việc cân bằng giữa độ chính xác và độ tươi mới (freshness). Một oracle quá nhạy (chấp nhận giá từng block) dễ bị front-running và flash loan tấn công. Một oracle quá chậm (cập nhật mỗi giờ) thì không phản ánh đúng thị trường. Giải pháp lý tưởng là sử dụng TWAP (Time-Weighted Average Price) như Uniswap V2 đã làm, nhưng TWAP lại chậm và không phù hợp với các giao thức cần giá tức thời như Kyber. Vậy nên, không có giải pháp hoàn hảo; chỉ có giải pháp phù hợp với mô hình rủi ro.
Contrarian: Điểm mù bảo mật mà ít ai nhìn thấy
Hầu hết các bài viết về oracle manipulation đều tập trung vào flash loan hay price manipulation trực tiếp. Nhưng theo quan sát của tôi, điểm mù lớn nhất nằm ở chính những người vận hành oracle — các admin và operator. Trong trường hợp Kyber, admin key là một điểm thất bại duy nhất (SPOF). Nhưng ngay cả khi admin key an toàn, thì bot tự động cập nhật oracle cũng có thể bị tấn công thông qua việc làm trễ transaction. Tôi đã từng viết một bài phân tích về cách kẻ tấn công có thể khai thác mempool: gửi transaction với gas thấp để làm trễ oracle update, đồng thời gửi transaction swap với gas cao để khớp lệnh trước khi giá được cập nhật. Đây là một hình thức front-running không cần flash loan, chỉ cần kiên nhẫn và một chút hiểu biết về gas auction.
Điều trớ trêu là các giao thức sau này như Uniswap V3, dù đã cải tiến oracle, vẫn mắc lỗi tương tự ở lớp ứng dụng. Ví dụ, các lending protocol dùng TWAP của Uniswap làm oracle, nhưng lại không kiểm tra độ lệch giữa giá spot và giá TWAP. Khi thị trường biến động mạnh, TWAP bị trễ, tạo cơ hội thanh lý chênh lệch. Tôi đã thấy nhiều trường hợp thanh lý không công bằng do oracle lag, và ít ai dám công khai chỉ trích vì liên quan đến lợi ích của LP. Oracle lỗ? Tôi đã thấy trước, và tôi sẽ tiếp tục thấy trước cho đến khi nào cộng đồng chấp nhận rằng việc phụ thuộc vào một oracle duy nhất là điên rồ.
Takeaway: Dự báo lỗ hổng
Vậy, điều gì sẽ xảy ra tiếp theo? Tôi dự đoán rằng trong chu kỳ tăng giá này, khi khối lượng giao dịch tăng vọt, các giao thức sử dụng oracle lấy từ một nguồn duy nhất (đặc biệt là các CEX như Binance) sẽ gặp sự cố. Không phải vì Binance bị hack, mà vì API của Binance có thể bị rate limit hoặc chậm do traffic cao, dẫn đến oracle bị trễ. Một số giao thức đã bắt đầu chuyển sang sử dụng oracle mạng (như Pyth Network) với độ trễ thấp hơn, nhưng Pyth lại yêu cầu người dùng phải trả phí để cập nhật giá — một mô hình kinh tế chưa được kiểm chứng trong điều kiện thị trường gấu. Liệu người dùng có sẵn sàng trả phí để update price mỗi khi họ muốn swap hay borrow? Câu trả lời là không, trừ khi giao thức bắt buộc. Và nếu giao thức bắt buộc, thì đó lại là một class of MEV khác.
Tôi kết thúc bài viết này bằng một câu hỏi: Khi lỗ hổng oracle tiếp theo xảy ra, bạn sẽ đổ lỗi cho hacker, hay cho chính thiết kế mà bạn đã bỏ qua từ đầu?