Đào mã thấy lỗi, im lặng là vàng.
Hai tuần trước, tôi ngồi trước bảng phân tích của một bridge L2 mới. Code của nó chạy trên OP Stack. Tôi lướt qua hàm finalizeWithdrawal – một pattern quen thuộc. Nhưng có một dòng lạ: require(proof.length == 32);. 32? Không phải 32 bytes của merkle proof, mà là proof length tính bằng số lượng node. Một lỗi cắt xén dữ liệu. Ai deploy chain này chắc chắn không đọc kỹ spec của Optimism. Họ copy code mẫu, sửa vài tham số, rồi launch. Im lặng. Đó là lý do tại sao tôi nói: sự khác biệt thực sự giữa OP Stack và ZK Stack không nằm ở công nghệ – mà là ai thuyết phục được nhiều dự án deploy chain trước. Và khi càng nhiều chain được deploy vội vã, bảo mật càng bị xem nhẹ.
Context: Cuộc đua deploy chain
Năm 2023, Optimism ra mắt OP Stack – một bộ công cụ cho phép bất kỳ ai launch một L2 riêng chỉ trong vài ngày. Base của Coinbase là ví dụ điển hình. ZK Stack của zkSync cũng làm điều tương tự, nhưng với công nghệ zero-knowledge. Từ góc nhìn kỹ thuật, ZK có ưu thế về security proof: không cần trust window, không cần challenge period. Nhưng thị trường lại chọn OP Stack. Tính đến tháng 5/2025, có hơn 40 chain dùng OP Stack, so với chưa tới 10 chain dùng ZK Stack. Lý do? Dễ deploy, cộng đồng lớn, tài liệu dày. ZK Stack yêu cầu hiểu biết sâu về toán học, còn OP Stack chỉ cần biết Solidity và copy-paste. Hệ quả: một loạt chain non-experienced ra đời, và lỗ hổng bắt đầu xuất hiện.
Core: Phân tích kỹ thuật – Code là thước đo cuối cùng
Tôi đã audit 5 chain dùng OP Stack trong năm qua. Mỗi chain đều có một điểm chung: họ sửa đổi logic gốc của Optimism mà không hiểu rõ tác động. Ví dụ điển hình: cơ chế Sequencer – điểm tập trung hóa của OP Stack. Trong standard OP Stack, sequencer có quyền forceInclude để đưa giao dịch vào block ngay lập tức. Một team nọ đã loại bỏ giới hạn gas cho sequencer, biến nó thành "siêu người dùng". Họ nghĩ rằng điều này tăng throughput. Sai. Nó tạo ra một vector tấn công: sequencer có thể spam block với chi phí thấp, gây ra tắc nghẽn mạng và làm trì hoãn các withdrawal.
Một lỗi khác tôi gặp: OptimismPortal contract – cửa ngõ giữa L1 và L2. Họ thêm một hàm setL2OutputOracle mới, cho phép admin cập nhật oracle mà không cần delay. Điều này phá vỡ bảo mật của proof-of-fraud. Nếu admin bị compromise, kẻ tấn công có thể ghi đè output oracle và rút tiền từ bridge mà không cần chứng minh. Đây là lỗi access control cơ bản. Nhưng team đó đã deploy lên mainnet. Họ dựa vào "audit của bên thứ ba" – một công ty chỉ scan tự động. Kết quả: 1,200 ETH bị mất sau hai tháng. Im lặng.
So sánh với ZK Stack: các chain dùng ZK thường được phát triển bởi đội ngũ có background formal verification. Họ hiểu rằng một lỗi nhỏ trong zk-circuit có thể làm sập toàn bộ hệ thống. Vì vậy, họ đầu tư vào audit nghiêm túc. Nhưng ZK Stack cũng có điểm yếu: sự phức tạp của prover. Tôi đã thấy một chain ZK dùng Plonk với setup ceremony sai, dẫn đến khả năng tạo proof giả. Vấn đề không phải công nghệ, mà là con người. Người dùng OP Stack thường ít kinh nghiệm hơn, họ deploy nhanh và bỏ qua các bước kiểm tra.
Contrarian: Điểm mù bảo mật không ai nói
Cộng đồng thường nghĩ OP Stack "an toàn vì được Optimism kiểm duyệt". Sai. Mỗi chain fork OP Stack là một thực thể riêng, với các tham số tùy chỉnh. Optimism không chịu trách nhiệm cho các fork. Họ chỉ cung cấp code gốc. Vấn đề nằm ở văn hóa "deploy first, audit later". Khi thị trường tăng, ai cũng muốn ra mắt nhanh. Các VC thúc đẩy TVL. Họ bỏ qua bảo mật. Thanh khoản cạn, bẫy còn đó. Tôi dự đoán trong 6 tháng tới, sẽ có ít nhất 5 chain OP Stack bị hack do lỗi cấu hình. Điểm chung: tất cả đều là những chain không có audit độc lập, hoặc audit chỉ cover surface basic.
Một điểm mù khác: tương tác giữa các chain OP Stack. Khi bạn có nhiều L2 cùng dùng chung bridge, một lỗ hổng trên chain A có thể lan sang chain B nếu chúng chia sẻ cùng L1CrossDomainMessenger. Tôi đã thấy một trường hợp: chain A và B dùng cùng một contract trên L1, nhưng chain A có bug trong hàm relayMessage. Kẻ tấn công khai thác chain A, gửi một message độc hại lên L1, sau đó relay sang chain B. Chain B không kiểm tra nguồn gốc của message. Hậu quả: cả hai chain mất tiền. Đây là lỗi thiết kế hệ thống, không phải lỗi code đơn lẻ.
Takeaway: Câu hỏi cho tương lai
DeFi không tha thứ cho mã nguồn cẩu thả. Nhưng điều đáng lo hơn là sự ỷ lại: người dùng tin rằng OP Stack là an toàn vì nó được dùng bởi Base. Họ không biết rằng Base có đội ngũ bảo mật riêng, còn chain của bạn thì không. Câu hỏi đặt ra: liệu sự phát triển nhanh của hệ sinh thái OP Stack có đang tạo ra một "bom nổ chậm" bảo mật? Các auditor như tôi đang đếm ngược. Khi thị trường downtrend, thanh khoản rút ra, các lỗ hổng sẽ lộ diện. Đào mã thấy lỗi, im lặng là vàng. Nhưng vàng đó, cuối cùng, sẽ thuộc về ai?