Một công cụ AI mã nguồn mở không ai để ý đã cảnh báo về lỗ hổng 2.92 tỷ USD của Kelp DAO 12 ngày trước

Tiêu đề ban đầu: Vụ Hack $292 triệu của Kelp DAO: Điều mà Một Đại Lý AI Phát Hiện Trước 12 Ngày—và Ý Nghĩa của Nó đối với An Ninh DeFi

Nguồn bản gốc: Blog Zengineer
Biên dịch ban đầu: TechFlow Sâu Sắc

Giới thiệu nhanh của TechFlow: Ngày 18 tháng 4, Kelp DAO bị hack mất 2,92 tỷ USD, là vụ tai nạn DeFi lớn nhất từ trước đến nay trong năm 2026. 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 LayerZero—nơi một điểm đánh bại có thể làm giả tin nhắn chuyển giao mã nguồn mở qua nhiều chuỗi.

12 ngày trước khi vụ tấn công xảy ra, tác giả đã sử dụng công cụ kiểm định trí tuệ nhân tạo mã nguồn mở của riêng mình để quét Kelp và đã ghi chú vấn đề rủi ro này. Bài viết này phân tích chi tiết toàn bộ quá trình tấn công, đồng thời thẳng thắn lên tiếng về ba điều mà công cụ không thực hiện đúng vào thời điểm đó.

Kelp DAO là gì

Kelp DAO là một giao thức cung cấp lại tổ chức dựa trên EigenLayer. Cơ chế hoạt động như sau: Người dùng gửi ETH hoặc token thế chấp lưu thông (stETH, ETHx) vào hợp đồng Kelp, sau đó hợp đồng ủy quyền tài sản cho nút vận hành của EigenLayer để thực hiện lại thế chấp—đồng thời cung cấp tính an toàn cho nhiều Dịch vụ Được Xác minh Hoạt động. Lấy rsETH làm phần thưởng, người dùng nhận được bằng chứng.

Với sự khác biệt so với việc thế chấp trực tiếp trên EigenLayer (tài sản bị khóa), rsETH có tính lưu thông—có thể giao dịch, sử dụng là tài sản thế chấp trong các giao thức vay mượn như Aave, cũng như có thể chuyển giao mã nguồn mở qua nhiều chuỗi.

Để đạt được tính lưu thông qua nhiều chuỗi, Kelp sử dụng tiêu chuẩn token có thể đổi mới của LayerZero (OFT) để triển khai rsETH trên hơn 16 chuỗi. Khi bạn chuyển rsETH từ Ethereum sang một chuỗi L2 nào đó, Mạng Xác minh Phi tập trung của LayerZero sẽ kiểm tra xem thông báo chuyển giao mã nguồn mở qua chuỗi đó có hợp lệ không. Kiến trúc cầu nối này chính là điểm hạ lõm của câu chuyện phía sau.

Kelp được khởi xướng bởi Amitej Gajjala và Dheeraj Borra (cựu cộng sự sáng lập của Stader Labs), ra mắt vào tháng 12 năm 2023, đỉnh điểm TVL là 20.9 tỷ USD, quản trị sử dụng bầu cử đa chữ ký 6/8 cộng với khoá 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ự cố Đánh cắp

Vào ngày 18 tháng 4 năm 2026, kẻ tấn công đã rút 116,500 đồng rsETH từ cầu nối Cross-Chain của Kelp DAO, tương đương khoảng 2.92 tỷ USD - sự kiện tấn công DeFi lớn nhất đến nay trong năm 2026. Nguyên nhân cơ bản không phải là lỗi hợp đồng thông minh mà là một vấn đề cấu hình: một thiết lập DVN 1 trong 1 (tức là chỉ có 1 nút xác minh, thông qua 1 chữ ký được coi là hợp lệ), cho phép kẻ tấn công sử dụng một nút bị xâm phạm duy nhất để làm giả các tin nhắn Cross-Chain.

12 ngày trước đó, vào ngày 6 tháng 4, công cụ kiểm định bảo mật mã nguồn mở của tôi đã chỉ ra điểm này của cuộc tấn công.

Hãy nói điều này trước: Lần này đã bị đánh cắp, người thật đã mất tiền thật. Người gửi tiền Aave WETH chưa bao giờ tiếp xúc với rsETH đã bị đóng băng; người tham gia vào nhiều giao protocal LP sẽ phải chịu nợ mà họ chưa bao giờ cam kết chịu trách nhiệm. Bài viết này phân tích những gì đã xảy ra, công cụ của chúng tôi đã bắt được điều gì - nhưng cái mà con người thực sự mất đi, quan trọng hơn bất kỳ bảng xếp hạng nào.

