Một công cụ AI mã nguồn mở không ai chú ý đã cảnh báo về lỗ hổng bảo mật trị giá 292 triệu USD của Kelp DAO cách đây 12 ngày
Tuyển chọn TechFlowTuyển chọn TechFlow
Một công cụ AI mã nguồn mở không ai chú ý đã cảnh báo về lỗ hổng bảo mật trị giá 292 triệu USD của Kelp DAO cách đây 12 ngày
Agent AI có thể trở thành lớp bảo mật độc lập cho các nhà đầu tư DeFi.
Chuyên sâu báo cáo Web3Tác giả: Zengineer
Biên dịch: TechFlow
Giới thiệu của TechFlow: Vào ngày 18 tháng 4, Kelp DAO bị tấn công và đánh cắp 292 triệu USD — đây là sự cố DeFi lớn nhất từ đầu năm 2026 đến nay. Lỗ hổng không nằm trong mã hợp đồng, mà ở cấu hình nút xác minh 1-trong-1 (1-of-1) của cầu nối chéo chuỗi LayerZero — chỉ cần một nút duy nhất bị xâm nhập là kẻ tấn công có thể giả mạo thông điệp chéo chuỗi. Chính tác giả đã phát hiện rủi ro này trước đó 12 ngày khi quét Kelp bằng công cụ kiểm toán AI mã nguồn mở do mình phát triển. Bài viết này tái dựng toàn bộ quá trình tấn công, đồng thời trung thực phản tư ba điểm mà công cụ chưa làm đúng.
Kelp DAO là gì?
Kelp DAO là một giao thức tái ký quỹ thanh khoản được xây dựng trên nền tảng EigenLayer. Cơ chế hoạt động như sau: Người dùng gửi ETH hoặc các token ký quỹ linh hoạt (stETH, ETHx) vào hợp đồng Kelp; hợp đồng này sau đó ủy quyền tài sản cho các nút vận hành trên EigenLayer để tái ký quỹ — đồng thời cung cấp tính bảo mật cho nhiều AVS (Dịch vụ Xác minh Chủ động – Actively Validated Services). Đổi lại, người dùng nhận được token rsETH làm chứng nhận. Khác với việc tái ký quỹ trực tiếp trên EigenLayer (khi tài sản bị khóa), rsETH là token có tính thanh khoản — có thể giao dịch, dùng làm tài sản thế chấp trên các giao thức cho vay như Aave, hoặc chuyển chéo chuỗi.
Để đạt được tính thanh khoản chéo chuỗi này, Kelp sử dụng tiêu chuẩn OFT (Omnichain Fungible Token – Token đồng nhất đa chuỗi) của LayerZero để triển khai rsETH trên hơn 16 chuỗi. Khi bạn chuyển rsETH từ Ethereum sang một L2 nào đó, Mạng xác minh phân tán (Decentralized Verifier Network – DVN) của LayerZero sẽ xác thực tính hợp lệ của thông điệp chéo chuỗi này. Chính kiến trúc cầu nối này là trung tâm của câu chuyện phía sau.
Kelp được khởi xướng bởi Amitej Gajjala và Dheeraj Borra (trước đây là đồng sáng lập Stader Labs), ra mắt vào tháng 12 năm 2023, đạt TVL cao nhất là 2,09 tỷ USD, và áp dụng cơ chế quản trị đa chữ ký 6/8 kết hợp khóa thời gian nâng cấp hợp đồng 10 ngày. Token quản trị KERNEL điều phối cả ba dòng sản phẩm Kelp, Kernel và Gain.
Sự kiện bị đánh cắp
Vào ngày 18 tháng 4 năm 2026, kẻ tấn công đã rút khỏi cầu nối chéo chuỗi của Kelp DAO tổng cộng 116.500 rsETH, tương đương khoảng 292 triệu USD — đây là cuộc tấn công DeFi lớn nhất từ đầu năm 2026 đến nay. Nguyên nhân gốc rễ không phải là lỗ hổng hợp đồng thông minh, mà là một sai sót cấu hình: thiết lập DVN dạng 1-trong-1 (chỉ có một nút xác minh duy nhất, và chỉ cần một chữ ký là đủ để thông qua) khiến kẻ tấn công có thể giả mạo thông điệp chéo chuỗi chỉ bằng cách chiếm quyền một nút duy nhất.
12 ngày trước đó, vào ngày 6 tháng 4, công cụ kiểm toán bảo mật mã nguồn mở do tôi phát triển đã xác định và gắn nhãn điểm tấn công này.
Trước hết, cần nhấn mạnh: Vụ đánh cắp lần này là thiệt hại thật do con người thật gây ra. Những người gửi WETH vào Aave — dù chưa từng chạm tới rsETH — cũng bị đóng băng tài sản; các nhà cung cấp thanh khoản (LP) trên nhiều giao thức buộc phải gánh chịu tổn thất xấu mà họ hoàn toàn không ký cam kết đảm nhiệm. Bài viết này phân tích những gì đã xảy ra và công cụ của chúng tôi đã phát hiện điều gì — nhưng chi phí thực tế mà con người phải trả còn quan trọng hơn bất kỳ bảng xếp hạng nào.
Báo cáo đầy đủ được đăng tải trên GitHub, với dấu thời gian commit có thể kiểm chứng bởi bất kỳ ai. Phần tiếp theo sẽ trình bày những gì công cụ chúng tôi đã bắt được, những gì đã bỏ sót, và ý nghĩa của sự việc này đối với các công cụ bảo mật DeFi.
46 phút — Chấn động DeFi
Vào lúc 17:35 UTC ngày 18 tháng 4, kẻ tấn công đã chiếm quyền nút DVN cô lập nói trên và ép nút này “duyệt” một thông điệp chéo chuỗi giả mạo. Khi Endpoint của LayerZero phát hiện DVN đã xác nhận, nó chuyển thông điệp này qua hàm lzReceive tới hợp đồng OFT của Kelp — và hợp đồng này thực hiện theo yêu cầu, đúc ra 116.500 rsETH trên mạng chính Ethereum. Thông điệp tuyên bố rằng tài sản tương ứng đã bị khóa trên chuỗi khác làm bảo đảm — nhưng thực tế những tài sản đó chưa bao giờ tồn tại.
Tiếp theo là quy trình rửa tiền DeFi tiêu chuẩn:
- Gửi rsETH bị đánh cắp làm tài sản thế chấp vào Aave V3, Compound V3 và Euler
- Sử dụng tài sản thế chấp không có bảo đảm thực tế này để vay khoảng 236 triệu USD WETH
- Tập trung khoảng 74.000 ETH và rút tiền qua Tornado Cash
46 phút sau, vào lúc 18:21, đa chữ ký khẩn cấp của Kelp đã tạm dừng hợp đồng. Hai đợt tấn công tiếp theo của kẻ tấn công (mỗi đợt 40.000 rsETH, tương đương khoảng 100 triệu USD) đều bị hủy — việc tạm dừng này đã chặn thêm khoảng 200 triệu USD tổn thất.
Nhưng phạm vi ảnh hưởng vẫn rất nghiêm trọng. Aave V3 gánh chịu khoảng 177 triệu USD tổn thất xấu. Token AAVE giảm mạnh 10,27%. ETH giảm 3%. Tỷ lệ sử dụng WETH trên Aave tăng vọt lên 100% ngay lập tức, khiến người gửi tiền đổ xô rút tiền. Trên hơn 20 L2, giá trị rsETH — vốn đang lưu hành — trở nên nghi vấn trong một đêm.
Ngày 6 tháng 4 — Báo cáo đã phát hiện điều gì?
Đầu tháng 4, ngay sau sự kiện Drift Protocol bị đánh cắp 285 triệu USD vào ngày 1 tháng 4, tôi đã phát triển một kỹ năng mã nguồn mở dành cho Claude Code mang tên crypto-project-security-skill — một khuôn khổ đánh giá rủi ro kiến trúc hỗ trợ bởi AI, sử dụng dữ liệu công khai (DeFiLlama, GoPlus, Safe API, xác minh trên chuỗi) để đánh giá các giao thức DeFi. Đây không phải là một công cụ quét mã, cũng không phải công cụ xác minh hình thức. Sự kiện Drift khiến tôi nhận ra rõ một điều: nguyên nhân gây tổn thất lớn nhất không nằm trong mã hợp đồng thông minh — mà nằm ở những lỗ hổng quản trị, sơ suất cấu hình và các “điểm mù” về kiến trúc — những thứ mà mọi công cụ quét mã đều không thể nhìn thấy. Vì vậy, tôi đã xây dựng một công cụ chuyên đánh giá các lớp này: cấu trúc quản trị, phụ thuộc vào oracles, cơ chế kinh tế và kiến trúc chéo chuỗi, đồng thời so sánh từng giao thức với các mẫu tấn công nổi tiếng trong lịch sử (Drift, Euler, Ronin, Harmony, Mango).
Vào ngày 6 tháng 4, tôi đã tiến hành kiểm toán toàn diện đối với Kelp DAO. Báo cáo đầy đủ được công khai trên GitHub, kèm dấu thời gian commit không thể thay đổi.
Báo cáo chấm điểm tổng thể mức độ rủi ro của Kelp là 72/100 (rủi ro trung bình). Nhìn lại, điểm số này quá dễ dãi — những khoảng trống thông tin liên quan đến chéo chuỗi vốn chưa được giải quyết đáng lẽ phải kéo điểm xuống thấp hơn. Tuy nhiên, ngay cả ở mức đánh giá rủi ro trung bình, báo cáo vẫn xác định đúng điểm tấn công sau này bị khai thác thực tế.
Hình chụp màn hình dưới đây là phần “Khoảng trống thông tin” trong báo cáo — vấn đề về cấu hình DVN của Kelp, sau này trở thành nguyên nhân gốc rễ dẫn đến vụ mất mát 292 triệu USD:
Chú thích ảnh: Chương “Khoảng trống thông tin” trong báo cáo ngày 6 tháng 4, trong đó cấu hình DVN thiếu minh bạch bị nêu đích danh
Dưới đây là bảng so sánh chi tiết giữa những gì báo cáo đã đánh dấu và thực tế diễn ra như thế nào.
Phát hiện 1: Thiếu minh bạch trong cấu hình DVN (tín hiệu cảnh báo)
Nguyên văn báo cáo: «Cấu hình DVN của LayerZero (tập hợp các nút xác minh trên từng chuỗi, yêu cầu ngưỡng xác minh) chưa được công khai»
Thực tế xảy ra: Kelp sử dụng cấu hình DVN dạng 1-trong-1. Chỉ một nút. Một điểm duy nhất. Kẻ tấn công chiếm được nút này là có thể giả mạo thông điệp chéo chuỗi. Nếu cấu hình là 2-trong-3 (mức tối thiểu được khuyến nghị trong ngành), kẻ tấn công buộc phải đồng thời chiếm quyền nhiều bên xác minh độc lập.
Cần làm rõ một điều: Đây là vấn đề của Kelp, chứ không phải của LayerZero. LayerZero là cơ sở hạ tầng — nó cung cấp khung DVN, còn mỗi giao thức tự chọn cấu hình: số lượng nút xác minh (1-of-1, 2-of-3, 3-of-5…), sử dụng nút của bên nào, ngưỡng xác minh trên từng chuỗi là bao nhiêu. Kelp đã chọn cấu hình 1-of-1 khi triển khai cầu nối OFT. LayerZero hoàn toàn hỗ trợ cấu hình 2-of-3 hoặc cao hơn — nhưng Kelp tự chọn không kích hoạt.
Hãy ví dụ: AWS cung cấp xác thực đa yếu tố (MFA). Nếu tài khoản của bạn bị đánh cắp vì bạn chưa bật MFA, thì đó là lỗi của bạn, chứ không phải của AWS. LayerZero đã đặt sẵn cơ chế bảo mật, nhưng Kelp không sử dụng.
Báo cáo của chúng tôi lúc đó không thể xác định ngưỡng DVN cụ thể (vì Kelp chưa từng tiết lộ), nhưng chúng tôi đã liệt kê rõ việc thiếu minh bạch này như một khoảng trống thông tin chưa giải quyết và một yếu tố rủi ro. Việc từ chối tiết lộ bản thân đã là một tín hiệu cảnh báo đỏ.
Phát hiện 2: Sự cố đơn điểm ảnh hưởng tới 16 chuỗi (đúng trúng đích)
Nguyên văn báo cáo: «Sự cố đơn điểm của DVN LayerZero có thể đồng thời ảnh hưởng tới rsETH trên 16 chuỗi được hỗ trợ»
Thực tế xảy ra: Thông điệp giả mạo trực tiếp nhắm vào mạng chính Ethereum, và sóng chấn động lan rộng tới tất cả các chuỗi đã triển khai rsETH. LayerZero chủ động tạm dừng toàn bộ cầu nối OFT xuất phát từ Ethereum. Người nắm giữ rsETH trên hơn 20 L2 bỗng chốc không còn biết đồng tiền họ đang nắm giữ còn có bảo đảm hay không.
Đây là rủi ro hệ thống trong mô hình triển khai đa chuỗi: rsETH cùng lúc lưu hành trên Arbitrum, Optimism, Base, Scroll và nhiều L2 khác, nhưng giá trị của tất cả những đồng tiền này đều bắt nguồn từ tài sản trên mạng chính Ethereum. Một khi cầu nối trên mạng chính bị xâm nhập, rsETH trên mọi L2 đồng loạt mất bảo đảm — người nắm giữ vừa không thể đổi lại, cũng không thể xác minh được giá trị thực tế của đồng tiền trong tay mình. earnETH của Lido (có phơi bày rủi ro rsETH), cầu nối LayerZero của Ethena — tất cả đều buộc phải tạm dừng. Phạm vi ảnh hưởng vượt xa giới hạn của riêng Kelp.
Phát hiện 3: Quyền kiểm soát quản trị chéo chuỗi chưa được xác minh (vấn đề liên quan)
Nguyên văn báo cáo: «Quyền kiểm soát quản trị đối với cấu hình OFT LayerZero trên từng chuỗi chưa được xác minh — đặc biệt là: các quyền này có thuộc về đa chữ ký 6/8 và khóa thời gian 10 ngày hay không, hay được quản lý bởi các khóa quản trị độc lập»
Thực tế xảy ra: Cấu hình DVN rõ ràng không nằm dưới sự kiểm soát chặt chẽ của quản trị giao thức cốt lõi. Nếu việc thay đổi cấu hình cầu nối cũng thuộc phạm vi quản trị của đa chữ ký 6/8 kết hợp khóa thời gian 10 ngày, thì thiết lập DVN 1-of-1 sẽ đòi hỏi ít nhất 6 trong số 8 người ký phải đồng ý — cấu hình như vậy khó có thể tồn tại lâu dài mà không bị giám sát.
Điều này phơi bày một “điểm mù” quản trị phổ biến: Nhiều giao thức thiết lập quy trình đa chữ ký nghiêm ngặt và khóa thời gian cho việc nâng cấp hợp đồng cốt lõi, nhưng đối với các thay đổi ở tầng vận hành — cấu hình cầu nối, tham số oracle, quản lý danh sách trắng — thường chỉ có một khóa admin duy nhất có thể thực hiện. Quản trị giao thức cốt lõi của Kelp đạt tiêu chuẩn hàng đầu trong ngành (6/8 đa chữ ký + khóa thời gian 10 ngày), nhưng những cơ chế bảo vệ này không mở rộng tới bề mặt tấn công lớn nhất của nó: cầu nối chéo chuỗi.
Phát hiện 4: Phù hợp với mô hình tấn công Ronin/Harmony (đúng trúng đích)
Nguyên văn báo cáo: «Tiền lệ lịch sử liên quan nhất liên quan đến an ninh cầu nối. Việc triển khai LayerZero của Kelp trên 16 chuỗi tạo ra độ phức tạp vận hành tương tự kiến trúc đa chuỗi của Ronin»
Thực tế xảy ra: Đường tấn công gần như sao chép y nguyên kịch bản Ronin — chiếm quyền nút xác minh cầu nối, giả mạo thông điệp, rút sạch tài sản. Mô-đun khớp mẫu tấn công của công cụ chúng tôi so sánh kiến trúc giao thức với các loại tấn công lịch sử, và đúng đắn xác định đây là vector tấn công rủi ro cao nhất.
Bối cảnh lịch sử: Năm 2022, cầu nối Ronin bị mất 625 triệu USD do 5 trong số 9 nút xác minh bị xâm nhập; cùng năm đó, cầu nối Horizon của Harmony bị mất 100 triệu USD do 2 trong số 5 nút xác minh bị xâm nhập. Tình thế của Kelp còn cực đoan hơn — chỉ có duy nhất một nút xác minh, đẩy ngưỡng tấn công xuống mức thấp tuyệt đối. Công cụ có thể xác định rủi ro này chính vì nó tự động so sánh kiến trúc giao thức với các mẫu tấn công lịch sử, chứ không chỉ tập trung vào mã nguồn.
Phát hiện 5: Không có quỹ bảo hiểm (làm trầm trọng thêm tổn thất)
Nguyên văn báo cáo: «Hiện tại giao thức chưa thiết lập quỹ bảo hiểm chuyên biệt, cũng chưa có cơ chế chia sẻ tổn thất xã hội để hấp thụ các sự kiện phạt thu»
Thực tế xảy ra: Do không có quỹ bảo hiểm, tổn thất 292 triệu USD toàn bộ được các giao thức phụ thuộc gánh chịu. Quỹ dự phòng thu hồi của Aave chỉ bao phủ chưa đến 30% trong số 177 triệu USD tổn thất xấu của nó. Các LP — hoàn toàn không liên quan đến quyết định cấu hình cầu nối của Kelp — lại phải gánh chịu cú sốc lớn nhất.
Kẻ tấn công gửi rsETH bị đánh cắp làm tài sản thế chấp vào Aave V3, Compound V3 và Euler, rồi vay ra WETH thật. Ngay khi rsETH bị xác nhận là không có bảo đảm, các vị thế này trở thành tổn thất xấu “không thể thanh lý” — tài sản thế chấp hóa giấy vụn, nhưng WETH đã cho vay thì không còn. Tỷ lệ sử dụng WETH trên Aave tăng vọt lên mức tối đa, khiến người dùng bình thường không thể rút tiền. Nếu bạn là người gửi WETH trên Aave, dù chưa từng chạm tới rsETH, tài sản của bạn vẫn bị ảnh hưởng. Hợp tác bảo hiểm giữa Kelp và Nexus Mutual chỉ bao phủ một số sản phẩm kho bạc cụ thể, chứ không bao gồm phơi bày rủi ro cốt lõi của giao thức rsETH.
Đây là sự thất bại của cả hai phía. Về phía Kelp: Một giao thức quản lý TVL 1,3 tỷ USD nhưng không có quỹ bảo hiểm, cũng không có cơ chế hấp thụ tổn thất. Khi cầu nối bị xâm nhập, không có bất kỳ lớp đệm nào để giảm nhẹ hậu quả. Về phía Aave: Chấp nhận rsETH làm tài sản thế chấp nhưng không đánh giá đầy đủ rủi ro cấu hình cầu nối chéo chuỗi. Các tham số rủi ro của Aave (tỷ lệ cho vay trên giá trị tài sản thế chấp – LTV, ngưỡng thanh lý) được thiết kế cho biến động giá bình thường, nhưng không tính đến rủi ro đuôi “cấu hình cầu nối bị xâm nhập khiến tài sản thế chấp hóa thành vô giá trị trong một đêm”. Quỹ dự phòng thu hồi thậm chí không bao phủ nổi 30% tổn thất xấu. Thực chất, đây là một thất bại trong định giá rủi ro: Aave coi rsETH như một tài sản biến động bình thường, nhưng thực tế nó mang rủi ro đuôi nhị phân do thất bại cầu nối. Sự thất bại chồng chéo của cả hai phía — Kelp không có quỹ bảo hiểm để ngăn tài sản thế chấp xấu vào hệ thống, còn Aave không xây dựng mô hình rủi ro đủ chi tiết để hạn chế mức phơi bày trong tình huống này.
Chúng tôi sai ở đâu?
Có ba việc chúng tôi đáng lẽ nên làm tốt hơn:
Chấm điểm rủi ro quá thấp. Chúng tôi đánh giá rủi ro cầu nối chéo chuỗi ở mức «trung bình». Trong báo cáo, 5 khoảng trống thông tin chưa giải quyết có tới 3 cái liên quan đến cấu hình cầu nối LayerZero, lại trùng khớp với mẫu tấn công lịch sử Ronin/Harmony — điều này đáng lẽ phải được xếp ở mức «cao» hoặc «nghiêm trọng». Việc thiếu minh bạch bản thân đã phải là tín hiệu mạnh hơn.
Chúng tôi không xuyên thấu được tới tầng cấu hình. Báo cáo liên tục yêu cầu Kelp tiết lộ ngưỡng DVN, nhưng chúng tôi không thể xác minh độc lập. Đây chính là «điểm mù cấu trúc» mà phân tích hậu sự kiện của Cnyes.com chỉ ra: Các công cụ kiểm toán hiện tại tập trung vào logic mã nguồn, nên không thể phát hiện rủi ro ở tầng cấu hình. Chúng tôi đã đánh dấu vấn đề, nhưng không thể đưa ra câu trả lời.
Chúng tôi không kiểm tra trên chuỗi. Thực tế, cấu hình DVN có thể đọc trực tiếp trên chuỗi thông qua hợp đồng EndpointV2 của LayerZero. Chúng tôi hoàn toàn có thể truy vấn registry ULN302 để xác minh độc lập ngưỡng DVN của Kelp, thay vì ghi nhận là «chưa được công khai». Nếu đã làm việc này, chúng tôi sẽ trực tiếp nhìn thấy cấu hình 1-of-1, chẳng cần Kelp tiết lộ. Đây là hướng cải tiến cụ thể nhất cho công cụ: Thêm bước xác minh cấu hình DVN trên chuỗi vào quy trình đánh giá chéo chuỗi.
Phát hiện chưa đủ cụ thể, chưa đủ khả thi. Việc nói «cấu hình DVN chưa được tiết lộ» chỉ là quan sát về việc thiếu tài liệu — chứ không phải dự báo tấn công. Những rủi ro này (tập trung oracle, phụ thuộc cầu nối, thiếu bảo hiểm) thực tế cũng tồn tại phổ biến ở hầu hết các giao thức DeFi chéo chuỗi. Công cụ đánh dấu sự thiếu minh bạch của Kelp, nhưng cũng đã ghi nhận các mẫu tương tự trên hàng chục giao thức khác chưa bị tấn công. Trong trường hợp chưa công bố tỷ lệ báo sai, việc tuyên bố «chúng tôi đã dự đoán trước» là phóng đại sự thật. Cách nói trung thực hơn là: Chúng tôi đã đặt ra những câu hỏi đúng — mà một trong số đó tình cờ chạm trúng điểm chịu lực then chốt.
Về «tiết lộ có trách nhiệm»
Một câu hỏi công bằng: Nếu chúng tôi đã đánh dấu những rủi ro này vào ngày 6 tháng 4, tại sao không thông báo cho Kelp trước khi xảy ra vụ tấn công ngày 18 tháng 4?
Chúng tôi không thông báo. Lý do là: Báo cáo chỉ nhận diện sự thiếu minh bạch — «cấu hình DVN chưa được tiết lộ», chứ không phải một lỗ hổng cụ thể có thể khai thác. Chúng tôi không biết cấu hình là 1-of-1, chỉ biết cấu hình chưa được công khai. Không có thông tin cụ thể nào để tiết lộ. «Cấu hình cầu nối của bạn chưa có tài liệu» là một quan sát về quản trị, chứ không phải một báo cáo phù hợp để nộp vào chương trình thưởng tìm lỗi (bug bounty).
Nhìn lại, chúng tôi hoàn toàn có thể liên hệ trực tiếp với đội ngũ Kelp để hỏi về ngưỡng DVN của họ. Cuộc trò chuyện đó có thể đã làm lộ cấu hình 1-of-1 và thúc đẩy việc sửa chữa. Nhưng chúng tôi đã không làm. Đây là một bài học: Ngay cả khi một phát hiện có vẻ quá mơ hồ để thực hiện quy trình tiết lộ chính thức, việc gửi một tin nhắn riêng tư để hỏi cũng luôn đáng giá.
Sự việc này hàm ý điều gì đối với an ninh DeFi?
Vụ đánh cắp Kelp — giống như vụ Drift bị đánh cắp 17 ngày trước — không phải do lỗ hổng hợp đồng thông minh. Các công cụ quét mã tự động như Slither, Mythril, thậm chí cả GoPlus đều không thể phát hiện. Lỗ hổng nằm ở cấu hình triển khai, khoảng trống quản trị và các quyết định kiến trúc — những yếu tố nằm ở tầng trên mã nguồn.
Đây cũng chính là luận điểm cốt lõi của crypto-project-security-skill:
An ninh giao thức không chỉ là an ninh mã nguồn. Một giao thức có thể sở hữu mã Solidity hoàn hảo, được kiểm toán năm lần bởi các công ty hàng đầu, và có chương trình thưởng tìm lỗi lên tới 250.000 USD — nhưng vẫn bị đánh cắp 292 triệu USD chỉ vì vấn đề cấu hình nút xác minh cầu nối.
Công cụ được mã nguồn mở trên GitHub — bất kỳ ai cũng có thể xem xét phương pháp luận, tự chạy thử hoặc cải tiến nó.
Timeline
12 ngày. Tín hiệu đã có từ rất sớm. Vấn đề là: Hệ sinh thái cần xây dựng những công cụ nào để có thể nhận diện các tín hiệu này trước khi cây cầu tiếp theo đổ sập.
Bạn có thể làm gì?
Nếu bạn đang nắm giữ tài sản trong các giao thức DeFi có tích hợp cầu nối chéo chuỗi:
- Tự chạy kiểm toán. Công cụ là mã nguồn mở. Đừng tin chúng tôi — hãy tự kiểm chứng.
- Kiểm tra cấu hình nút xác minh cầu nối. Nếu một giao thức từ chối tiết lộ ngưỡng DVN của mình, hãy coi đó là tín hiệu cảnh báo đỏ. Báo cáo của chúng tôi đã làm như vậy — và thực tế chứng minh điều đó là đúng.
- Đừng nghĩ rằng kiểm toán mã nguồn đã bao quát mọi thứ. Kelp đã trải qua hơn năm lần kiểm toán mã nguồn bởi các công ty và nền tảng uy tín (Code4rena, SigmaPrime, MixBytes). Mục tiêu thiết kế của kiểm toán mã nguồn truyền thống không bao gồm việc phát hiện rủi ro ở tầng cấu hình như thiết lập ngưỡng DVN — đây là một loại phân tích khác, chứ không phải sự thiếu sót của các công ty kiểm toán.
- Đánh giá phạm vi bảo hiểm. Nếu một giao thức không có quỹ bảo hiểm, và bạn là LP trên một nền tảng cho vay chấp nhận token của giao thức đó làm tài sản thế chấp, thì bạn đang vô hình chung đảm bảo rủi ro cho giao thức đó. Lần này, những người gửi WETH trên Aave đã học bài học này một cách đau đớn nhất.
Bức tranh lớn hơn: Agent AI như một lớp bảo mật độc lập
Bài viết này kể về một công cụ và một vụ đánh cắp. Nhưng luận điểm sâu xa hơn là: Agent AI có thể trở thành một lớp bảo mật độc lập cho nhà đầu tư DeFi.
Mô hình an ninh truyền thống trong ngành tiền mã hóa như sau: Giao thức thuê công ty kiểm toán, công ty kiểm toán xem mã nguồn, công ty kiểm toán phát hành báo cáo. Mô hình này có những “điểm mù” — sự kiện Kelp vừa minh chứng rõ điều này: Nó tập trung vào tính đúng đắn của mã nguồn, nhưng lại bỏ sót rủi ro ở tầng cấu hình, quản trị và kiến trúc.
Claude Code và các công cụ kỹ năng tương tự mở ra một hướng tiếp cận khác: Bất kỳ ai cũng có thể sử dụng dữ liệu công khai để chạy một đánh giá rủi ro hỗ trợ bởi AI đối với bất kỳ giao thức nào trong vài phút. Bạn không cần chi 200.000 USD để thuê công ty kiểm toán. Bạn không cần biết đọc Solidity. Bạn để agent so sánh kiến trúc giao thức với các mẫu tấn công đã biết, và nó sẽ liệt kê ra những câu hỏi bạn nên đặt ra trước khi gửi tiền.
Điều này sẽ không thay thế kiểm toán chuyên nghiệp — nhưng nó hạ thấp ngưỡng kiểm tra doanh nghiệp (due diligence) ở cấp độ đầu tiên xuống mức mà bất kỳ ai cũng có thể sử dụng. Một nhà cung cấp thanh khoản (LP) đang cân nhắc gửi vốn vào một giao thức tái ký quỹ mới giờ đây có thể chạy lệnh audit defi <protocol>, và nhận được một báo cáo đánh giá rủi ro có cấu trúc bao quát quản trị, oracle, cầu nối và cơ chế kinh tế. Đây là một bước chuyển mình thực sự trong cách nhà đầu tư cá nhân và nhà đầu tư trung bình tự bảo vệ mình.
Báo cáo về Kelp không hoàn hảo. Nó chấm rủi ro cầu nối ở mức trung bình, trong khi đáng lẽ phải là nghiêm trọng. Nó không xuyên thấu được tới tầng cấu hình. Nhưng nó đã đặt ra những câu hỏi đúng — nếu đội ngũ Kelp hoặc bất kỳ LP nào lúc đó nghiêm túc xem xét những câu hỏi này, tổn thất 292 triệu USD hoàn toàn có thể tránh được.
Chào mừng tham gia cộng đồng chính thức TechFlow
Nhóm Telegram:https://t.me/TechFlowDaily
Tài khoản Twitter chính thức:https://x.com/TechFlowPost
Tài khoản Twitter tiếng Anh:https://x.com/BlockFlow_News
@liliangjya5
