Hook
Tuần trước, một bridge cross-chain quen thuộc trong top 10 TVL bất ngờ bị khai thác 120 triệu USD. Điều khiến cộng đồng sôi sục không phải kỹ thuật exploit — vì nó là một biến thể của reentrancy đã được document đầy đủ từ năm 2021 — mà là statement chính thức từ team: “Chúng tôi sẽ không chấp nhận bất kỳ yêu cầu refund nào từ hacker. Số tiền này là một phần trong buffer bảo mật của chúng tôi.”
Tôi đọc câu đó xong, tay dừng lại trên debugger. Điều tinh tế (và đáng sợ) trong thiết kế này là họ biến một lỗ hổng thành một quyết định chính trị. Với tư cách một auditor kỹ thuật, tôi thấy đây không đơn thuần là một vụ hack. Đây là một tín hiệu về cấu trúc quyền lực bên trong protocol.
Context
Cần hiểu rõ loại bridge này: đó là một optimistic bridge với một bộ xác thực off-chain (validator set) và một contract on-chain giữ toàn bộ tài sản. Khi người dùng gửi token sang chain đích, validator ký một message, contract khóa token. Cơ chế này phụ thuộc vào giả định rằng validator set là trung thực.
Trong vụ tấn công lần này, hacker khai thác một lỗ hổng trong logic xác minh message — cụ thể, hàm verify() không kiểm tra đủ ràng buộc về số lượng chữ ký, cho phép một chữ ký duy nhất vượt qua ngưỡng 2-of-3 multi-sig. Kết quả là hacker rút toàn bộ pool.
Nhưng thay vì thừa nhận lỗi thiết kế, team phát hành một thông báo dài, lập luận rằng: “Việc refund sẽ tạo ra tiền lệ nguy hiểm cho kẻ tấn công trong tương lai.” Họ so sánh buffer này với “lãnh thổ đệm” của một quốc gia — một cách nói mượn từ chiến lược quân sự. Insight ở cấp độ giao thức mà hầu hết mọi người bỏ lỡ là họ đang thay đổi bản chất của trust model: từ trustless (dựa trên code) sang trust-based (dựa trên quyết định của một nhóm người).
Core
Hãy cùng trace execution path của contract để thấy vấn đề thực sự nằm ở đâu.
Trước nhất, pool contract sử dụng một cơ chế quản lý gọi là “Safety Module” — về lý thuyết, module này được thiết kế để can thiệp trong trường hợp khẩn cấp. Khi hacker rút tiền, team đã active module này và đóng băng contract. Họ có thể làm điều đó. Vậy tại sao không refund?
Code của Safety Module cho phép admin thực hiện bất kỳ hành động nào trên pool, bao gồm mint lại token cho người dùng. Điều mà các dev không nói với bạn là module này không được audit kỹ như core logic. Trong audit báo cáo của tôi với một client tương tự, tôi chỉ ra rằng Safety Module là một backdoor tinh vi — nó cho phép admin override mọi logic. Nhưng ở đây team không refund không phải vì kỹ thuật không cho phép, mà vì họ chọn không làm.
Phần lớn phân tích sai về motive của team. Nhiều người nghĩ họ sợ phải bán token để cover. Nhưng thực tế, bridge có một quỹ bảo hiểm 300 triệu USD từ vòng funding. Lý do thực sự là: họ muốn thiết lập một precedent rằng hacker không thể được thưởng — đây là tư duy “zero-sum” trong bảo mật. Và tư duy đó nguy hiểm hơn bất kỳ lỗi code nào.
Xét về cấu trúc governance: token holders mới là người quyết định việc refund. Nhưng team đã active Safety Module — nghĩa là họ bypass governance. Họ biến một quyết định kỹ thuật (refund hay không) thành một quyết định chính trị đơn phương. Nếu bạn đọc kỹ whitepaper của bridge, bạn sẽ thấy governance được thiết kế để xử lý các quyết định như thế này. Việc team tự ý hành động cho thấy họ không tin tưởng vào cộng đồng của chính mình.
Contrarian
Góc nhìn phản trực giác: Việc từ chối refund thực ra là một tín hiệu tốt cho những ai hold token dài hạn? Một số người cho rằng điều này thể hiện sự cứng rắn, sẽ ngăn chặn các cuộc tấn công tương lai. Nhưng xét trên khía cạnh bảo mật, nó hoàn toàn ngược lại.
Khi một team quyết định không refund, họ đang gửi thông điệp: Chúng tôi sẽ không chịu trách nhiệm cho lỗi của mình. Trong một hệ sinh thái mà người dùng gửi tài sản dựa trên trust vào code, hành động này làm xói mòn niềm tin. Hacker có thể exploit lỗi, và team nói: “Ừ, mất rồi, thôi.” Điều này khuyến khích những kẻ tấn công mạnh tay hơn, vì họ biết với lỗ hổng đủ lớn, team sẽ không chặn được việc mất tiền, chỉ có thể active Safety Module — và thậm chí còn không dùng nó để refund.
Từ góc nhìn audit: Phần lớn phân tích sai về quan hệ giữa refund policy và security posture. Một protocol càng sẵn sàng refund, càng cho thấy họ có kế hoạch dự phòng và khả năng khắc phục lỗi nhanh. Ngược lại, việc từ chối refund là dấu hiệu của kiến trúc cứng nhắc, nơi quyền lực tập trung vào một nhóm nhỏ có thể quyết định số phận tài sản của người dùng.
Takeaway
Câu hỏi rhetorical: Lần tới khi bạn deposit vào một bridge, hãy hỏi: “Nếu bị hack, team có sẵn sàng refund không?” Nếu câu trả lời là không — hoặc mơ hồ — thì bạn đang giao tài sản của mình cho một hệ thống mà code không phải là luật, mà là ý chí của nhóm admin. Tôi dự báo rằng trong chu kỳ tới, chúng ta sẽ chứng kiến nhiều bridge sụp đổ vì chính sách “không refund” này, khi người dùng bắt đầu chạy khỏi các protocol có lỗ hổng governance tiềm ẩn.
Dựa trên kinh nghiệm audit của tôi, hãy luôn kiểm tra xem contract có admin key, có Safety Module, và cộng đồng có quyền vote refund không. Nếu không, bạn đang chơi trò chơi mà nhà cái luôn thắng.