Báo cáo đầy đủ được công bố trên GitHub, mọi người đều có thể kiểm chứng dấu thời gian commit. Dưới đây là những gì chúng tôi đã phát hiện, những gì đã bị sót và ý nghĩa của sự việc này đối với các công cụ an ninh trong DeFi.

46 Phút, Sóng Gió DeFi

Vào lúc 17:35 UTC ngày 18 tháng 4, kẻ tấn công đã hack nút xác minh DVN cô lập đó, sau đó đã "phê duyệt" một tin nhắn Cross-Chain giả mạo. Điểm cuối của LayerZero đã nhìn thấy DVN thông qua, sau đó chuyển tin nhắn qua lzReceive đến hợp đồng OFT của Kelp - hợp đồng đã tạo ra 116,500 đồng rsETH trên mạng chính Ethereum. Tin nhắn tuyên bố rằng có tài sản đóng bảo mật tương đương trên các chuỗi khác. Những tài sản này chưa bao giờ tồn tại.

Tiếp theo là một quy trình rửa tiền DeFi tiêu chuẩn:

1. Đặt rsETH lẫn trộm được như tài sản thế chấp vào Aave V3, Compound V3, Euler

2. Dùng những tài sản thế chấp không có giá trị thật sự này để vay khoảng 2.36 tỷ đô la WETH

3. Tích trữ khoảng 74,000 ETH, rút tiền qua Tornado Cash

Sau 46 phút vào lúc 18:21, multi-sig khẩn cấp của Kelp đã đóng băng hợp đồng. Kẻ tấn công sau đó theo đuổi hai lượt (mỗi lượt 40,000 rsETH, khoảng 1 tỷ đô la) đều bị revert—lần này dừng lại ngăn chặn được khoảng 2 tỷ đô la.

Nhưng tác động vẫn rất mạnh mẽ. Aave V3 đã hấp thụ khoảng 1.77 tỷ đô la nợ xấu. Token AAVE đã giảm 10.27%. ETH giảm 3%. Tỷ lệ sử dụng WETH trên Aave tăng lên 100% ngay tức khắc, người gửi hốt về. Hơn 20 mã L2 trên thị trường rsETH, tất cả nhanh chóng trở thành tài sản không rõ giá trị qua một đêm.

Ngày 6 tháng 4, báo cáo đã bắt được điều gì

Vào đầu tháng 4, ngay sau vụ Drift Protocol bị đánh cắp 2.85 tỷ đô la vào ngày 1 tháng 4, tôi đã viết một kỹ năng mã nguồn mở Claude Code về an ninh dự án được đánh giá rủi ro với sự trợ giúp của trí tuệ nhân tạo crypto-project-security-skill——một khung đánh giá rủi ro kiến trúc được hỗ trợ bởi trí tuệ nhân tạo, 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à 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 đã làm tôi nhận ra một điều: Nguyên nhân thực sự gây ra tổn thất lớn nhất không phải ở mã hợp đồng thông minh—mà ở lỗ hổng quản trị, sơ suất cấu hình, điểm mù kiến trúc, những nơi mà các công cụ quét mã mãi mãi không thể nhìn thấy. Vì vậy, tôi đã viết một công cụ đánh giá riêng về những tầng này: cấu trúc quản trị, phụ thuộc vào oracles, cơ chế kinh tế, kiến trúc liên chuỗi, để so sánh mỗi giao thức và các mẫu tấn công trong lịch sử (Drift, Euler, Ronin, Harmony, Mango).

Ngày 6 tháng 4, tôi đã thực hiện một cuộc kiểm toán đầy đủ đối với 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ể thay đổi.

Báo cáo điều trị tổng thể cho Kelp đạt điểm đánh giá 72/100 (Rủi ro Trung bình). Nhìn lại sau, điểm này đã được đưa ra quá dễ dãi — những khoảng trống thông tin liên chuỗi không được giải đáp đã nên giảm điểm số. Nhưng ngay cả ở mức đánh giá rủi ro trung bình, báo cáo vẫn chỉ ra đến một hướng tấn công cuối cùng đã được tận dụng.

Ảnh chụp màn hình dưới đây là phần "Khoảng trống Thông tin" của báo cáo — về vấn đề cấu hình DVN của Kelp, cuối cùng đã trở thành nguyên nhân của việc mất 2,92 tỷ USD:

