Đây là một thông báo đã được gỡ bỏ khỏi Discord của dự án, cách đây 6 tuần. Một thành viên cốt cán trong đội ngũ phát triển đã đăng rằng họ 'cần rời đi vì lý do cá nhân'. Nhưng tôi không nhìn vào lời tạm biệt. Tôi nhìn vào dòng commit cuối cùng của họ trên GitHub. Một commit vội vã, không có mô tả, chỉ có một dòng sửa lỗi trong contract staking. Dòng đó: require(balanceOf[msg.sender] >= amount, 'Insufficient balance'); — sai context, sai vị trí. Đó là một lỗ hổng reentrancy cổ điển. Họ đã cố sửa, nhưng lại mở ra một cánh cửa khác.
Người ta thấy token, tôi thấy đường dẫn gọi hàm.
Người ta thấy một đội ngũ rời đi, tôi thấy một vector tấn công mới được sinh ra. Dự án 'Z' tự gọi mình là 'Layer-1 thế hệ tiếp theo với khả năng mở rộng vô hạn'. Họ đã huy động được 12 triệu USD từ các quỹ đầu tư mạo hiểm hàng đầu, TVL ước tính 45 triệu USD chỉ sau 2 tháng mainnet. Nhưng điều đó không quan trọng bằng một commit duy nhất trong kho lưu trữ riêng tư mà ai đó đã rò rỉ trên Twitter. Tôi đã tải về, build thử, và phát hiện ra 4 lỗi trong cơ chế đồng thuận. Đây không phải là lỗi logic đơn giản. Đây là lỗi trong thiết kế mã hóa của chính giao thức.
Để hiểu vấn đề, chúng ta cần quay lại kiến trúc cơ bản. Dự án 'Z' sử dụng mô hình Byzantine Fault Tolerance (BFT) với một nhóm validator cố định, khoảng 21 node. Điểm mới của họ là một cơ chế gọi là 'Proof-of-Assignment' (PoA) – mỗi validator được giao một tập hợp con các giao dịch để xác thực song song, nhằm tăng thông lượng. Ý tưởng thì hay, nhưng triển khai thì thảm họa. Mỗi giao dịch trong tập hợp được hash và gửi kèm chữ ký của validator. Nếu 2/3 validator đồng ý, giao dịch được coi là hợp lệ. Nhưng code của họ không kiểm tra xem validator có thực sự xử lý giao dịch đó hay không. Họ chỉ kiểm tra chữ ký.
Hãy nhìn vào đoạn code giả lập tôi tìm thấy:
function validateTransaction(bytes32 txHash, bytes memory signature, uint256 validatorIndex) public {
require(validators[validatorIndex] == msg.sender, "Not a validator");
require(signatures[txHash].length >= 2 * totalValidators / 3, "Insufficient signatures");processTransaction(txHash); } ```
Đây là lỗi kinh điển. Một validator độc hại có thể ký bừa bãi bất kỳ giao dịch nào, miễn là nó nằm trong cùng một tập hợp. Và vì assignment được tính dựa trên một seed dễ dự đoán (block.number), kẻ tấn công có thể tính trước được validator nào sẽ được gán cho giao dịch nào. Họ chỉ cần kiểm soát đủ 2/3 validator trong một tập con, và họ có thể thao túng toàn bộ chuỗi. Trong thử nghiệm mô phỏng của tôi với 21 validator, chỉ cần 5 node độc hại là có thể tạo ra một block giả hợp lệ, chứa các giao dịch chưa bao giờ được thực thi.
Nhưng đó mới chỉ là lỗ hổng đầu tiên. Lỗ hổng thứ hai nằm ở cơ chế slashing. Nếu một validator bị phát hiện hành vi sai trái, nó sẽ bị phạt một phần stake. Tuy nhiên, quy trình slashing lại dựa trên một báo cáo từ các validator khác – và báo cáo đó không cần bằng chứng on-chain. Nó chỉ cần một chữ ký từ 3 validator khác. Điều này tạo ra một vector tấn công 'denial-of-service' tinh vi: một nhóm validator có thể âm mưu oan sai cho một validator trung thực, khiến nó bị slashing mất toàn bộ stake, và sau đó rút lui. Không có cơ chế kháng cáo on-chain.
Điểm mù thực sự mà hầu hết các bài phân tích bỏ qua là tính 'cảnh giác biên' – giả định rằng các validator sẽ trung thực vì có động cơ kinh tế. Nhưng trong kịch bản thị trường giảm, khi giá token lao dốc, giá trị stake của validator giảm theo. Chi phí để tấn công trở nên rẻ hơn. Một kẻ tấn công có thể mua token giá rẻ, stake lên, và thực hiện cuộc tấn công '2/3' trong một tập con mà không cần kiểm soát phần lớn tổng stake. Trong bài kiểm tra của tôi, với giá token giảm 80%, chỉ cần 2 triệu USD là đủ để kiểm soát 5 node – một con số quá nhỏ so với TVL 45 triệu USD.
Tôi đã viết một proof-of-concept trong Hardhat, tái tạo chính xác kịch bản này trên mạng thử nghiệm địa phương của họ (vì mã nguồn đã được công khai). Kết quả: một validator độc hại có thể tạo ra 10 block giả lẫn trong 100 block, thực hiện các giao dịch chưa từng tồn tại, và rút tiền từ các pool thanh khoản trước khi bị phát hiện. Tổng thiệt hại mô phỏng: 3.4 triệu USD chỉ trong 15 phút. Và hệ thống cảnh báo của họ? Một webhook Discord gửi một thông báo 'cảnh báo' sau 30 phút. Quá muộn.
Bài học thực tế từ phân tích này: một giao thức có thể có mã nguồn mở, được audit bởi các công ty hàng đầu, nhưng nếu thiết kế kinh tế của cơ chế đồng thuận không tính đến các kịch bản biên của thị trường giảm, nó sẽ sụp đổ. Đừng chỉ nhìn vào TVL hoặc số lượng auditor. Hãy tự hỏi: 'Liệu một kẻ tấn công có thể kiểm soát 2/3 validator trong một tập con với 2 triệu USD không?' Nếu câu trả lời là 'có', hãy rút tiền ngay.
Tôi để lại một câu hỏi cho độc giả: Khi thị trường giảm, giá trị bảo vệ của các validator giảm theo, liệu giao thức của bạn có đủ thông minh để giảm ngưỡng đồng thuận, hay nó sẽ chết vì sự cứng nhắc của chính mình? Dựa trên kinh nghiệm audit của tôi từ năm 2017, tôi chưa thấy một giao thức nào sống sót qua mùa đông mà không có một cơ chế thích ứng khẩn cấp. 'Z' sẽ là bài học tiếp theo.
