Tin tức 
Thông tin Coin 
Về chúng tôi 
Kelp DAO và *LayerZero* đang bước vào cuộc đối đầu gay gắt sau vụ tấn công cầu nối rsETH với thiệt hại lên tới khoảng 292 triệu USD (khoảng 4.246 tỷ đồng). Trọng tâm tranh cãi nằm ở câu hỏi: ai phải chịu trách nhiệm về cấu hình *trình xác thực (DVN)* trong hệ thống – bên thiết kế giao thức hay bên triển khai ứng dụng.
Theo The Block đưa tin ngày 24 (giờ địa phương), Kelp DAO cáo buộc *LayerZero* đã đồng ý với cấu trúc “1-of-1 DVN” ngay từ đầu, trong khi phía *LayerZero* lại xem đây là nguyên nhân chính dẫn đến lỗ hổng bảo mật trong báo cáo sau vụ việc.
“từ Kelp DAO”, “từ LayerZero”, “từ rsETH”, “từ cầu nối”, “từ DVN” sẽ được đề cập xuyên suốt bài viết này, xoay quanh câu chuyện trách nhiệm kỹ thuật và rủi ro hệ thống trong lĩnh vực *từ cầu nối đa chuỗi*.
Kelp: *LayerZero* từng nói “dùng mặc định cũng không sao”
Trong bản ghi nhớ mới được công bố, *từ Kelp DAO* khẳng định nhân sự của *từ LayerZero* đã xem xét trước và chấp thuận cấu trúc *1-of-1 DVN* trong quá trình tích hợp rsETH. Điều này trái ngược với báo cáo ngày 19 tháng 4 (giờ địa phương), nơi *LayerZero* cho rằng việc rsETH chỉ dựa vào một DVN đơn lẻ – đi ngược khuyến nghị “multi-DVN” – là gốc rễ của vụ hack.
Kelp cho biết trong suốt khoảng 2 năm rưỡi, hai bên đã có tổng cộng 8 lần trao đổi kỹ thuật về việc tích hợp, nhưng *LayerZero* không một lần cảnh báo rằng cấu trúc *1-of-1 DVN* tiềm ẩn rủi ro nghiêm trọng.
Một ảnh chụp màn hình Telegram được Kelp công bố cho thấy phía *LayerZero* từng phát biểu với nội dung “dùng cấu hình mặc định cũng không vấn đề gì”. Theo Kelp, “cấu hình mặc định (defaults)” này chính là mô hình 1-of-1 DVN – sau đó lại bị *LayerZero* nêu đích danh là nguyên nhân gây ra lỗ hổng bảo mật.
*bình luận* Việc một cấu hình được giới thiệu hoặc ngầm hiểu là “mặc định an toàn” nhưng sau đó bị quy là “lỗi thiết kế của người dùng” là điểm khiến cộng đồng tranh cãi gay gắt, bởi nó liên quan trực tiếp đến ranh giới trách nhiệm giữa nhà cung cấp hạ tầng và bên triển khai.
Tuy nhiên, các bản chụp màn hình mà Kelp đưa ra hiện chưa được bên thứ ba độc lập xác minh.
Thiết kế giao thức hay cấu hình ứng dụng: ai chịu trách nhiệm?
Kelp tiếp tục đưa ra thêm bằng chứng, cho rằng các tài liệu và bộ khởi tạo (template) của *LayerZero* đã “dẫn dắt” nhà phát triển chọn cấu trúc đơn DVN:
- Trong tài liệu *OFT Quickstart*, ví dụ mã nguồn trên GitHub và phần tài liệu hướng dẫn, mô hình DVN đơn lẻ được trình bày như lựa chọn mặc định, ít nhất là về mặt trải nghiệm người dùng.
- Phạm vi bug bounty của *LayerZero* loại trừ các lỗi do “cấu hình ứng dụng”. Theo đó, việc thiết lập và vận hành mạng lưới DVN, bao gồm cấu trúc 1-of-1 hay multi-DVN, được xem là trách nhiệm của bên phát triển ứng dụng.
Nhà nghiên cứu bảo mật Sujith Somraaj cho biết ông từng báo cáo một kịch bản tấn công có mẫu hình tương tự lên chương trình bug bounty của *LayerZero*, nhưng phía nền tảng không công nhận đây là lỗ hổng. Ông chia sẻ rằng các điều kiện bảo vệ được đưa vào lúc đánh giá bug bounty sau đó lại bị loại bỏ trong triển khai thực tế, và điều đó đã mở đường cho vụ hack gần 295 triệu USD.
*bình luận* Nếu lời của Somraaj chính xác, vấn đề không chỉ nằm ở “ai cấu hình sai” mà còn là “ai đánh giá sai rủi ro hệ thống” trong quá trình thiết kế và duyệt bảo mật nội bộ.
Cấu trúc tấn công: nghi ngờ dấu vết “Lazarus”
Vụ tấn công nhắm vào cầu nối *từ rsETH* đã gây thất thoát tổng cộng khoảng 116.500 rsETH, tương đương 292 triệu USD (khoảng 4.246 tỷ đồng). Ngoài ra, còn có hơn 100 triệu USD giao dịch giả mạo được hệ thống xử lý, dù không gắn trực tiếp với dòng tiền thực.
*LayerZero* cho rằng nhiều khả năng nhóm tấn công có liên hệ với tổ chức hacker Bắc Triều Tiên “Lazarus Group”. Theo phân tích của họ, quy trình tấn công diễn ra theo các bước:
- Kẻ tấn công có được danh sách node RPC mà DVN đang sử dụng.
- Chúng chiếm quyền điều khiển hai node, thay thế bằng binary độc hại.
- Tiếp theo, chúng thực hiện tấn công DDoS lên các node “sạch” còn lại, đẩy những node này vào trạng thái lỗi.
- Khi hệ thống tự động chuyển sang sử dụng các node bị chiếm quyền, kẻ tấn công bắt đầu phê duyệt những giao dịch “không hề tồn tại” trên chuỗi gốc, biến chúng thành các giao dịch hợp lệ trong mắt cầu nối.
Sau vụ việc, *LayerZero* khẳng định “giao thức đã hoạt động đúng như thiết kế”, ngụ ý rằng lỗi xuất phát từ cách cấu hình DVN chứ không phải từ bản thân cơ chế cốt lõi. Dù vậy, nền tảng này đã thay đổi chính sách, không cho phép cấu trúc 1-of-1 DVN tiếp tục tham gia ký thông điệp.
*bình luận* Phát biểu “hoạt động đúng như thiết kế” thường đúng theo nghĩa hẹp, nhưng lại dễ gây phản ứng mạnh khi người dùng chịu thiệt hại hàng trăm triệu USD. Nó đặt ra câu hỏi: nếu “thiết kế đúng” nhưng lại dễ bị cấu hình theo cách cực kỳ nguy hiểm, liệu thiết kế đó thực sự “an toàn” chưa?
Kelp rời *LayerZero*, chuyển sang *Chainlink* CCIP
Sau cú sốc bảo mật, *từ Kelp DAO* tuyên bố sẽ di dời hạ tầng *từ rsETH* khỏi *LayerZero* và chuyển sang *Cross-Chain Interoperability Protocol (CCIP)* của *Chainlink(LINK)*. Đây là một thay đổi hạ tầng căn bản, thể hiện sự sụt giảm nghiêm trọng mức độ tin cậy vào mô hình bảo mật của *LayerZero* trong mắt Kelp.
Không dừng lại ở đó, Kelp nhấn mạnh rằng cấu trúc 1-of-1 DVN không phải là trường hợp cá biệt. Dẫn số liệu từ CoinGecko và Dune Analytics, Kelp cho biết:
- Khoảng 47% toàn bộ OApp trên *LayerZero* đang sử dụng cấu trúc tương tự 1-of-1 DVN.
- Tổng tài sản đặt trên các cấu trúc này lên tới khoảng 4,5 tỷ USD (khoảng 6.546 tỷ đồng), đồng nghĩa với việc một lượng lớn tài sản có thể đối mặt rủi ro cùng kiểu.
Kelp cũng khẳng định chính họ là bên phát hiện dấu hiệu tấn công trước *LayerZero*, từ đó đặt dấu hỏi về hệ thống giám sát và ứng phó sự cố của nền tảng hạ tầng này.
*bình luận* Việc gần một nửa ứng dụng dựa trên *LayerZero* tùy chỉnh theo mô hình 1-of-1 DVN cho thấy vấn đề mang tính hệ thống, chứ không chỉ là “sai sót đơn lẻ” của một dự án. Điều đó đặt thêm áp lực lên các nền tảng cầu nối phải thiết kế lại “đường ray an toàn mặc định” cho nhà phát triển.
Ý nghĩa rộng hơn: tranh luận cũ trong bối cảnh mới
Cuộc đối đầu giữa *từ Kelp DAO* và *từ LayerZero* đang làm sống lại cuộc tranh luận cũ: đâu là ranh giới giữa “trách nhiệm thiết kế giao thức” và “trách nhiệm cấu hình ứng dụng”? Trong mảng *từ cầu nối* và *từ tương tác đa chuỗi*, nơi tài sản trị giá hàng tỷ USD di chuyển mỗi ngày, câu hỏi này mang tính sống còn.
- Nếu nhà cung cấp hạ tầng chỉ cần “cung cấp công cụ”, còn mọi rủi ro cấu hình do dự án tự gánh, cộng đồng sẽ tiếp tục chứng kiến những vụ hack trị giá trăm triệu USD.
- Ngược lại, nếu nền tảng gánh quá nhiều trách nhiệm, tốc độ đổi mới và sự linh hoạt kỹ thuật có thể bị kìm hãm.
Tranh cãi quanh *từ rsETH* và *từ LayerZero* cho thấy thị trường đang tiến gần tới giai đoạn mà các “mặc định an toàn” (secure defaults), tiêu chuẩn multi-DVN, cũng như ranh giới bug bounty sẽ phải được tái định nghĩa rõ ràng hơn.
Khi các cầu nối trở thành hạ tầng thiết yếu cho DeFi đa chuỗi, những bài học từ vụ hack 292 triệu USD này và màn “đổ lỗi qua lại” giữa *từ Kelp DAO* và *từ LayerZero* có thể trở thành tiền lệ quan trọng, buộc toàn ngành phải đánh giá lại mô hình *từ bảo mật cầu nối* từ gốc rễ – không chỉ ở code, mà còn ở cách chia sẻ trách nhiệm giữa các bên tham gia.
Bình luận 0