Phần "Khoảng trống Thông tin" trong báo cáo ngày 6 tháng 4, nêu rõ trực tiếp vấn đề không minh bạch của cấu hình DVN

Dưới đây là từng điểm so sánh với điều ghi trong báo cáo và thực tế đã xâm nhập như thế nào.

Khám phá 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 (Bộ sưu tập các nhà xác minh trên từng chuỗi, yêu cầu ngưỡng) không được tiết lộ công khai"

Thực tế đã xảy ra gì: Kelp đang chạy cấu hình DVN 1 trên 1. Một nhà xác minh. Một điểm duy nhất. Kẻ tấn công chiếm được điểm duy nhất này, liền có thể tạo ra tin nhắn liên chuỗi. Nếu cấu hình là 2 trên 3 (mức đề nghị tối thiểu của ngành), kẻ tấn công sẽ phải đồng thời tấn công nhiều bên xác minh độc lập.

Để nói rõ ràng 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 nhà xác minh (1 trên 1, 2 trên 3, 3 trên 5...), sử dụng những nhà xác minh nào, ngưỡng trên từng chuỗi là bao nhiêu. Khi triển khai cầu nối OFT, Kelp đã chọn 1 trên 1. LayerZero hoàn toàn hỗ trợ 2 trên 3 hoặc cao hơn — mà Kelp không sử dụng.

Một ví dụ: AWS cung cấp xác thực đa yếu tố. Nếu tài khoản của bạn bị đánh cắp vì bạn chưa bật xác thực đa yếu tố, đó là vấn đề của bạn, không phải của AWS. LayerZero đã đặt cơ chế bảo mật đó ở đấy, nhưng Kelp không sử dụng.

Báo cáo của chúng tôi không thể xác định rõ ngưỡng DVN cụ thể lúc đó (do Kelp chưa bao giờ tiết lộ), nhưng chúng tôi đã liệt kê mục không minh bạch này cụ thể là một khoảng trống thông tin chưa giải quyết và mối nguy rủi. Việc không muốn tiết lộ chính mình là một lá cờ đỏ.

Phát hiện 2: Sự cố Điểm Đơn của 16 Chuỗi (Trúng trực tiếp)

Bản gốc báo cáo: 「Sự cố Điểm Đơn của LayerZero DVN, có thể ảnh hưởng đồng thời đến 16 chuỗi hỗ trợ rsETH trên chuỗi」

Đã xảy ra gì: Tin nhắn giả mạo đã trúng trực tiếp vào mạng chính Ethereum, sóng chấn lan đến tất cả các chuỗi triển khai rsETH. LayerZero đã tạm dừng mọi giao dịch qua cầu OFT từ Ethereum. Hơn 20 người giữ rsETH trên hơn 20 chuỗi L2, số lượng token trong tay họ trong một đêm không biết có còn bảo đảm hay không.

Đây là một rủi ro hệ thống của việc triển khai đa chuỗi: rsETH đồng thời lưu thông trên Arbitrum, Optimism, Base, Scroll và các chuỗi 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 mạng chính Ethereum. Khi cầu mạng chính bị đột nhập, rsETH trên mỗi chuỗi L2 đều mất bảo đảm đồng thời—người giữ không thể rút token và cũng không thể xác minh xem token trong tay họ còn giá trị không. earnETH của Lido (giữ rsETH không rủi ro), cầu mạng LayerZero của Ethena—tất cả đều bị tạm ngừng. Vùng tác động của vụ nổ vượt xa cả Kelp.

Phát hiện 3: Quyền Kiểm soát Thống trị Chéo Chuỗi Chưa Được Xác Thực (Vấn đề liên quan)

Bản gốc báo cáo: 「Quyền kiểm soát thống trị của mỗi chuỗi LayerZero OFT chưa được xác thực—đặc biệt là: liệu quyền kiểm soát này có thuộc về cùng một mạng 6/8 nhiều chữ ký và khoá thời gian 10 ngày, hay có được kiểm soát bởi các khóa quản lý độc lập」

Đã xảy ra gì: Cấu hình DVN rõ ràng không nằm dưới sự kiểm soát thống trị nghiêm ngặt của giao thức cốt lõi. Nếu các thay đổi cấu hình cầu cầu tiến hành qua 6/8 nhiều chữ ký cộng với khoá thời gian 10 ngày, cấu hình DVN 1-of-1 sẽ cần sự đồng ý của 6 trong số 8 người ký dựng—cấu hình như vậy khó có thể không có người quản lý.

