- Dune vừa công bố phân tích mở trên ~2,665 OApp LayerZero active trong 90 ngày qua: 47% đang chạy sàn bảo mật 1-of-1 DVN — đúng cấu hình đã khiến rsETH của KelpDAO bị hút 116,500 token trị giá $290M hôm 18/04.
- Bài này bóc tách con số, cách khai thác, và vì sao tranh cãi 'nâng multi-DVN' có thể chưa phải là liều thuốc thật.
TL;DR
Sau vụ hack KelpDAO làm bay 116,500 rsETH (~$290M) vào 18/04/2026, Dune công bố một phân tích on-chain mở trên ~2,665 OApp LayerZero active trong 90 ngày qua. Kết quả gây choáng: 47% đang chạy sàn bảo mật 1-of-1 DVN — đúng cấu hình đã bị khai thác ở Kelp — 45% chạy 2-of-2, và chỉ ~5% dùng 3-of-3 trở lên. Một kẽ hở cấu hình đơn lẻ đang phơi bày hàng tỷ USD tài sản cross-chain. Nhưng sửa bằng cách nâng số DVN có thể chỉ là 'marketing copy' nếu các verifier vẫn đọc từ cùng một cụm RPC.
Dune công bố gì?
Ngày 20/04, Dune Analytics đăng một phân tích mở về cấu hình DVN (Decentralized Verifier Network) của toàn bộ OApp đang hoạt động trên LayerZero trong 90 ngày gần nhất. Phương pháp, truy vấn SQL và bộ dữ liệu đều public — ai cũng có thể fork về chạy lại hoặc tranh luận về định nghĩa 'active'.
Phân tích quét ~2,665 hợp đồng OApp duy nhất và phân loại theo sàn bảo mật — tức cấu hình DVN tối thiểu mà OApp đó yêu cầu để pass một message cross-chain. Ba nhóm lớn:
- 47% — 1-of-1 DVN: chỉ cần 1 verifier duy nhất xác nhận, không có optional DVN dự phòng. rsETH của KelpDAO nằm trong nhóm này.
- 45% — 2-of-2 DVN: cần 2 verifier độc lập cùng ký mới cho message đi qua.
- ~5% — 3-of-3 hoặc cao hơn: đa chữ ký với dư thừa thật sự.
Nói cách khác: gần một nửa cầu nối cross-chain trên hệ LayerZero đang treo tất cả niềm tin lên một chữ ký duy nhất.
Vì sao con số này quan trọng?
Trước 18/04, nhiều team coi 1-of-1 là 'default hợp lý' vì chính LayerZero V2 OApp Quickstart và layerzero.config.ts mẫu trên GitHub cấu hình sẵn 1 required DVN + 0 optional DVN. Hậu Kelp, mặc định đó không còn là vùng an toàn — đó là bản đồ mục tiêu. Kẻ tấn công nhìn vào dataset của Dune và nhìn thấy khoảng 1,250 OApp còn lại vẫn đang dùng cùng cấu trúc đã nuốt $290M.
Vấn đề sâu hơn: đây là vụ hack DeFi thứ hai vượt $290M trong 17 ngày (Drift mất $285M ngày 01/04 qua social engineering multisig). Cả hai đều không phải lỗi smart contract. Cả hai đều vì bề mặt tấn công đã dịch chuyển sang hạ tầng off-chain — khóa ký, RPC, con người. Audit Solidity sạch không còn đủ.
Technical facts: vụ Kelp xảy ra như thế nào
Để hiểu vì sao 1-of-1 là chí tử, cần mổ xẻ attack chain ở Kelp:
- Target: KelpDAO Ethereum OFTAdapter tại
0x85d456B2...e98Ef3, giữ reserve rsETH. - Config:
requiredDVN=1(chỉ LayerZero Labs DVN ở0x589dedbd...294236b),optionalDVN=0. - Bước 1: Attacker compromise 2 RPC node độc lập mà LayerZero Labs DVN dùng để đọc chain state, swap binary op-geth bằng payload độc hại — chỉ forge message cho DVN, trong khi vẫn trả về kết quả thật cho bất kỳ IP nào khác (qua mặt observability).
- Bước 2: Attacker DDoS các RPC không bị compromise trong khung 10:20a–11:40a PT, ép DVN failover sang node đã bị đầu độc.
- Bước 3: DVN xác nhận một transaction không hề tồn tại trên Unichain.
lzReceiverelease 116,500 rsETH (~$292M) từ escrow về ví attacker. - Bước 4: Packet forge thứ hai (nonce 309) nhắm thêm 40,000 rsETH (~$100M) bị chặn 46 phút sau nhờ emergency multisig của Kelp pause hợp đồng kịp.
Không hợp đồng nào bị hack theo nghĩa code-level. OFTAdapter hoạt động đúng như thiết kế — nó tin DVN. Một chữ ký sai của một DVN có quyền ký mọi thứ. LayerZero quy attribution cho DPRK Lazarus / TraderTraitor.
1-of-1 vs 2-of-2 vs góc nhìn phản biện
| Config | Attacker phải làm gì | Chi phí |
|---|---|---|
| 1-of-1 | Compromise 1 DVN (hoặc upstream RPC của nó) | Thấp — Kelp đã chứng minh |
| 2-of-2 (operator khác nhau) | Compromise đồng thời 2 hạ tầng verification độc lập | Cao hơn đáng kể |
| 2-of-N với threshold optional | Tương tự + vượt threshold các optional DVN | Rất cao nếu đa dạng thực sự |
Khuyến nghị chính thức của LayerZero từ lâu đã là multi-DVN với diversity. Nhưng nhà phân tích The Smart Ape chỉ ra một lỗ hổng mà con số '2-of-2' không che được: nếu 5 DVN 'độc lập' cùng đọc chain state từ 3 RPC provider clustering trên AWS/GCP, attacker đầu độc 3 RPC đó sẽ đánh lừa cả 5 verifier cùng lúc. 'Nếu tất cả verifier bị lừa cùng một cách tại cùng một lúc, phép toán quay về 1-of-1. Năm bản sao không phải là năm nhân chứng.'
Developer Yearn banteg (Artem K) review public deployment code của LayerZero và xác nhận cấu hình mẫu trên Ethereum, BSC, Polygon, Arbitrum, Optimism đều ship mặc định 1-of-1. Còn Zach Rynes (Chainlink community) công khai cáo buộc LayerZero 'đẩy trách nhiệm' sang Kelp trong khi chính hạ tầng bị compromise là hạ tầng LayerZero vận hành.
Protocol nên làm gì ngay?
- Audit config ngay: gọi
getConfigtrên EndpointV2 cho từng pathway. NếurequiredDVNCount==1 && optionalDVNCount==0→ pathway rủi ro cao nhất, treat như incident. - Migrate lên ≥2-of-N: chọn 2 required DVN từ operator khác nhau (ví dụ LayerZero Labs + Google Cloud, hoặc Polyhedra). Hai operator phải độc lập về team, cloud, client software.
- Optional DVN threshold: thêm 1–2 optional DVN với threshold=1 để có lớp defense-in-depth mà không hy sinh liveness.
- Match bảo mật với escrow: OFTAdapter giữ $100M+ thì mọi pathway vào đó phải strict nhất có thể.
- Pre-tx limit + monitoring: cap số token có thể release trong 1 tx. Monitor off-chain cho 'message xác nhận nhưng không có tx gốc trên source chain' — chính là pattern forge packet.
- Audit upstream topology: không chỉ đếm DVN, mà hỏi mỗi DVN đang đọc từ RPC nào, client nào, cloud nào. Nếu trùng → 'multi-DVN' chỉ là giấy.
Giới hạn & giá
Phân tích Dune đếm số verifier, không map được upstream topology. Nó không thể cho biết 2 DVN trong cấu hình 2-of-2 có đang chia sẻ cùng một RPC provider hay không — đúng lỗ hổng mà nhóm phản biện nhấn mạnh. Đây cũng là snapshot 90 ngày; configs có thể đổi qua setConfig bất kỳ lúc nào.
Toàn bộ phương pháp là public, free — ai cũng fork query trên Dune về chạy. Không có paywall, không API key. Đó chính là điểm mạnh: ép tranh luận diễn ra trên data chung thay vì đoán mò.
What's next
LayerZero đã tuyên bố không còn ký message cho app chạy 1-of-1, ép migration toàn hệ. Team đang trực tiếp contact từng OApp trong nhóm 47% để chuyển config. Câu hỏi mở:
- Bao nhiêu OApp thực sự migrate — hay chỉ tắt bridge và rút sang chỗ khác?
- Ai sẽ kiểm toán upstream topology của các DVN 'độc lập' để không lặp lại trò RPC-clustering?
- Mặc định trong repo quickstart của LayerZero có được đổi thành 2-of-2 không? Banteg đã mở PR ý tưởng này.
- Tranh chấp Kelp ↔ LayerZero có dẫn tới khung trách nhiệm mới giữa 'bridge infra provider' và 'bridge consumer' không?
Bài học lớn nhất: smart contract audit là điều kiện cần, không đủ. Bề mặt tấn công đã dịch chuyển sang off-chain infra, key management và trust assumptions. Con số 47% là một gậy đánh thức, nhưng giải pháp thật sự phải sâu hơn phép cộng.
Nguồn: Dune, The Defiant, Blockaid, LayerZero, CoinDesk, NewsBTC.