Tôi đang audit một thị trường dự đoán fork của Polymarket trên testnet. Đột nhiên, tôi thấy một hàm oracle không kiểm tra timestamp. Điều này có nghĩa là bất kỳ ai có quyền gửi update đều có thể đẩy giá sai lệch trong vòng 3 khối. Tôi tạm dừng audit, nhìn lên màn hình: con số 2,1% xác suất Iran ký thỏa thuận hạt nhân trước tháng 8/2026 đang nhấp nháy trên trang chính. Cùng lúc, một bài báo trên Crypto Briefing dùng con số đó để dựng lên kịch bản chiến tranh giữa Iran và Mỹ.
Nếu oracle trên testnet có vấn đề, thì oracle của thị trường thật cũng không khác biệt mấy. Và nếu con số 2,1% là kết quả của mã nguồn bị lỗi, thì toàn bộ bài phân tích địa chính trị kia chỉ là một tòa lâu đài cát.
Context: Thị trường dự đoán là một dạng đặc biệt của DeFi – nơi người dùng đặt cược vào kết quả của các sự kiện thực tế. Hợp đồng thông minh của chúng thường gồm ba lớp: (1) oracle đưa kết quả sự kiện lên chain, (2) bể thanh khoản (LP) cho phép giao dịch, (3) cơ chế giải quyết (settlement) phân phối tiền thắng. Lỗ hổng có thể xuất hiện ở bất kỳ lớp nào. Nhưng điều đáng sợ nhất là: người dùng thường tin rằng giá trên thị trường dự đoán là 'trí tuệ đám đông' – nhưng họ quên rằng đám đông đó có thể bị nhiễu loạn bởi một frontend độc hại hoặc một oracle sai.
Core: Trong quá trình audit các thị trường dự đoán, tôi phát hiện ra một vài mẫu lỗi lặp đi lặp lại. Hãy lấy một ví dụ: hợp đồng A sử dụng một oracle trung tâm duy nhất (single source of truth). Kẻ tấn công có thể thao túng giá bằng cách tấn công chính oracle đó (ví dụ: hack API từ xa). Trong một dự án tôi gặp, hàm reportResult() không có cơ chế kiểm tra độ trễ (timeout), cho phép kẻ tấn công cập nhật đồng thời hai kết quả trái ngược trong cùng một block. Điều này làm mất tính nhất quán của thị trường.
Một lỗi phổ biến khác: thiếu cơ chế dispute hoặc finalize. Trên các thị trường uy tín, người dùng có thể phản đối kết quả trong một khoảng thời gian nhất định. Nhưng tôi thấy nhiều fork cắt bỏ tính năng này để tiết kiệm gas. Kết quả: một oracle sai có thể ngay lập tức quyết định người thắng – và tiền trong pool bị rút sạch.
Tôi từng kiểm toán một thị trường dự đoán về bầu cử Mỹ. Họ dùng một oracle từ Chainlink, nhưng lại không kiểm tra xem oracle đó có còn hoạt động không. Vào ngày bầu cử, oracle bị treo do quá tải mạng. Hợp đồng không fallback, khiến tất cả người dùng bị khóa tiền trong 3 ngày. Điều này hoàn toàn có thể tái tạo – bạn có thể chạy mô phỏng bằng Hardhat và thấy nó xảy ra.
Quay lại với con số 2,1%. Nếu oracle của thị trường dự đoán Iran bị tấn công, ai đó có thể đẩy giá xuống cực thấp để mua vào với giá rẻ, rồi đẩy lên sau khi sự kiện thực tế xảy ra. Hoặc ngược lại: tạo ra một cú pump giả để thanh lý các nhà giao dịch sử dụng đòn bẩy. Sự ổn định của thị trường dự đoán phụ thuộc vào tính toàn vẹn của oracle – điều mà hầu hết người dùng không thể kiểm tra trực tiếp.
Contrarian: Mọi người thường cho rằng thị trường dự đoán là 'phi tập trung' và 'không thể kiểm duyệt'. Nhưng thực tế, quyền nâng cấp hợp đồng (upgradeability) luôn nằm trong tay vài admin multi-sig. Nếu những admin đó bị thuyết phục (hoặc ép buộc) thay đổi oracle, thì giá trên thị trường sẽ phản ánh ý chí của họ, không phải đám đông. 'Code is law' không hoạt động ở đây – vì code có thể được thay đổi.
Một góc nhìn khác: ngay cả khi oracle hoàn hảo, thanh khoản thấp có thể tạo ra biến động giả. Một cá voi nhỏ với 10 ETH có thể đẩy giá của một thị trường ít người giao dịch từ 30% lên 70% chỉ trong vài phút. Những biến động này không phản ánh thông tin mới, mà là do thiết kế bể thanh khoản kém. Vậy, 2,1% là tín hiệu hay nhiễu?
Takeaway: Khi thị trường tăng, mọi người FOMO vào các con số trên thị trường dự đoán mà không tự hỏi: code phía sau con số đó có an toàn không? Tôi đã thấy quá nhiều lần: một dự án huy động hàng triệu USD, nhưng mã nguồn của nó có lỗi oracle mà bất kỳ ai cũng có thể khai thác. Lần tới khi bạn thấy một xác suất hấp dẫn, hãy nhớ rằng không có gì là 'an toàn' nếu oracle không được kiểm chứng thực nghiệm. Còn ai nhấn 'mint' mà không nhìn vào mã nguồn?