Điều này đã phơi bày một điểm mù thông thống: rất nhiều giao thức thiết lập có nhiều chữ ký và khoá thời gian nghiêm ngặt cho việc nâng cấp hợp đồng cốt lõi, nhưng đối với các thay đổi vận hành—cầu cầu, tham số trình nhanh, quản lý danh sách trắng—thường chỉ có một khóa quản trị duy nhất có thể điều chỉnh. Thống trị giao thức cốt lõi của Kelp là tiên tiến trong ngành (6/8 nhiều chữ ký + khoá thời gian 10 ngày), nhưng những biện pháp bảo vệ này không mở rộng ra phạm vi tấn công lớn nhất của nó: cầu chéo chuỗi.

Khám phá 4: Phát hiện Mẫu Tấn Công Ronin/Harmony (Tấn công trực tiếp)

Bản gốc báo cáo: “Tiền lệ lịch sử có liên quan nhất liên quan đến an toàn của cầu. Kelp trên Lớp Zero của 16 chuỗi triển khai, mang lại sự phức tạp vận hành tương tự kiến trúc đa chuỗi của Ronin”

Đã xảy ra thực sự: Con đường tấn công gần như sao chép hoàn toàn kịch bản của Ronin - xâm nhập vào các nhà xác thực của cầu, làm giả tin nhắn, rút hết tài sản. Mô-đun phù hợp của công cụ tấn công của chúng tôi so sánh kiến trúc giao thức và danh mục tấn công lịch sử, chính xác xác định đây là vector tấn công có nguy cơ cao nhất.

Lịch sử: Năm 2022, Ronin Bridge đã mất 6.25 tỷ USD do 5 trong tổng số 9 nhà xác thực bị xâm nhập; cùng năm đó, Horizon Bridge của Harmony đã mất 1 tỷ USD do 2 trong tổng số 5 nhà xác thực bị xâm nhập.

Tình hình của Kelp càng tồi tệ hơn - chỉ có 1 nhà xác thực, đã đẩy ngưỡng tấn công xuống thấp nhất có thể. Lý do công cụ có thể xác định rủi ro này chính 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, chứ không chỉ nhìn vào mã nguồn.

Khám phá 5: Không có Quỹ Bảo hiểm (Làm tăng mức thiệt hại)

Bản gốc báo cáo: “Hiện tại giao thức không có Quỹ Bảo hiểm chuyên dụng, cũng không có cơ chế chịu thiệt hại xã hội để hấp thu sự kiện phạt”

Đã xảy ra thực sự: Do không có dự phòng bảo hiểm, toàn bộ thiệt hại 2.92 tỷ USD đã bị giao thêm cho giao thức phía dưới. Dự phòng thu hồi của Aave chỉ bao phủ 30% của 1.77 tỷ USD thiệt hại của nó. LP không liên quan đến quyết định cấu hình cầu Kelp - chịu tổn thất lớn nhất.

Người tấn công đã sử dụng rsETH đánh cược, gửi vào Aave V3, Compound V3, Euler, sau đó vay ra WETH thật. Khi rsETH không còn đảm bảo, các vị thế này trở thành nợ xấu “không thể thanh toán” - tài sản đặt cược trở thành giấy vụn, nhưng WETH đã vay thì mất. Tỷ lệ sử dụng WETH trên Aave tăng gấp đôi, người dùng thông thường không thể rút tiền. 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, tài sả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 kỷ luật cụ thể, không bao phủ rủi ro lõng lẻo cốt lõi của giao thức rsETH.

Đây là trường hợp cả hai bên đều chưa hoàn thành trách nhiệm của mình. Phía Kelp: một giao thức quản lý TVL 13 tỷ USD, không có hồ bảo hiểm, không có cơ chế hấp thụ lỗ hại. Khi cầu bị phá vỡ, không có bất kỳ phần đệm nào để hấp thụ thiệt hại. Phía Aave: chấp nhận rsETH là tài sản đặt cược, nhưng chưa đánh giá đầy đủ rủi ro cấu hình cầu liên chuỗi của nó.

