Tác giả: Zengineer
Biên dịch: Deep Tide TechFlow
Dẫn nhập Deep Tide: Ngày 18/4, Kelp DAO bị đánh cắp 292 triệu USD, trở thành sự cố DeFi lớn nhất năm 2026 tính đến thời điểm đó. Lỗ hổng không nằm trong mã hợp đồng, mà trong cấu hình nút xác thực 1-of-1 của cầu nối chuỗi chéo LayerZero – chỉ cần một điểm yếu duy nhất bị xâm phạm là có thể giả mạo tin nhắn liên chuỗi. 12 ngày trước, tác giả đã sử dụng công cụ kiểm tra AI mã nguồn mở do mình phát triển để quét Kelp và đã đánh dấu điểm rủi ro này. Bài viết phân tích toàn bộ quá trình tấn công, đồng thời trung thực suy ngẫm về ba điều công cụ đã không làm đúng lúc đó.
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 EigenLayer. Cơ chế như sau: người dùng gửi ETH hoặc token staking thanh khoản (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 của EigenLayer để tái staking – đồng thời cung cấp tính bảo mật cho nhiều AVS (Dịch vụ Xác thực Chủ động - Actively Validated Services). Đổi lại, người dùng nhận rsETH làm chứng chỉ. Khác với việc tái staking trực tiếp trên EigenLayer (tài sản bị khóa), rsETH có tính thanh khoản – có thể giao dịch, dùng làm tài sản thế chấp trong các giao thức cho vay như Aave, hoặc có thể sử dụng xuyên chuỗi.
Để đạt được tính thanh khoản xuyên chuỗi này, Kelp sử dụng chuẩn OFT (Token có thể thay thế đa chuỗi - Omnichain Fungible Token) 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 đó, DVN (Mạng lưới Xác thực Phi tập trung - Decentralized Verifier Network) của LayerZero sẽ xác minh tính hợp lệ của tin nhắn liên chuỗi này. Kiến trúc cầu nối này chính là cốt lõi của câu chuyện sau đây.
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/2023, TVL đỉnh 2.09 tỷ USD, quản trị sử dụng đa ký 6/8 và khóa thời gian nâng cấp hợp đồng 10 ngày. Token quản trị KERNEL quản lý ba dòng sản phẩm Kelp, Kernel, Gain.
Sự kiện bị đánh cắp
Ngày 18 tháng 4 năm 2026, kẻ tấn công đã rút 116,500 rsETH từ cầu nối xuyên chuỗi của Kelp DAO, tương đương khoảng 292 triệu USD – sự cố tấn công DeFi lớn nhất tính đến thời điểm đó trong năm 2026. 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 vấn đề cấu hình: cài đặt DVN 1-of-1 (nghĩa là chỉ có 1 nút xác thực, chỉ cần 1 chữ ký là đủ), cho phép kẻ tấn công chỉ cần xâm phạm một nút duy nhất để giả mạo tin nhắn liên chuỗi.
12 ngày trước, vào ngày 6 tháng 4, công cụ kiểm tra bảo mật mã nguồn mở của tôi đã đánh dấu mặt tấn công này.
Xin nói trước một điều: vụ trộm này, là những người thực sự đang mất tiền thực sự. Những người gửi tiền WETH vào Aave chưa từng chạm vào rsETH, tiền của họ bị đóng băng; các LP trong nhiều giao thức phải gánh chịu các khoản nợ xấu mà họ thậm chí chưa từng ký kết. Bài viết này phân tích điều gì đã xảy ra, công cụ của chúng tôi đã chụp được gì – nhưng cái giá tổn thất thực tế của mọi người, quan trọng hơn bất kỳ bảng điểm nào.
Báo cáo đầy đủ được đăng trên GitHub, dấu thời gian commit bất kỳ ai cũng có thể xác minh. Dưới đây giải thích những gì chúng tôi đã bắt được, những gì đã bỏ lỡ, 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, DeFi chấn động
17:35 UTC ngày 18/4, kẻ tấn công xâm phạm nút xác thực DVN bị cô lập đó, sau đó khiến nó "phê duyệt" một tin nhắn liên chuỗi giả mạo. Endpoint của LayerZero thấy DVN đã thông qua, liền chuyển tin nhắn qua lzReceive tới hợp đồng OFT của Kelp – hợp đồng làm theo, đúc ra 116,500 rsETH trên Ethereum mainnet. Tin nhắn tuyên bố rằng các tài sản thế chấp có giá trị tương đương đã bị khóa trên các chuỗi khác. Những tài sản đó không bao giờ tồn tại.
Tiếp theo là một quy trình rửa tiền DeFi tiêu chuẩn:
- Gửi rsETH đánh cắp được làm tài sản thế chấp vào Aave V3, Compound V3, Euler
- Sử dụng các tài sản thế chấp không có đảm bảo thực này, vay khoảng 236 triệu USD WETH
- Tập trung khoảng 74,000 ETH, rút tiền qua Tornado Cash
46 phút sau, vào lúc 18:21, đa ký tạm dừng khẩn cấp của Kelp đã đóng băng hợp đồng. Kẻ tấn công sau đó truy đuổi hai lần (mỗi lần 40,000 rsETH, khoảng 100 triệu USD) đều bị revert – lần tạm dừng này đã chặn thêm khoảng 200 triệu USD.
Nhưng phạm vi ảnh hưởng vẫn thảm khốc. Aave V3 nuốt khoảng 177 triệu USD nợ xấu. Token AAVE lao dốc 10.27%. ETH giảm 3%. Tỷ lệ sử dụng WETH trên Aave ngay lập tức tăng vọt lên 100%, người gửi tiền tranh nhau rút. rsETH trên hơn 20 L2, chỉ sau một đêm đều trở thành tài sản có giá trị đáng ngờ.
Ngày 6/4, báo cáo đã bắt được gì
Đầu tháng 4, ngay sau khi Drift Protocol bị đánh cắp 285 triệu USD vào ngày 1/4, tôi đã viết một kỹ năng Claude Code mã nguồn mở crypto-project-security-skill – một khung đá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. Nó không phải là trình quét mã, cũng không phải là công cụ xác minh hình thức. Sự kiện Drift đã cho tôi thấy rõ một điều: thứ thực sự gây ra tổn thất lớn nhất, không nằm trong mã hợp đồng thông minh – mà nằm ở các lỗ hổng quản trị, sơ suất cấu hình, điểm mù kiến trúc, những nơi trình quét mã không bao giờ nhìn thấy. Vì vậy tôi đã viết 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 oracle, cơ chế kinh tế, kiến trúc chuỗi chéo, 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).
Ngày 6/4, tôi đã chạy một lượt kiểm tra đầy đủ cho Kelp DAO. Báo cáo đầy đủ được công khai trên GitHub, với dấu thời gian commit không thể sửa đổi.
Báo cáo cho điểm đánh giá tổng hợp của Kelp là 72/100 (rủi ro trung bình). Nhìn lại, điểm này quá khoan hồng – những khoảng trống thông tin chưa được giải đáp về chuỗi chéo lẽ ra phải kéo điểm xuống thấp hơn. Nhưng ngay cả với xếp hạng rủi ro trung bình, báo cáo cũng chỉ ra mặt tấn công sau đó bị khai thác thực tế.
Ảnh chụp màn hình dưới đây, là nguyên văn phần "Khoảng trống thông tin" của báo cáo – câu hỏi về cấu hình DVN của Kelp, cuối cùng đã trở thành nguyên nhân gốc rễ của vụ trộm 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/4, cấu hình DVN không minh bạch bị chỉ đích danh
Dưới đây là từng điểm đối chiếu những gì báo cáo đã đánh dấu và thực tế bị xuyên thủng như thế nào.
Phát hiện 1:Cấu hình DVN không minh bạch(Tín hiệu cảnh báo)
Nguyên văn báo cáo: 「Cấu hình LayerZero DVN (tập hợp trình xác thực trên mỗi chuỗi, yêu cầu ngưỡng) không được công bố công khai」
Thực tế xảy ra: Kelp chạy cấu hình DVN 1-of-1. Một nút. Một điểm đơn lẻ. Kẻ tấn công chiếm được nút duy nhất này, đã giả mạo được tin nhắn liên chuỗi. Nếu cấu hình là 2-of-3 (mức tối thiểu được khuyến nghị trong ngành), kẻ tấn công sẽ phải đồng thời xâm phạm nhiều bên xác thực độc lập.
Cần nói rõ một điều: Đây là vấn đề của Kelp, không phải của LayerZero. LayerZero là cơ sở hạ tầng – nó cung cấp khung DVN, mỗi giao thức tự chọn cấu hình: bao nhiêu nút xác thực (1-of-1, 2-of-3, 3-of-5...), dùng nút của ai, ngưỡng cho mỗi chuỗi là bao nhiêu. Kelp đã chọn 1-of-1 khi triển khai cầu OFT. LayerZero hoàn toàn hỗ trợ 2-of-3 hoặc cao hơn – là Kelp đã không bật nó lên.
Lấy một ví dụ: AWS cung cấp MFA (Xác thực đa yếu tố). Nếu tài khoản của bạn bị hack vì bạn chưa bao giờ bật MFA, đó là lỗi của bạn, không phải của AWS. LayerZero đặt sẵn cơ chế bảo mật ở đó, 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õ ràng sự không minh bạch này thành một khoảng trống thông tin chưa giải quyết và mục rủi ro. Bản thân việc không muốn tiết lộ, đã là một lá cờ đỏ.
Phát hiện 2:Điểm hỏng đơn lẻ trên 16 chuỗi(Trúng trực tiếp)
Nguyên văn báo cáo: 「Điểm hỏng đơn lẻ của LayerZero DVN, có thể đồng thời ảnh hưởng đến rsETH trên 16 chuỗi được hỗ trợ」
Thực tế xảy ra: Tin nhắn giả mạo trúng vào mainnet Ethereum, sóng xung kích lan tỏa đến tất cả các chuỗi đã triển khai rsETH. LayerZero đã chủ động tạm dừng tất cả các cầu OFT đi ra từ Ethereum. Người nắm giữ rsETH trên hơn 20 L2, token trong tay họ chỉ sau một đêm không thể nói rõ còn được đảm bảo hay không.
Đây là rủi ro hệ thống của triển khai đa chuỗi: rsETH lưu thông đồng thời trên Arbitrum, Optimism, Base, Scroll và các L2 khác, nhưng giá trị của tất cả các token này đều bắt nguồn từ tài sản trên Ethereum mainnet. Cầu chính trên mainnet một khi bị xuyên thủng, rsETH trên mỗi L2 đồng thời mất đi sự đảm bảo – người nắm giữ không thể mua lại, cũng không thể xác minh token họ nắm giữ còn giá trị hay không. earnETH của Lido (nắm giữ rủi ro rsETH), cầu LayerZero của Ethena – tất cả đều buộc phải tạm dừng. Bán kính nổ vượt xa bản thân Kelp.
Phát hiện 3:Quyền kiểm soát quản trị chuỗi chéo 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 các chuỗi chưa được xác minh – cụ thể: các quyền kiểm soát này có thuộc về cùng một đa ký 6/8 và khóa thời gian 10 ngày hay không, hay được quản lý bởi một khóa quản trị độc lập」
Thực tế xảy ra: Rõ ràng cấu hình DVN không nằm dưới sự quản trị chặt chẽ của giao thức cốt lõi. Nếu thay đổi cấu hình cầu cũng thuộc quản lý của đa ký 6/8 và khóa thời gian 10 ngày, thì việc thiết lập DVN 1-of-1 sẽ cần 6 trên 8 người ký đồng ý – kiểu cấu hình như vậy khó có thể không ai để ý.
Điều này phơi bày một điểm mù quản trị phổ biến: nhiều giao thức đặt đa ký chặt chẽ và khóa thời gian cho việc nâng cấp hợp đồng cốt lõi, nhưng ở các thay đổi tầng vận hành – cấu hình cầu, tham số oracle, quản lý danh sách trắng – thường chỉ có một admin key có thể thay đổi. Quản trị giao thức cốt lõi của Kelp là hàng đầu trong ngành (đa ký 6/8 + khóa thời gian 10 ngày), nhưng những biện pháp bảo vệ này đã không mở rộng đến mặt tấn công lớn nhất của nó: cầu nối chuỗi chéo.
Phát hiện 4:Khớp với mẫu tấn công Ronin/Harmony(Trúng trực tiếp)
Nguyên văn báo cáo: 「Tiền lệ lịch sử có liên quan nhất liên quan đến bảo mật cầu. Triển khai LayerZero trên 16 chuỗi của Kelp, mang lại độ phức tạp vận hành tương tự như kiến trúc đa chuỗi của Ronin」
Thực tế xảy ra: Đường dẫn tấn công gần như sao chép hoàn hảo kịch bản Ronin – xâm phạm trình xác thực cầu, giả mạo tin nhắn, rút rỗng 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ử, đã xác định chính xác đây là vector tấn công có rủi ro cao nhất.
Bối cảnh lịch sử: Năm 2022, cầu Ronin mất 625 triệu USD do 5 (trên tổng số 9) trình xác thực bị xâm phạm; cùng năm, cầu Horizon của Harmony mất 100 triệu USD do 2 (trong số 5) trình xác thực bị xâm phạm. Tình thế của Kelp còn cực đoan hơn – chỉ có 1 trình xác thực, đẩy ngưỡng tấn công xuống mức thấp nhất tuyệt đối. Lý do công cụ có thể đánh dấu rủi ro này, là 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ử này, thay vì chỉ nhìn vào mã.
Phát hiện 5:Không có bể bảo hiểm(Khuếch đại tổn thất)
Nguyên văn báo cáo: 「Giao thức hiện không có bể bảo hiểm chuyên biệt, cũng không có cơ chế chia sẻ tổn thất xã hội hóa để hấp thụ các sự kiện slashing」
Thực tế xảy ra: Do không có dự trữ bảo hiểm, tổn thất 292 triệu USD hoàn toàn bị các giao thức downstream nuốt chửng. Kho dự trữ thu hồi của Aave chỉ trang trải được dưới 30% khoản nợ xấu 177 triệu USD của nó. Các LP – những người không hề liên quan đến quyết định cấu hình cầu của Kelp – lại phải gánh chịu tác động lớn nhất.
Kẻ tấn công gửi rsETH đánh cắp được làm tài sản thế chấp, vào Aave V3, Compound V3, Euler, sau đó vay WETH thật. Một khi rsETH được xác nhận là không có đảm bảo, các vị thế này trở thành nợ xấu "không thể thanh lý" – tài sản thế chấp thành giấy lộn, nhưng WETH đã vay mất rồi. Tỷ lệ sử dụng WETH trên Aave ngay lập tức tăng vọt lên 100%, người dùng thông thường muốn rút cũng không thể. Nếu bạn là người gửi WETH trên Aave, ngay cả khi bạn chưa từng chạm vào rsETH, tiền của bạn cũng bị ảnh hưởng. Hợp tác bảo hiểm giữa Kelp và Nexus Mutual chỉ bao phủ các sản phẩm vault cụ thể, không bao phủ rủi ro tiếp xúc giao thức rsETH cốt lõi.
Đây là sự không hoàn thành trách nhiệm từ cả hai phía. Về phía Kelp: một giao thức quản lý 1.3 tỷ USD TVL, không có bể bảo hiểm, không có cơ chế hấp thụ tổn thất. Khi cầu bị xuyên thủng, không có bất kỳ đệm nào để hấp thụ thiệt hại. 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 chuỗi chéo của nó. Các tham số rủi ro của Aave (LTV, ngưỡng thanh lý) được thiết kế cho biến động giá thông thường, nhưng không tính đến rủi ro đuôi "cấu hình cầu bị xuyên thủng khiến tài sản thế chấp về 0 chỉ sau một đêm". Kho dự trữ thu hồi thậm chí không trang trải nổi 30% nợ xấu. Về bản chất, đây là một thất bại trong định giá rủi ro: Aave đối xử với rsETH như một tài sản biến động bình thường, nhưng thực tế nó mang theo rủi ro đuôi nhị phân của sự thất bại cầu. Hai thất bại cộng lại – phía Kelp không có bảo hiểm ngăn tài sản thế chấp xấu vào hệ thống, phía Aave không làm mô hình hóa rủi ro đủ tinh vi để hạn chế mức độ tiếp xúc trong trường hợp này.
Chúng tôi đã sai ở đâu
Có ba điều lẽ ra nên làm tốt hơn:
Đánh giá rủi ro quá thấp. Chúng tôi đánh giá rủi ro cầu chuỗi chéo là "trung bình". Trong báo cáo, 5 khoảng trống thông tin chưa giải quyết có 3 cái liên quan đến cấu hình cầu LayerZero, lại khớp với mẫu tấn công lịch sử của Ronin/Harmony – lẽ ra phải là "cao" hoặc "nghiêm trọng". Bản thân sự không minh bạch đã phải là một tín hiệu mạnh hơn.
Chúng tôi không thể xuyên thấu lớp cấu hình. Báo cáo nhiều lần 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 sau sự kiện của [CNA] (鉅亨網) đã chỉ ra: các công cụ kiểm tra hiện có tập trung vào logic mã, không nắm bắt được rủi ro ở lớp cấu hình. Chúng tôi đã đánh dấu vấn đề, nhưng không thể trả lời.
Chúng tôi đã không kiểm tra trên chuỗi. Cấu hình DVN thực ra 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 lẽ ra có thể truy vấn ULN302 registry để xác minh độc lập ngưỡng DVN của Kelp, thay vì đánh dấu là "chưa công bố". Nếu kiểm tra lúc đó, đã có thể trực tiếp thấy cấu hình 1-of-1, hoàn toàn không cần Kelp tiết lộ. Đây là hướng cải tiến cụ thể nhất của công cụ: thêm xác minh cấu hình DVN trên chuỗi vào bước đánh giá chuỗi chéo.
Phát hiện không đủ cụ thể, không đủ để hành động. Nói "Cấu hình DVN chưa được tiết lộ" là quan sát sự thiếu sót tài liệu – không phải dự đoán cuộc tấn công. Những rủi ro này (tập trung oracle, phụ thuộc cầu, thiếu bảo hiểm) trên thực tế cũng phổ biến ở đa số các giao thức DeFi chuỗi chéo. Công cụ đánh dấu sự không minh bạch của Kelp, nhưng nó cũng đã đánh dấu các mẫu tương tự trên hàng chục giao thức không bị tấn công. Trong tình trạng chưa công bố tỷ lệ báo động sai, tuyên bố "chúng tôi đã dự đoán đượ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 đắn mà không ai hỏi, và một trong số đó tình cờ chạm đúng điểm then chốt.
Về "công bố 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/4, tại sao không thông báo cho Kelp trước ngày 18/4 khi bị tấn công?
Không thông báo. Lý do là: Báo cáo xác định được sự không minh bạch – "Cấu hình DVN chưa được tiết lộ", không phải là 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 không công khai. Không đủ cụ thể để có thể công bố. "Cấu hình cầu của bạn không có tài liệu" là một quan sát về quản trị, không phải là một báo cáo phù hợp để nộp cho chương trình bug bounty.
Nhìn lại, chúng tôi lẽ ra 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, thúc đẩy sửa chữa. 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ồ, không phù hợp để đi theo quy trình công bố chính thức, việc gửi một tin nhắn riêng tư để hỏi vẫn đáng giá.
Sự việc này có ý nghĩa gì với bảo mật DeFi
Vụ trộm Kelp – giống như vụ trộm Drift 17 ngày trước đó – không phải là lỗ hổng hợp đồng thông minh. Các trình quét mã tự động như Slither, Mythril, thậm chí GoPlus đều không thể bắt được. Lỗ hổng ẩn trong cấu hình triển khai, khoảng trống quản trị, quyết định kiến trúc, nằm ở trên lớp mã.
Đây cũng là luận điểm cốt lõi của crypto-project-security-skill:
Bảo mật giao thức không chỉ là bảo mật mã. Một giao thức có thể có Solidity hoàn hảo, năm lần kiểm tra từ các công ty hàng đầu, chương trình bug bounty 250,000 USD – và rồi vẫn bị đánh cắp 292 triệu USD vì vấn đề cấu hình trình xác thực cầu.
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, hoặc cải tiến nó.
Dòng thời gian
12 ngày. Tín hiệu đã ở đó từ sớm. Vấn đề là: hệ sinh thái phải xây dựng những công cụ như thế nào để có thể nhìn thấy những 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 có tài sản trong các giao thức DeFi có cầu nối chuỗi chéo:
- Tự chạy một lần kiểm tra. Công cụ là mã nguồn mở. Không cần tin chúng tôi – hãy tự xác minh.
- Kiểm tra cấu hình trình xác thực cầu. Nếu một giao thức không muốn tiết lộ ngưỡng DVN của họ, hãy coi đó là cờ đỏ. Báo cáo của chúng tôi đã làm như vậy, và thực tế chứng minh là đúng.
- Đừng nghĩ rằng kiểm tra mã bao phủ mọi thứ. Kelp có hơn 5 lần kiểm tra mã từ các công ty và nền tảng nổi tiếng (Code4rena, SigmaPrime, MixBytes). Mục tiêu thiết kế của kiểm tra mã truyền thống không bao gồm việc nắm bắt các rủi ro ở lớp cấu hình như thiết lập ngưỡng DVN – đó là một loại phân tích khác, không phải là sự thiếu trách nhiệm của 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ó bể 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 nó làm thế chấp, bạn đang ngầm bảo hiểm cho nó. Những người gửi WETH trên Aave lần này, đã học bài học đó theo cách khó khăn nhất.
Bức tranh lớn hơn: AI Agent như một lớp bảo mật
Bài viết này nói về một công cụ và một vụ trộm. Nhưng luận điểm đằng sau lớn hơn: AI Agent có thể trở thành một lớp bảo mật độc lập cho các nhà đầu tư DeFi.
Mô hình bảo mật truyền thống của ngành crypto như sau: giao thức thuê công ty kiểm toán, công ty kiểm toán xem mã, công ty kiểm toán phát hành báo cáo. Mô hình này có điểm mù – sự kiện Kelp đã minh họa rõ điều đó, nó tập trung vào tính đúng đắn của mã, nhưng bỏ lỡ cấu hình, quản trị, rủi ro kiến trúc.
Claude Code và các công cụ kỹ năng loại này mang lại một con đường 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 cho 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, nó sẽ đặt ra những câu hỏi bạn nên hỏi 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 cho lớp due diligence đầu tiên xuống mức mà mọi người đều có thể sử dụng. Một LP đang cân nhắc đưa vốn vào một giao thức tái staking mới, giờ đây có thể chạy lệnh audit defi
Báo cáo đó của Kelp không hoàn hảo. Nó đánh giá rủi ro cầu là trung bình, lẽ ra phải là nghiêm trọng. Nó không xuyên thấu được lớp cấu hình. Nhưng nó đã đặt ra những câu hỏi đúng đắn – 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 đã có thể tránh được.
