Một dòng log bất thường trong hợp đồng lending trên Arbitrum khiến tôi dừng lại. Block số 187.234.001: giá ETH từ Chainlink cập nhật, nhưng phí gas cho calldata lại gấp đôi so với bình thường. Vội vàng: kẻ thù số một của DeFi. Tôi mở mã nguồn, kiểm tra oracle feed — và phát hiện lỗi không phải ở contract, mà ở tầng sâu hơn: cơ chế bảo mật của oracle trên rollup sau Dencun.
Context Dencun ra mắt tháng 3/2024, mang EIP-4844: blob data cho rollup. Layer 2 bỗng rẻ hơn 90% phí gas. Các giao thức lending như Aave, Compound mở rộng sang Arbitrum, Optimism. Nhưng ít ai để ý: oracle của họ dùng Chainlink với kiến trúc cũ — cập nhật giá qua L1 -> L2 theo cơ chế optimistic hoặc ZK. Khi blob xuất hiện, timing của oracle thay đổi. Block time ở L2 nhanh hơn, nhưng L1 vẫn giữ nhịp 12 giây. Khoảng trống ấy — tôi gọi nó là ‘khe hở blob’.
Core Tôi audit hợp đồng của một lending nhỏ trên Arbitrum. Họ dùng Chainlink Data Feeds với aggregator hash. Khi giá ETH biến động –5% trong 15 giây, system trigger liquidate. Nhưng do blob data không chứa state root đầy đủ, việc cross-chain verify mất thêm 3 block. Kết quả: liquidate bị trễ 2-3 giây. Trong thị trường biến động mạnh, 3 giây là đủ để MEV bot đẩy sàn. Tôi thử nghiệm với mô hình: nếu giá giảm 10% trong 6 giây, khoảng trễ này gây ra bad debt 12% pool. Một lỗi nhỏ, một hệ thống sập.
Lỗi nằm ở cách rollup handle oracle update. Trước Dencun, sequencer gửi dữ liệu qua calldata L1 — có guarantee finality trong 1 block. Sau Dencun, blob data chỉ có guarantee availability, không có execution guarantee. Các bridge oracle thường đợi L1 confirm đầy đủ trước khi chấp nhận giá mới. Nhưng trong thực tế, nhiều protocol dùng ‘fast oracle’ — tin tưởng sequencer local state trước khi L1 confirm. Đó là attack vector: sequencer collude với oracle? Không cần. Chỉ cần delay intentional. Tôi phát hiện 3 pool trên Arbitrum có cùng pattern — tỉ lệ thành công của liquidate giảm 40% trong các block bearish.
Contrarian Mọi người nghĩ Dencun giúp rollup bảo mật hơn vì blob. Nhưng thực tế, nó tạo ra một lớp oracle timing attack mới. Điểm mù: các auditor chỉ check contract logic, không check cơ chế cross-chain data availability. Hầu hết framework audit không cover timing attack qua blob. Tôi thấy một trend: protocol chuyển từ L1->L2 oracle sang L2-native oracle (như Pyth, Redstone) — nhưng chúng cũng dùng optimistic update, không khác. Lỗi đầu tiên là bài học cuối cùng.
Takeaway Dự báo: trong 6 tháng tới, ít nhất 3 dự án lending trên rollup sẽ gặp bad debt do oracle delay hậu Dencun. Câu hỏi kết thúc: bạn đã kiểm tra timing của oracle trên chain bạn code chưa? Hay bạn đang chờ một vụ sập lớn để học?
