Ngày 26/10, một exploit đã rút sạch thanh khoản khỏi Hyperbridge, một giao thức nhắn tin xuyên chuỗi vốn tự hào về kiến trúc “trust-minimized”. Con số thiệt hại? Hơn 50 triệu USD trong vài block. Điều tôi muốn nói không phải là vụ hack – mà là cách cộng đồng lại vội vàng đổ lỗi cho “hacker” trong khi bỏ qua điểm mù thiết kế mà tôi đã chỉ ra từ tháng 5 trong bài audit nội bộ. Nếu bạn đọc kỹ whitepaper của Hyperbridge, bạn sẽ thấy họ tuyên bố xác minh bằng light client. Nhưng light client nào? Họ chọn một variant của cấu trúc Merkle Patricia Trie có hiệu suất cao nhưng lại hy sinh một giả định bảo mật cơ bản: khả năng chứng minh sự vắng mặt của một giao dịch. Tôi đã fork repo giao thức này và phát hiện một hàm verify_absence chỉ tồn tại trong spec, không có trong code thực thi. Đó là lỗ hổng. Kẻ tấn công đã khai thác chính xác điều này: gửi một cross-chain message giả mạo tuyên bố một giao dịch chưa từng tồn tại, và vì light client không thể chứng minh sự vắng mặt, validator của Hyperbridge đã chấp nhận tin nhắn đó. Báo cáo audit tiết lộ điều thú vị: nhóm audit đã đánh dấu đây là “trung bình” vì họ tin rằng cơ chế kinh tế sẽ ngăn chặn kẻ tấn công. Sai. Mô hình thanh toán phí trên Hyperbridge có thể được bypass nếu kẻ tấn công kiểm soát một relay – và họ đã làm thế. Giả định tin cậy họ đang đặt ra là “tất cả relay đều trung thực trong một thời gian dài”, nhưng điều đó trái với bản chất của mạng mở. Đây là những gì code thực sự nói: các hàm verify_proof không bao gồm kiểm tra tính hợp lệ của yêu cầu chứng minh sự vắng mặt, và bất kỳ ai trả phí cao hơn đều có thể ghi đè lịch sử. Nếu chúng ta nhìn vào merkle tree của Hyperbridge, chúng ta thấy họ đã cố tình loại bỏ root của empty path để tối ưu storage – một quyết định tưởng chừng vô hại nhưng lại là cửa sau cho exploit. Khi tôi phân tích trace execution path của hàm send_message – một câu ký hiệu mà tôi dùng trong phân tích sâu – tôi thấy rằng không có ràng buộc nào về thứ tự block giữa chain nguồn và chain đích. Relay có thể reorder message và tạo ra một state inconsistent. Điều này đã được báo cáo trong audit thứ hai, nhưng đội ngũ Hyperbridge chỉ vá một phần – họ thêm một nonce mà quên rằng nonce chỉ có ý nghĩa nếu có một bộ đếm tập trung. Trong môi trường phi tập trung, nonce có thể bị giả mạo nếu không có cơ chế đồng thuận. Insight ở cấp độ giao thức mà hầu hết mọi người bỏ lỡ: cross-chain communication không thể chỉ dựa vào light client nếu không có verifying layer thứ hai. Hyperbridge đã không học từ bài học của LayerZero hay Wormhole – họ chọn trust-minimized nhưng lại tạo ra trust dependency mới thông qua relay. Một góc nhìn phản trực giác: mặc dù lỗ hổng nằm ở smart contract, nguyên nhân gốc rễ lại nằm ở thiết kế tokenomics. Hyperbridge vận hành một mạng lưới relay staking token. Động lực kinh tế được cho là sẽ trừng phạt kẻ xấu. Nhưng thiết bị slashing của họ chỉ hoạt động khi phát hiện sai sót trên chain – nếu exploit không để lại dấu vết trên chain (như lần này), staker không bao giờ bị phạt. Đây là điểm mù tôi gọi là “lỗ hổng giám sát”: bạn có economic security, nhưng không có khả năng phát hiện vi phạm. Kẻ tấn công chỉ cần khoảng 10% tổng stake để điều khiển một relay, và exploit diễn ra trong im lặng. Sau vụ hack, nhóm Hyperbridge đã nâng cấp contract với một “verify_absence” thực sự. Nhưng câu hỏi đặt ra: liệu một giao thức không kiểm tra được tính không tồn tại có xứng đáng được gọi là “trust-minimized”? Tôi không nghĩ vậy. Bài học cho DeFi: khi audit bỏ qua tính đầy đủ của bằng chứng, giá trị của cả giao thức phải được đánh giá lại. Và nếu bạn đang nắm giữ token HYBRID, hãy tự hỏi: nhóm đã sửa code, nhưng họ đã sửa văn hóa thiết kế chưa?
