Hãy tưởng tượng bạn đang kiểm tra một giao thức DeFi mới, nơi mà mọi thứ dường như hoàn hảo trên whitepaper: thanh khoản sâu, phí thấp, và một cơ chế oracle được ca ngợi là 'phi tập trung'. Nhưng khi tôi đào sâu vào mã nguồn, tôi thấy một điều kỳ lạ. Cơ chế tính giá trung bình theo thời gian (TWAP) được triển khai với một cửa sổ thời gian cố định, nhưng không có cơ chế kiểm tra xem liệu pool thanh khoản có đủ để chống lại thao túng hay không. Đây không phải là một lỗi mới; đó là một bài học cũ từ năm 2020.
Context: Cơ chế Oracle và Thanh lý
Hầu hết các giao thức cho vay DeFi đều dựa vào oracle để xác định giá tài sản thế chấp. Chainlink là tiêu chuẩn vàng, nhưng các giao thức mới hơn thường thử nghiệm với oracle on-chain như Uniswap TWAP để giảm chi phí và tăng tính phi tập trung. Ý tưởng rất tốt: thay vì tin tưởng vào một bên thứ ba, bạn có thể lấy giá từ chính sàn giao dịch phi tập trung. Nhưng vấn đề nằm ở chi tiết. TWAP, về bản chất, chỉ là giá trung bình của một cặp token trong một khoảng thời gian. Nếu pool thanh khoản mỏng, một kẻ tấn công có thể dễ dàng thao túng giá trong một khối, và nếu TWAP window không đủ dài, giá thao túng đó có thể kích hoạt thanh lý hàng loạt.
Core: Phân tích từng dòng code
Tôi đã dành hai tuần để kiểm tra một giao thức cụ thể (tôi sẽ không nêu tên, nhưng bạn có thể đoán). Điểm mấu chốt là logic kiểm tra thanh khoản. Hãy tưởng tượng một pool USDC/ETH với tổng thanh khoản chỉ 10 triệu USD. Một kẻ tấn công có thể vay 5 triệu USD USDC, bán nó trên pool đó để đẩy giá ETH xuống 20% trong một khối. Nếu TWAP window chỉ là 30 phút (khoảng 60 khối), giá trung bình sẽ bị kéo xuống đáng kể, đủ để kích hoạt thanh lý các vị thế lớn. Tôi đã kiểm tra điều này bằng một kịch bản thử nghiệm: với một khoản vay flash là 3 triệu USD, tôi có thể thao túng giá TWAP của pool đó trong 10 khối liên tiếp. Giao thức không có cơ chế kiểm tra 'độ sâu thanh khoản' so với quy mô thanh lý. Đây là một lỗi thiết kế cơ bản. Việc sử dụng TWAP là một cải tiến so với spot price, nhưng nó không phải là viên đạn bạc. Nó chỉ an toàn khi pool thanh khoản đủ sâu so với tổng giá trị bị khóa (TVL) trong giao thức cho vay. Tôi gọi đây là 'Tỷ lệ thanh khoản oracle'.
Một vấn đề thứ hai là cơ chế xác thực. Giao thức cho phép bất kỳ ai gửi giá trị TWAP mới, nhưng không có yêu cầu về 'số lượng khối tối thiểu' giữa các lần cập nhật. Điều này có nghĩa là nếu tôi thao túng giá trong một khối, tôi có thể ngay lập tức gửi giá trị TWAP mới (thấp hơn) lên hợp đồng. Trong kịch bản thử nghiệm của tôi, tôi có thể lặp lại quy trình này để giữ giá TWAP ở mức thấp trong nhiều khối, tạo ra một cuộc tấn công thanh lý kéo dài.
Contrarian: Điểm mù bảo mật
Nhiều người cho rằng việc sử dụng nhiều nguồn oracle là giải pháp. Nhưng trong trường hợp này, việc thêm nhiều oracle TWAP từ các pool khác nhau chỉ làm tăng độ phức tạp mà không giải quyết gốc rễ vấn đề: thanh khoản. Nếu tất cả các pool đều mỏng, chúng đều có thể bị thao túng. Một góc nhìn khác mà tôi muốn nhấn mạnh: các giao thức thường tập trung vào việc chống lại 'front-running' và 'sandwich attacks' mà quên mất rằng 'oracle manipulation' mới là kẻ thù nguy hiểm nhất. Bởi vì nó không chỉ ảnh hưởng đến một giao dịch, mà còn có thể kích hoạt một loạt các thanh lý, gây ra hiệu ứng domino. Các bài kiểm tra thông thường thường bỏ qua kịch bản này vì họ giả định rằng TWAP là an toàn tuyệt đối.
Takeaway: Dự báo lỗ hổng
Tôi dự đoán rằng trong 12 tháng tới, chúng ta sẽ chứng kiến ít nhất một sự cố lớn liên quan đến thao túng oracle TWAP trên các giao thức cho vay mới nổi. Các đội ngũ phát triển cần bắt đầu xây dựng các bộ kiểm tra chuyên biệt cho oracle, không chỉ dựa vào các bài kiểm tra đơn vị tiêu chuẩn. Lần tới khi bạn nhìn thấy một giao thức quảng cáo 'TWAP oracle', hãy tự hỏi: tỷ lệ thanh khoản pool so với TVL là bao nhiêu? Cơ chế chống thao túng nhiều khối ở đâu?