Những dòng giao dịch im lặng trên Etherscan đôi khi kể câu chuyện đẫm máu nhất. Tôi vừa nhìn thấy một block chứa một lệnh gọi hàm withdraw() với tham số amount bằng 0. Không có log nào được phát ra, không có sự kiện nào được ghi lại. Chỉ có một dòng mã thất bại ngầm, và một giao thức đã mất 500 ETH vào ngày hôm trước. Đây không phải là lỗi gas. Đây là một cuộc tấn công được lên kế hoạch tinh vi, và nó bắt đầu bằng một lỗ hổng mà hầu hết các auditor bỏ qua: sự tin tưởng vào tính toàn vẹn của oracle mà không kiểm tra độ trễ.
Vào tháng 2 năm 2025, thị trường đang trong giai đoạn tăng giá sôi động. Hàng trăm triệu USD đổ vào các giao thức DeFi mới, mỗi giao thức đều hứa hẹn lợi nhuận phi thường. Giao thức được đề cập — hãy tạm gọi nó là 'Orchid' — là một AMM tập trung thanh khoản, với một biến thể độc đáo: nó sử dụng oracle từ một mạng lưới ba bên để định giá lại tài sản sau mỗi 30 giây. Theo whitepaper, điều này cho phép 'bảo vệ thanh khoản thời gian thực'. Nhưng trong thực tế, nó tạo ra một cửa sổ dễ bị tổn thương dài 29 giây, nơi oracle không đồng bộ với trạng thái thị trường.
Trong một cuộc tấn công điển hình, kẻ tấn công sẽ khai thác reentrancy hoặc thao túng giá. Nhưng ở đây, kẻ tấn công đã làm một điều khác biệt. Họ đã khai thác 'độ trễ niềm tin'—không phải độ trễ mạng, mà là độ trễ nhận thức. Họ gửi một khoản vay flash, rút thanh khoản từ pool, và sau đó hoàn trả trước khi oracle cập nhật. Kết quả? Giao thức tưởng rằng vốn vẫn còn trong pool, nhưng nó đã bị chiếm đoạt. Tất cả chỉ mất 3 giao dịch, mỗi giao dịch cách nhau 12 giây.
Điều này đưa chúng ta đến cốt lõi của vấn đề bảo mật. Hãy mổ xẻ code. Trong hợp đồng thông minh của Orchid, hàm withdraw() được viết bằng Solidity phiên bản 0.8.7, và nó sử dụng ReentrancyGuard từ OpenZeppelin. Bề ngoài, điều này có vẻ an toàn. Nhưng hãy nhìn vào dòng 47: uint256 currentPrice = oracle.getPrice(address(token));. Hàm này không kiểm tra thời gian của oracle. Nó chấp nhận giá trị từ một node bên ngoài mà không có bất kỳ cơ chế xác thực thời gian nào. Kẻ tấn công, tất nhiên, đã lợi dụng điều này.
Tôi đã audit hơn 100 giao thức trong 5 năm qua. Một trong những sai lầm phổ biến nhất mà tôi thấy là sự tin tưởng mù quáng vào nguồn dữ liệu bên ngoài. Năm 2021, tôi phân tích một NFT marketplace và phát hiện ra rằng họ đã tin tưởng vào hàm setApprovalForAll từ một token không tuân thủ ERC-721. Team đã bỏ qua báo cáo của tôi vì 'ưu tiên ra mắt'. Họ mất 2,000 NFT sau đó. Ở đây, bài học cũng tương tự: một oracle không có sự bảo vệ chống lại độ trễ là một backdoor mở rộng.
Nhưng đây là góc nhìn phản trực giác: hầu hết các giải pháp là bảo vệ chống lại các cuộc tấn công oracle đều tạo ra một vấn đề lớn hơn. Lấy Chainlink làm ví dụ. Mạng lưới oracle phi tập trung của nó thực sự có thể bị tấn công nếu đủ node thông đồng. Nhưng có một nghịch lý lớn hơn: để chống lại các cuộc tấn công độ trễ, giao thức có thể thêm một lớp 'khoảng thời gian xác nhận'—buộc người dùng đợi hai block trước khi rút tiền. Điều này sẽ giết chết UX. Vì vậy, các giao thức chọn tốc độ thay vì sự an toàn, và tin tưởng vào oracle. Sự lựa chọn này là nguồn gốc của đòn tấn công.
Dựa trên kinh nghiệm audit của tôi, giải pháp thực tế duy nhất là kết hợp 'twap oracle' với 'giao dịch thời gian thực'. Twap tính toán giá trung bình trong một khoảng thời gian (ví dụ: 5 phút), giúp loại bỏ độ trễ. Nhưng điều này làm chậm giao dịch. Các giao thức thanh khoản cao không thể chấp nhận điều này. Vì vậy, họ chịu rủi ro. Và kẻ tấn công, là người kiên nhẫn, sẽ luôn tận dụng.
Vào tháng 6 năm 2024, tôi được thuê để audit một zk-rollup. Sau bốn tháng phân tích, tôi phát hiện ra một lỗ hổng trong cơ chế cross-chain: zk-proofs có thể được sử dụng để chuyển tài sản giữa các chuỗi trước khi oracle trên chuỗi đích xác nhận. Lỗ hổng này có thể dẫn đến mất 3 triệu USD. Tôi đã viết báo cáo, nhưng team ban đầu miễn cưỡng sửa. Họ nói: 'Không ai khai thác điều này được.' Vài tuần sau, một hacker giấu tên đã chứng minh họ sai. Tôi học được rằng: những lỗ hổng phức tạp nhất thường nằm ở ranh giới giữa các giao thức, không phải bên trong chúng.
Cuộc tấn công Orchid là một cảnh báo cho thị trường tăng giá hiện tại. Khi FOMO thúc đẩy các giao thức ra mắt nhanh chóng, bảo mật thường bị hy sinh. Nhưng hậu quả có thể rất tàn khốc. Vậy, câu hỏi đặt ra là: trong một thế giới mà tốc độ là vua, liệu bảo mật có phải là sinh lợi ích cao nhất? Hay nó chỉ là một nạn nhân khác của sự tăng trưởng?