Các thông số rủi ro của Aave (LTV, ngưỡng thanh lọc) được thiết kế cho đợt biến động giá bình thường, nhưng không tính đến rủi ro phía sau như "việc cấu hình cầu bị phá vỡ dẫn đến tài sản đặt cược mất giá qua đêm". Dự trữ khôi phục ngay cả 30% cũng không đủ để bù đắp. Về bản chất, đây là một lỗi trong việc đị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 sự nó đi kèm với rủi ro nhị phân từ việc cầu thất bại. Sự thất bại từ cả hai phía - Kelp không có bảo hiểm ngăn chặn tài sản đặt cược xấu vào hệ thống, Aave không thực hiện mô hình hóa rủi ro đủ tinh tế để hạn chế rủi ro trong tình huống này.

Chúng ta đã sai ở đâu

Có ba điều chúng ta nên làm tốt hơn:

Đánh giá rủi ro bị đánh giá thấp. Chúng tôi đã xếp hạng rủi ro của cầu liên chuỗi là "trung bình". Trong báo cáo, có 5 thiếu sót thông tin chưa được giải quyết, trong đó có 3 liên quan đến cấu hình cầu LayerZero và phù hợp với mô hình tấn công lịch sử của Ronin/Harmony - điều này nên được xếp hạng là "cao" hoặc "nghiêm trọng". Sự không minh bạch mặc định nên là một tín hiệu mạnh mẽ hơn.

Chúng ta không thể xuyên qua 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 một cách độc lập. Đây chính là lỗ hổng cấu trúc chính mà phân tích sau sự kiện của Ju Huế Net đã chỉ ra: Công cụ kiểm tra hiện tại tập trung vào logic mã nguồn và không thể bắt được rủi ro ở tầng cấu hình. Chúng tôi đã đánh dấu vấn đề, nhưng không thể trả lời.

Chúng ta không kiểm tra trên chuỗi. Cấu hình DVN thực tế có thể được đọc trực tiếp trên chuỗi thông qua hợp đồng EndpointV2 của LayerZero. Chúng tôi đã có thể truy vấn registry ULN302 để xác minh ngưỡng DVN của Kelp mà không cần đánh dấu là "chưa tiết lộ công khai". Nếu chúng tôi đã kiểm tra vào thời điểm đó, chúng tôi có thể thấy ngay cấu hình 1 trên 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á liên chuỗi.

Phát hiện không cụ thể, không hành động được. Nói rằng "cấu hình DVN không được tiết lộ" chỉ là quan sát về thiếu sót tài liệu - không phải dự đoán tấn công. Những rủi ro như tập trung của bộ dự báo, phụ thuộc vào cầu, thiếu bảo hiểm thực sự cũng phổ biến trong hầu hết các giao thức DeFi liên chuỗi. Công cụ đã đánh dấu sự không minh bạch của Kelp, nhưng cũng đã đưa ra nhãn tương tự trên nhiều giao thức khác chưa bị tấn công. Trong tình hình không có mức phổ biến thông tin sai, việc tuyên bố "chúng tôi đã dự đoán được" làm phồng hoặc hơn. Cách nói trung thực hơn là: Chúng tôi đặt ra một số câu hỏi đúng mà không ai đặt ra, trong đó có một câu hỏi trọng điểm ngẫu nhiên.

Về "Tiết Lộ Trách Nhiệm"

Một vấn đề công bằng: Nếu chúng ta đã đánh dấu các 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 bị tấn công vào ngày 18 tháng 4?

Không thông báo. Lý do là: Báo cáo nhận diện là 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 trên 1, chỉ biết rằng cấu hình không được công khai. Không có gì cụ thể để tiết lộ. "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 để gửi vào chương trình thưởng lỗi.

Sau khi xem xét, chúng tôi có thể đã liên hệ trực tiếp với nhóm Kelp, hỏi về ngưỡng DVN của họ. Cuộc trò chuyện đó có thể làm tiết lộ cấu hình 1 trên 1 và thúc đẩy quá trình sửa chữa. Chúng tôi đã không làm điều đó. Điều này là bài học: Ngay cả khi một phát hiện nào đó trông quá mơ hồ, không phù hợp để đi qua 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 đáng giá.

Sự Kiện Này Có Ý Nghĩa Gì Đối Với An Ninh DeFi

Kelp đã bị đánh cắp - giống như việc Drift bị đánh cắp cách đây 17 ngày - không phải là lỗ hổng trong hợp đồng thông minh. Các công cụ quét mã tự động như Slither, Mythril, hay thậm chí là GoPlus đều không thể phát hiện. Lỗ hổng nằm trong cấu hình triển khai, kẽ hở quản trị, quyết định kiến trúc, nằm ở tầng mã nguồn cao hơn.

