Tôi đã kiểm tra từng dòng mã của ba giao thức Layer 2 đang gây sốt trên Twitter trong tuần này. Kết quả: hai trong số đó có lỗ hổng xác thực có thể dẫn đến mất toàn bộ tài sản của người dùng nếu thanh khoản pool dưới 50 ETH. Đây không phải là tin đồn FUD – đây là phân tích từ mã nguồn mở mà bất kỳ ai cũng có thể clone về và chạy thử nghiệm.
Context Quý III năm 2025, thị trường tăng giá đã quay trở lại với cường độ chưa từng thấy. Bitcoin ETF được phê duyệt, hàng tỷ USD đổ vào các giao thức DeFi, và hàng loạt dự án Layer 2 mới ra mắt với lời hứa “TPS vô hạn” và “phí gas gần bằng 0”. Nhưng trong cơn sốt, các dự án này cạnh tranh bằng marketing chứ không phải chất lượng code. Là một Layer2 Research Lead, tôi nghiệm ra rằng thị trường tăng che giấu lỗi kỹ thuật – nhìn xuyên qua marketing bằng con mắt audit code. Trong bài viết này, tôi sẽ đưa bạn vào bên trong quy trình kiểm tra của tôi: từ phân tích mã Solidity, chạy mô phỏng giao dịch với các kịch bản tấn công, cho đến phát hiện ra điểm mù mà đội ngũ phát triển không muốn bạn biết.
Core: Phân tích kỹ thuật và điểm mù bảo mật Dự án thứ nhất là một optimistic rollup hứa hẹn “finality trong 2 giây”. Tôi clone repo, chạy test suite chính thức – tất cả đều xanh lá. Nhưng khi tôi viết một script mô phỏng chuỗi giao dịch liên tục với số lượng 500 lệnh chuyển token giữa các layer, tôi nhận ra rằng cơ chế fraud proof bị delay khi số lượng sequencer vượt quá 5 node. Cụ thể: mã nguồn trong FraudProof.sol sử dụng một vòng lặp for để xử lý từng transaction trong block, nhưng không có giới hạn gas cho vòng lặp này. Trong trường hợp block chứa hơn 1000 giao dịch (hoàn toàn khả thi khi TVL đạt 500 triệu USD), hàm challenge() sẽ hết gas và revert – dẫn đến việc tất cả các fraud proof đều bị bỏ qua. Tôi đã gửi một pull request với bản vá: thêm checkpoint sau mỗi 200 transaction và sử dụng cơ chế batch proof. Đội ngũ dự án phản hồi: “Chúng tôi biết điều này, nhưng ưu tiên hiện tại là ship mainnet.” – đây chính là vết nứt.
Dự án thứ hai sử dụng zero-knowledge rollup với cam kết “không cần trusted setup”. Khi tôi kiểm tra mã nguồn của contract verifier, tôi phát hiện một lỗi trong việc xử lý proof aggregation: hàm verifyBatchProofs không kiểm tra tính duy nhất của publicInputs. Điều này cho phép kẻ tấn công gửi cùng một proof hợp lệ nhiều lần để rút token từ nhiều lần khác nhau. Tôi đã chạy mô phỏng trên testnet với số dư giả định 10 ETH – trong vòng 3 phút, tôi có thể rút toàn bộ pool thanh khoản nếu không có cơ chế chặn. Đây là một lỗi bảo mật cấp độ critical, nhưng đội ngũ dự án vẫn quảng cáo “audited by Trail of Bits” – thực tế bản audit đó chỉ kiểm tra phiên bản v0.1, trong khi họ đã deploy v0.2 với thay đổi code.
Phân tích dữ liệu on-chain cho thấy một thực tế khác Tôi scrape dữ liệu on-chain của hai dự án này từ tháng 6 đến tháng 9/2025. Kết quả: dự án thứ nhất có 12 giao dịch đáng ngờ với giá trị >10 ETH mà fraud proof không được kích hoạt (có thể do lỗi delay). Dự án thứ hai có 3 giao dịch withdrawal với cùng một proof (một dấu hiệu của tấn công replay). Tôi đã liên hệ với team bảo mật của cả hai – một dự án không trả lời, dự án còn lại nói “đang điều tra”. Trong khi đó, TVL của họ đã tăng 300% trong tháng qua nhờ các chiến dịch airdrop.
Contrarian: Góc nhìn phản trực giác Nhiều người cho rằng audit của các công ty lớn (Trail of Bits, OpenZeppelin) là đủ tin cậy. Nhưng kinh nghiệm 5 năm audit code của tôi cho thấy: audit chỉ kiểm tra phiên bản code tại thời điểm đó – không ai audit commit mới nhất sau khi deploy. Các dự án thường xuyên thay đổi logic để fix lỗi gas hoặc thêm tính năng, nhưng không chạy lại audit. Điều này tạo ra một kẽ hở mà tôi gọi là “audit window”: khoảng thời gian giữa lần audit cuối và thời điểm deploy thực tế, nơi mà các lỗi mới có thể được introduce. Với thị trường tăng, áp lực ship feature rất lớn – team thường bỏ qua bước internal review. Đây không phải là conspiracy, mà là thực tế kỹ thuật.
Một điểm mù khác: hầu hết các dự án Layer 2 đều sử dụng cơ chế “emergency pause” để tạm dừng hợp đồng trong trường hợp khẩn cấp. Nhưng khi tôi phân tích mã của dự án thứ hai, tôi thấy rằng pause() chỉ được gọi bởi một multisig 2-of-3, và trong đó có một signer là founder. Điều này vi phạm nguyên tắc phi tập trung hóa: một người có thể chặn toàn bộ hệ thống. Họ gọi đó là “tính linh hoạt” – tôi gọi đó là rủi ro censorship.
Takeaway Thị trường tăng không làm cho lỗi biến mất – nó chỉ làm cho chúng ít bị chú ý hơn. Nếu bạn đang đầu tư vào bất kỳ dự án Layer 2 nào, hãy tự mình clone repo, chạy mô phỏng với kịch bản tấn công. Nếu bạn không làm được, ít nhất hãy yêu cầu đội ngũ cung cấp link đến mã nguồn của phiên bản đang chạy thực tế (không phải phiên bản audit). Vết nứt nào cũng có lối vào – nhưng lối vào đó sẽ dẫn đến mất tiền nếu bạn không cẩn thận. Và câu hỏi cuối cùng: Khi thị trường điều chỉnh, ai sẽ là người gánh chịu những lỗi này? Người dùng bán lẻ, như mọi khi.