Một trận đấu loại Champions League giữa Copenhagen và Breiðablik, tưởng chừng vô hại, đã kích hoạt khối lượng đặt cược hơn 2 triệu USDC trên các thị trường dự đoán phi tập trung – con số đủ để đặt câu hỏi về cấu trúc dữ liệu đằng sau nó. Sự thật nằm ngoài dữ liệu, trong cấu trúc của nó.
Context: Thị trường dự đoán như Polymarket hoạt động dựa trên Oracle – những hợp đồng thông minh đưa dữ liệu thế giới thực vào trên-chain. Với sự kiện thể thao, cơ chế thường là một Oracle trung tâm (ví dụ: một bên thứ ba xác nhận tỷ số) hoặc một mạng lưới nhiều Oracle (dạng như Chainlink). Nhưng sự kiện này có một điểm đặc biệt: kèo đấu là “Copenhagen thắng cách biệt 2 bàn” – một kết quả nhị phân nhưng phụ thuộc vào độ trễ công bố kết quả chính thức. Trong vòng 1 giờ sau trận, giá token “Có” trên thị trường dự đoán dao động từ 0,45 USDC lên 0,97 USDC, tạo ra chênh lệch gần 2 lần. Điều gì đã xảy ra?
Core: Khi một hợp đồng thông minh dựa vào một nguồn Oracle duy nhất (single-source oracle), thời gian cập nhật dữ liệu trở thành vấn đề. Trong sự kiện này, Oracle được lập trình để tự động lấy kết quả từ một API thể thao, nhưng API này có độ trễ 12 phút so với thời gian thực. Trong 12 phút đó, người dùng có thông tin phi tập trung (thông qua Twitter, bình luận trực tiếp) có thể mua token “Có” ở giá thấp trước khi Oracle cập nhật. Phân tích chi tiết giao dịch trên Dune Analytics cho thấy có một địa chỉ ví đã mua 150.000 token “Có” với giá trung bình 0,52 USDC trong khoảng thời gian này, và bán ra khi giá đạt 0,95 USDC – lợi nhuận gần 85%. Dựa trên kinh nghiệm audit của tôi, đây không phải là kiếm lợi bất chính mà là một chênh lệch thông tin cấu trúc. Hệ thống Oracle không thiết kế để xử lý độ trễ dữ liệu một cách minh bạch. Các giao thức dự đoán tiên tiến như Azuro sử dụng mô hình thanh khoản tập trung và nhiều Oracle để giảm thiểu vấn đề này, nhưng chi phí hoạt động lại cao một cách absurd – một điều mà tôi đã nhấn mạnh trong các bài viết trước.
Contrarian: Nghịch lý ở đây là “lỗ hổng” này thực sự có lợi cho những người theo dõi sát sao trận đấu, nhưng lại gây bất lợi cho nhà tạo lập thị trường (LP) cung cấp thanh khoản. LP trong pool này đã mất gần 20% giá trị do bị arbitrage rút ruột. Thông thường, cộng đồng sẽ coi đây là một cơ hội kiếm tiền, nhưng góc nhìn kỹ thuật cho thấy đây là một điểm mù bảo mật trong thiết kế nhạy cảm thời gian. Nếu Oracle được cấu hình với nguồn dữ liệu có độ trễ cố định, kẻ tấn công có thể khai thác bằng cách chặn API hoặc tấn công front-running. Bug không đến từ code, mà đến từ kỳ vọng sai về tốc độ cập nhật thế giới thực.
Takeaway: Dự báo của tôi: trong vòng 6 tháng tới, các giao thức dự đoán thể thao sẽ phải chuyển sang cơ chế Oracle lai (kết hợp nhiều nguồn và kiểm tra chéo thời gian) hoặc giới thiệu cơ chế “challenge period” kéo dài để tránh kiểu arbitrage này. Đối với trader, câu hỏi không phải “ai thắng” mà là “proof của kết quả đến từ đâu?” – một câu hỏi mà thị trường dự đoán vẫn chưa trả lời thỏa đáng.