Điều này cũng chính là lập luận cốt lõi của kỹ năng an ninh dự án tiền điện tử:

An toàn giao thức không chỉ là an toàn mã nguồn. Một giao thức có thể có hợp đồng thông minh Solidity hoàn hảo, được kiểm tra bởi năm lần từ các công ty hàng đầu, có 250,000 USD thưởng lỗi - sau đó vì vấn đề cấu hình cầu xảy ra, vẫn bị đánh cắp 292 triệu USD.

Công cụ này đã được mã nguồn mở trên GitHub - bất kỳ ai đều có thể xem xét phương pháp luận, chạy thử nghiệm, hoặc cải thiện nó.

Dòng Thời Gian

12 ngày. Tín hiệu đã xuất hiện từ lâu. Vấn đề là: Cộng đồng cần xây dựng công cụ để nhìn thấy những tín hiệu này trước khi cầu tiếp theo gãy.

Bạn Có Thể Làm Gì

Nếu bạn đang giữ tài sản trong một giao thức DeFi có cầu nối liên chuỗi:

1. Tự kiểm tra kiểm toán một lần. Công cụ này là mã nguồn mở. Đừng tin chúng tôi — hãy tự xác thực.

2. Xem cấu hình xác minh cầu. Nếu một giao thức không muốn tiết lộ ngưỡng DVN của mình, hãy coi đó là một dấu hiệu đỏ. Báo cáo của chúng tôi làm điều này, và sự thực đã chứng minh điều đó.

3. Đừng nghĩ rằng việc kiểm tra mã sẽ bao trùm tất cả mọi thứ. Kelp đã được kiểm tra mã hơn 5 lần bởi 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 bắt ngưỡng DVN — một loại rủi ro ở tầng cấu hình này — điều này không phải là sơ suất của công ty kiểm toán.

4. Đánh giá phạm vi bảo hiểm. Nếu một giao thức không có hồ 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à tài sản thế chấp, bạn đang ẩn ngầm đảm bảo cho nó. Người đưa tiền vào Aave lần này, sử dụng WETH, đã học được điều này theo cách khó nhất.

Bức tranh lớn hơn: AI Agent như một tầng an ninh

Bài viết này kể về một công cụ và một vụ trộm. Nhưng lập luận đằng sau lớn hơn: AI Agent có thể trở thành một tầng an ninh độc lập cho nhà đầu tư DeFi.

Mô hình an ninh truyền thống trong ngành 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 tạo báo cáo. Mô hình này có điểm mù — sự kiện Kelp chỉ minh họa điều này, tập trung vào tính chính xác của mã, nhưng bỏ qua rủi ro ở tầng cấu hình, quản trị, kiến trúc.

Claude Code và các công cụ kỹ năng tương tự mở ra một cách tiếp cận khác: bất kỳ ai đều có thể sử dụng dữ liệu công khai, trong vài phút kiểm thử rủi ro hỗ trợ AI cho bất kỳ giao thức nào. Bạn không cần bỏ ra 200,000 USD để thuê công ty kiểm toán. Bạn không cần biết đọc Solidity. Bạn chỉ cần để agent so sánh cấu trúc giao thức với các mẫu tấn công đã biết, và nó sẽ đặt ra các câu hỏi bạn nên hỏi trước khi gửi tiền.

Điều này không thay thế cho kiểm toán chuyên nghiệp — nhưng nó hạ thấp ngưỡng cửa cho giai đoạn đầu của công tác kiểm tra diligence đến mức mà bất kỳ ai cũng có thể sử dụng. Một LP đang xem xét đưa vốn vào một giao thức vay lại thế chấp mới, bây giờ có thể thực hiện một bài kiểm tra DeFi audit.

Báo cáo về Kelp không hoàn hảo. Nó xếp hạng rủi ro của cầu không nhịp là trung bình, nên là nghiêm trọng. Nó không đi sâu vào tầng cấu hình. Nhưng nó đã đặt ra những câu hỏi đúng — nếu nhóm Kelp hoặc bất kỳ LP nào đã xem thường những câu hỏi này, tổn thất 2.92 tỷ USD có thể tránh được.

Liên kết gốc

Chào mừng bạn tham gia cộng đồng chính thức của BlockBeats:

Nhóm Telegram đăng ký: https://t.me/theblockbeats

Nhóm Telegram thảo luận: https://t.me/BlockBeats_App

Tài khoản Twitter chính thức: https://twitter.com/BlockBeatsAsia