Bài học tỷ đô la: An ninh DeFi đang chuyển trọng tâm từ mã nguồn sang quản trị vận hành

Bản dịch: Cộng đồng Đăng Liên

Tóm tắt nội dung và hướng dẫn đọc:

Trong gần một năm, DeFi đã mất gần 1 tỷ USD, thiệt hại lớn thực sự không còn chủ yếu đến từ lỗ hổng hợp đồng thông minh nữa, mà đến từ quản lý quyền hạn, quy trình ký, tấn công xã hội, hạ tầng bên thứ ba và rủi ro khả năng hợp tác xuyên chuỗi. Học hỏi từ sự bền bỉ vận hành của TradFi, ba lớp phòng thủ, đóng băng khẩn cấp, quản trị dữ liệu rủi ro và kiểm tra tiếp cận tài sản, kết hợp phân tích an ninh hỗ trợ AI, mới có thể giữ được tính mở và khả năng hợp tác đồng thời nâng cao an toàn cho vốn người dùng.

Chúng ta không cần phải mất đi hàng tỷ đô la như vậy

Trong 12 tháng qua, gần 1 tỷ USD đã bị mất do các sự cố DeFi, nhưng phần lớn trong số đó hoàn toàn có thể tránh được.

Bắt đầu từ vụ khai thác gần nhất: ngày 18 tháng 4, vụ khai thác 2,92 tỷ USD của Kelp DAO.

AAVE giảm 15%. Aave đã đóng băng thị trường rsETH trong tất cả các triển khai, sau đó lại đóng băng cho vay WETH để phòng ngừa. Hợp đồng của Aave chưa từng bị khai thác, nhưng trong vòng vài giờ, tỷ lệ sử dụng của thị trường WETH đạt 100%. Những người cung cấp WETH chưa từng chạm vào rsETH đột nhiên không thể rút tiền.

Tiếp theo là các quan điểm phổ biến trên crypto twitter: Bridge hỏng rồi. DeFi hỏng rồi. Đó là lý do tại sao vốn thực sự không đổ vào nữa.

Tôi cho rằng những lời này đều chưa nắm bắt đúng trọng tâm.

Phần lớn trong số 1 tỷ USD này, là do các vector tấn công đã được bàn luận và có giải pháp sửa chữa từ trước, gây ra thiệt hại. Thiệt hại lớn nhất chủ yếu do truy cập đặc quyền, quy trình ký, tấn công xã hội và hạ tầng bên thứ ba, chứ không phải do lỗi smart contract riêng lẻ. Tuy nhiên, các giải pháp sửa chữa này không nằm trong tài liệu DeFi, mà trong sổ tay kiểm soát rủi ro ngân hàng, nghiên cứu về bền bỉ kỹ thuật, và các playbook vận hành đã được TradFi mài giũa hàng chục năm.

Kelp chính là ví dụ rõ ràng nhất.

Một verifier. Một điểm lỗi.

Vụ khai thác của Kelp không phải do lỗi hợp đồng thông minh. Nguyên nhân chính nằm ở chỗ @KelpDAO đã chọn cấu hình mạng xác thực phi tập trung (DVN) 1-đối-1 trên LayerZero bridge. Theo cáo buộc, hacker liên quan nhóm tội phạm mạng Lazarus của Triều Tiên, không xâm phạm DVN về mặt kỹ thuật. Trước tiên, họ xác định các RPC providers mà LayerZero DVN phụ thuộc. Sau đó, họ tấn công hai trong số đó, khiến chúng trả về dữ liệu giả mạo. Tiếp theo, họ tấn công các providers còn lại bằng DDoS, buộc hệ thống chuyển sang các node đã bị xâm phạm. Trong tình huống thiện chí, DVN đã ký một tin nhắn xuyên chuỗi giả mạo — vì không có verifier nào khác xác minh kết quả, nên ký này đủ để hệ thống chấp nhận.

Một verifier. Một điểm lỗi.

116.500 rsETH từ LayerZero OFT Adapter (quản lý token xuyên nhiều blockchain) trên Ethereum bị phát hành cho hacker, khiến 16 lớp rsETH OFT trên các Layer2 mất backing. Hacker dùng rsETH trên Ethereum làm tài sản thế chấp gửi vào Aave, Compound, Euler, rồi vay 2,36 tỷ USD WETH cho đến khi bị phát hiện. Hiện tại, tất cả những ai nắm giữ rsETH trên một Layer2 đều chỉ còn quyền đòi lại một chiếc lockbox đã bị rút sạch.

Rủi ro rõ ràng này đã được cảnh báo từ 12 ngày trước.

Ngày 6 tháng 4, kỹ sư @liliangjya5 của @get_truenorth đã phát hành một kỹ năng mã nguồn mở Claude Code, trong đó nhấn mạnh vấn đề không minh bạch trong cấu hình DVN, coi 16 chuỗi là điểm yếu lớn nhất, và so sánh với các vụ khai thác bridge Ronin và Harmony năm 2022. Thời điểm commit rõ ràng — ai cũng có thể xem.

[]

Kelp chưa từng công khai ngưỡng DVN của họ. LayerZero trong checklist tích hợp rõ ràng khuyến nghị dùng cấu hình multi-DVN. Kelp vẫn chọn 1-đối-1. Không ai bắt buộc họ công khai, cũng không ai bắt buộc họ sửa đổi.

Sau 12 ngày, 2,92 tỷ USD đã biến mất.

Trong 12 tháng qua, DeFi vẫn chưa thể phủ nhận

Vụ khai thác của Kelp là lớn nhất, nhưng không phải duy nhất.

• Chỉ hai tuần trước, ngày 1 tháng 4, Drift sau nhiều tháng tấn công xã hội đã mất 285 triệu USD. Hacker lợi dụng nonces bền vững của Solana để có chữ ký quản trị hợp lệ, whitelist một token vô giá trị làm collateral, rồi rút sạch tài sản thật. Ít nhất 20 protocol khác cũng báo cáo bị ảnh hưởng. Drift trong kế hoạch tái cấu trúc sau đó đã thêm thiết bị ký riêng, timelock cho quản trị, và multisig mới.

• Ngày 22 tháng 3, Resolv bị tấn công qua hạ tầng offchain. Hacker xâm nhập từ điểm yếu của dự án thứ ba, truy cập vào GitHub và môi trường đám mây của Resolv, lấy quyền ký mint, tạo ra 80 triệu USR không backing, rồi trộm 25 triệu USD ETH. Hợp đồng thông minh không bị lỗi, điểm yếu nằm ở key đặc quyền và hệ thống vận hành xung quanh.

• Ngày 10 tháng 3, Aave tự nó gặp vấn đề về risk tooling khi hai tham số oracle không phù hợp, gây thanh lý khoảng 26 triệu USD, liên quan đến 34 tài khoản. Sự không phù hợp này khiến giá wstETH giảm 2,85%. Trong trường hợp này, không có kẻ xấu hay khai thác, chỉ là cập nhật cấu hình thiện chí, nhưng không được kiểm thử trong môi trường hostile.

• Trước khi bắt đầu năm 2026, chúng ta còn chứng kiến Cetus mất 223 triệu USD trên Sui, Cork mất 12 triệu USD sau nhiều lần audit do mất wstETH, Balancer mất hơn 120 triệu USD vào tháng 11, và Aerodrome không phải do khai thác hợp đồng, mà do DNS hijack của nhà đăng ký tên miền, gây thiệt hại hơn 1 triệu USD. Nhấn mạnh lại, hợp đồng không bị tổn hại. Một trang phishing đã hoàn tất đòn cuối cùng.

Tổng cộng, gần 1 tỷ USD thiệt hại. Nguyên nhân trực tiếp của mỗi vụ đều khác nhau, nhưng một mô hình đang hình thành.

Các vụ khai thác này đã chuyển sang offchain

Rủi ro hợp đồng thông minh không biến mất — Cetus, Cork và Balancer đều là thất bại logic onchain thực sự. Bất kỳ protocol nào còn coi invariant testing, adversarial simulation và formal methods là tùy chọn, chỉ cần một lần phát hành nữa là sẽ rút ra bài học. Nhưng điều đó đã không còn là câu chuyện chính nữa.

Nhìn toàn bộ thị trường crypto, Chainalysis ước tính đến năm 2025 sẽ có hơn 6,5 tỷ USD bị đánh cắp, trong đó ba vụ hack lớn nhất chiếm 69% thiệt hại. Như đã đề cập, thiệt hại lớn nhất vẫn do truy cập đặc quyền, quy trình ký, tấn công xã hội và hạ tầng bên thứ ba gây ra, chứ không phải lỗi smart contract riêng lẻ.

Tôi xem đây là ba dạng thất bại khác nhau: Code layer, Control plane, Chức năng hợp tác (Composability).

2. Code là lớp mà DeFi thực sự giỏi phòng thủ nhất, nhưng ngay cả vậy, nó vẫn chưa hoàn toàn giải quyết được. Chúng ta có fuzzing, phân tích tĩnh và động, xác minh chính thức, bug bounty, audit, invariant testing — hiện mỗi đội ngũ nghiêm túc đều biết làm những điều này.

3. Control plane là nơi DeFi còn tụt hậu ít nhất so với TradFi. Thiết bị ký, xoay khóa, kiểm tra truy cập đặc quyền, provenance CI/CD, hardening DNS, an toàn tên miền. Hầu hết protocol thậm chí còn không có danh mục các surface này, chứ đừng nói kiểm soát chúng.

4. Chức năng hợp tác (Composability) dù là lợi thế lớn nhất của DeFi, nhưng cũng mang lại rủi ro mới, ít được đánh giá đúng — khi một thị trường cho vay liệt kê một tài sản wrapped, nó biến mode failure của bridge thành mode failure của chính nó. Khi một vị thế nợ có thế chấp nhận token staking lỏng, nó thừa hưởng độ trễ quản trị của nhà phát hành. Aave không viết một dòng code nào của Kelp, nhưng vẫn chịu thiệt hại do thất bại của Kelp — điều này cũng phơi bày vấn đề quản trị của chính nó.

Nếu một protocol liệt kê tài sản thế chấp mà không thể tự định giá, đóng băng, cắt lỗ hoặc thanh lý trong điều kiện áp lực, thì thực chất nó đã đưa tail risk của tài sản đó vào bảng cân đối của mình, bất kể quỹ dự trữ có ký hay không.

TradFi đã có sẵn playbook

Về tranh luận “làm giống TradFi hơn” trong DeFi, thường sẽ đi lệch hướng ngay từ bước này. Trong crypto, trực giác là, làm giống TradFi nghĩa là chậm hơn, kiểm soát nhiều hơn, permissioned hơn, có nhiều quy định hơn.

[]

Tôi cho rằng điều này là sai.

Dù TradFi không hoàn hảo, nhưng đã nghĩ ra nhiều thứ hữu ích hơn permissioning rất nhiều. Nó đã phát minh ra cách vận hành các hệ thống quan trọng trong disruption — các khung này đã tồn tại. Chúng đã trải qua thử thách trong hàng chục năm sụp đổ ngân hàng, gián đoạn giao dịch, tấn công mạng và sự cố vận hành.

Ví dụ liên quan:

• NIST Cybersecurity Framework 2.0 nâng cao chức năng Govern ngang hàng với Identify, Protect, Detect, Respond và Recover.

• Basel Committee on Banking Supervision định nghĩa operational resilience là khả năng duy trì hoạt động quan trọng trong disruption.

• Cơ quan Quản lý Tài chính Vương quốc Anh (FCA) yêu cầu các công ty xác định dịch vụ kinh doanh quan trọng, đặt giới hạn tác động, và kiểm tra xem disruption có vượt qua các giới hạn này không.

• Viện Kiểm toán Nội bộ (IIA) qua mô hình Three Lines tách biệt quản lý, thách thức rủi ro và đảm bảo độc lập.

Tất cả đều không cần tài sản hoặc bảng cân đối của TradFi, không cần permission. Tất cả đều có thể chuyển sang DeFi. An toàn trong DeFi không có nghĩa là biến thành ngân hàng, mà là duy trì tính mở của người dùng và khả năng hợp tác, đồng thời áp dụng kỷ luật ngân hàng ở control layer.

Khi Lazarus tấn công RPC providers của LayerZero, họ dùng playbook giống như tấn công SWIFT và chuỗi cung ứng phần mềm doanh nghiệp. TradFi đã có 30 năm kinh nghiệm trong vấn đề này. Nhưng DeFi dường như nghĩ rằng mình không thể học hỏi từ lịch sử của TradFi.

Quyền đặc quyền (power) là một tiện ích hệ thống quan trọng

Quyền đặc quyền phải khó hơn để sử dụng so với các chức năng thông thường của protocol. Bất kỳ key, multisig hoặc tài khoản dịch vụ nào có thể liệt kê collateral, di chuyển reserves, cập nhật oracle, thay đổi peer bridge hoặc logic thanh lý, đều là một tiện ích tài chính hệ trọng. Tiêu chuẩn tối thiểu:

• Ví phần cứng

• Xác thực chống phishing

• Máy ký riêng biệt

• Giải mã ngoài chuỗi cho các giao dịch

• Phân tách quorum

• Đặt timelock cho tất cả các thao tác không khẩn cấp

• Rõ ràng từ chối các chức năng tiện lợi có thể bị lợi dụng để kích hoạt ký dormant trong tương lai

Kế hoạch tái cấu trúc sau sự cố của Drift là một chuẩn tối thiểu tốt.

Hạ tầng offchain cũng là một phần của protocol. Quản lý mã nguồn, CI/CD, IAM đám mây, registry gói, tên miền, DNS, surface WalletConnect và giao diện trình duyệt đều nằm trong phạm vi các mối đe dọa thực tế. Các tiêu chuẩn kỹ thuật bao gồm quyền truy cập tối thiểu, xác thực dựa trên phần cứng, triển khai không secret, xây dựng có thể tái tạo với bill of materials, và khóa dependency. Ở ranh giới, các biện pháp như khóa registrar, hardening DNS và mirror front end phi tập trung có thể duy trì liên tục trong thời gian khủng hoảng.

DNS hijack của Aerodrome nhắc nhở chúng ta rằng ranh giới an ninh còn lớn hơn nhiều so với những gì hầu hết nhóm nghĩ.

Mọi thay đổi đều cần được kiểm thử theo kịch bản hostile. Verifier xuyên chuỗi nên kiểm tra proof, chứ không phải attestation. Bridge chuẩn sẽ xác minh merkle proof của block headers đã ký, là một dạng bảo đảm mã hóa: node bị tấn công có thể từ chối cung cấp dữ liệu, nhưng không thể giả mạo. Kiểm tra proof mạnh hơn attestation, nhưng bridge dựa trên proof vẫn thừa hưởng rủi ro đồng thuận, rủi ro triển khai và rủi ro nâng cấp. Vấn đề là, thiết kế này loại trừ những thất bại nào, và còn giữ lại những thất bại nào.

Verifier dựa trên attestation không có cùng mức đảm bảo. Chúng ký bất kỳ nội dung nào từ RPC endpoints trả về, khiến các endpoint này trở thành bề mặt tấn công. Nếu dùng attestation để tăng tốc hoặc phù hợp chuỗi, quorum thể hiện tính độc lập chứ không phải số lượng. Năm validator đọc cùng một RPC bị đầu độc sẽ ký cùng một lời dối trá năm lần. Chỉ khi các thành viên quorum có nguồn dữ liệu thực sự độc lập, thì mới đảm bảo an toàn, lý tưởng là kết hợp nodes riêng và nodes công khai đáng tin cậy. Kelp chính là kết quả của việc attacker lợi dụng lỗ hổng này.

Không phải tất cả collateral đều xứng đáng đưa vào bảng cân đối chung. Tài sản bridge, token restaking lỏng, share vault, dollar tổng hợp và wrapper token đều nên coi như các sản phẩm có cấu trúc. Chúng cần có memo onboarding riêng, bao gồm rủi ro rộng, hạn mức bảo thủ. Trong hầu hết các trường hợp, chúng nên vào thị trường cách ly, chứ không phải pool chính chia sẻ.

Aave đã tạm dừng rsETH từ tháng 4 năm 2025 do bug over-mint của Kelp. Một năm sau, rsETH trở lại thị trường chung, điều này cần được xem xét kỹ hơn.

Phát hiện và phản ứng phải vận hành ở tốc độ máy. Khi một protocol có thể bị rút sạch trong vài phút, chỉ dựa vào quản trị thủ công là biểu diễn của sự yếu kém. Tự động hóa hạn chế là tiêu chuẩn: phát hiện bất thường trong quản lý admin, mint và burn, utilization tăng đột biến, oracle mất peg, lưu lượng bridge, rồi kết hợp rate limit, throttle vay mượn, và auto-freeze dựa trên điều kiện đã định trước, có thể kiểm duyệt sau này qua governance, phạm vi hoạt động hẹp.

Chúng ta cần ưu tiên bảo vệ an toàn vốn người dùng. Những tự động hóa như vậy, dù gây chút bất tiện, vẫn còn tốt hơn nhiều so với không có tự động nào từ ban đầu.

Quản trị phải xác định những điều không thể thất bại

Để giúp nhóm xác định mục tiêu an toàn, quản trị cần rõ ràng liệt kê những việc tuyệt đối không thể thất bại. Hội đồng quản trị, quỹ hoặc DAO cần xác định rõ các dịch vụ kinh doanh quan trọng: gửi tiền rút tiền, thanh lý, cập nhật oracle, thực thi quản trị, bridge vào ra, truy cập frontend, truyền thông sự cố.

Với mỗi dịch vụ, cần đặt giới hạn tác động (impact tolerance), bao gồm mức thiệt hại tối đa cho người dùng, tổn thất khả năng thanh toán, thời gian ngưng hoạt động và độ không chắc chắn dữ liệu, rồi kiểm tra xem các giới hạn này có còn đúng trong các kịch bản nghiêm trọng nhưng hợp lý hay không.

Điều này chính là ý nghĩa của operational resilience trong ngân hàng, và có thể chuyển sang DeFi.

DeFi nên áp dụng mô hình Three Lines thực sự:

• Đường 1: Sản phẩm, kỹ thuật, treasury và vận hành chịu trách nhiệm về rủi ro do mình tạo ra và các biện pháp kiểm soát giảm thiểu.

• Đường 2: Các chức năng độc lập về rủi ro và an ninh, có quyền rõ ràng, thách thức việc list, tham số, nâng cấp và đối tác, đồng thời làm chậm hoặc ngăn chặn các thay đổi không an toàn.

• Đường 3: Báo cáo assurance độc lập về việc đường 1 và 2 có thực sự hoạt động đúng không.

Tính độc lập là cách ngăn các nhóm vì lợi ích tăng trưởng tự cho phép tự phê duyệt.

Onboarding tài sản nên giống như quá trình tín dụng, chứ không phải phát triển kinh doanh. Memo list phải bao gồm thanh khoản, độ tập trung, quản trị tập trung, đường đi của bridge và khả năng nâng cấp, cơ chế mua lại, circuit breaker, cách xây dựng oracle và pháp lý. Nếu bất kỳ giả định nào bị phá vỡ, memo đó phải có quy trình giảm cấp rõ ràng.

Quyền khẩn cấp cần hẹp, xác định rõ phạm vi và có chế độ sunset. Phiên bản recovery của Cetus và Sui cho thấy hai mặt của vấn đề này — can thiệp khẩn cấp có thể cứu hàng trăm triệu USD. Nó cũng đặt ra câu hỏi nghiêm trọng: ai có thể kiểm soát các hệ thống không thể bị chặn trong lý thuyết, và dựa trên cơ sở nào. Câu trả lời là, trước khi ra mắt, chứ không phải trong khủng hoảng, cần xác định rõ điều kiện kích hoạt, người được ủy quyền, tiêu chuẩn chứng cứ, thời gian tối đa duy trì, nghĩa vụ minh bạch và lộ trình trở lại quản trị bình thường.

Mỗi protocol cần chuẩn bị sẵn kế hoạch giải quyết khủng hoảng. Drift đang xây dựng recovery pool sau sự cố. Aave đã chuyển sang bồi thường cho người dùng sau sai lệch oracle. Resolv đã hoàn trả 1:1 cho các chủ sở hữu trước khi bị hack. Đây đều là phản ứng hợp lý, nhưng tiêu chuẩn cao hơn là ủy quyền trước các quy trình thác nước: bảo vệ người dùng trước, rồi quỹ dự trữ, rồi bảo hiểm hoặc module an toàn, rồi trách nhiệm nhà cung cấp dịch vụ, và đặt ra ngưỡng rõ ràng cho tổn thất xã hội hóa.

Phân biệt các protocol nghiêm túc về quản trị và các protocol không coi trọng quản trị, dựa trên 3 câu hỏi: ai có thể ngăn chặn một launch không an toàn? ai có thể đóng băng thị trường theo điều kiện đã định? khi một nhà cung cấp dịch vụ ủy thác gây thiệt hại, ai sẽ chịu trách nhiệm?

Một protocol không thể xác định rõ các nhân sự liên quan, điều kiện kích hoạt và trách nhiệm, thì chưa thực sự có quản trị rõ ràng, chỉ đang cầu nguyện rằng exploit sẽ không xảy ra.

Dữ liệu rủi ro quyết định thành bại của các biện pháp kiểm soát

DeFi an toàn cần có một hệ thống dữ liệu sống động: các tín hiệu onchain và offchain thúc đẩy các hành động như đóng băng, giới hạn, thanh lý trong protocol. Control plane chịu trách nhiệm hành động, data plane cung cấp thông tin để quyết định.

Tiêu chuẩn dữ liệu và chất lượng dữ liệu cũng quan trọng không kém. Dữ liệu đưa vào oracle, đóng băng, thay đổi tham số cần rõ ràng về độ mới (freshness), provenance, điểm tin cậy (confidence), và phải có kiểm tra chéo với feed độc lập. Khi có mâu thuẫn, hành động fallback phải được định rõ trước, chứ không phải quyết định tạm thời.

Aave đề xuất oracle quản lý rủi ro cho USDe, cùng oracle Slope2 theo trọng số thời gian, đều hướng đúng. Sự kiện wstETH nhắc nhở rằng, mỗi vòng kiểm soát tự động đều cần có hàng rào phòng tránh lỗi cấu hình.

Việc tiết lộ chính là một dạng kiểm soát. Người dùng cần có trang trạng thái công khai, danh sách địa chỉ tấn công, nhật ký sự cố theo thời gian thực, tuyên bố ban đầu rõ ràng, và một báo cáo hậu sự cố, phân biệt rõ thực tế đã xác nhận và giả thuyết, định lượng chính xác thiệt hại, liệt kê các biện pháp kiểm soát đã thay đổi, và giải thích quy trình bồi thường. Các cập nhật phục hồi của Drift, báo cáo hậu sự cố của Resolv, và giải thích oracle của Aave, đều tốt hơn nhiều so với cách cũ là phát tán các tweet mơ hồ rồi im lặng. Chuẩn ngành nên có một bộ playbook truyền thông đã được luyện tập sẵn.

Ý nghĩa của dữ liệu rủi ro là để thúc đẩy hành động. Giới hạn cho vay, giảm giới hạn, tạm dừng thị trường, nâng cấp để xử lý thủ công, chứng minh một thị trường có thể tiếp tục an toàn — những phân tích không thể đưa vào control, limit hoặc assurance đều không xứng đáng gọi là hạ tầng rủi ro.

Mô hình đe dọa AI đã thay đổi

Mô hình đe dọa AI đã thay đổi vào tháng 4 năm 2026. Claude Mythos Preview của Anthropic đã chứng minh có thể phát hiện và khai thác tất cả các lỗ hổng zero-day trong các hệ điều hành và trình duyệt phổ biến. Các lỗ hổng này có hơn 99% chưa được công khai, vì chưa ai vá chúng. Các ngân hàng và cơ quan quản lý của Anh, Mỹ, Đức đã coi khả năng của Mythos như một rủi ro mạng thực tế.

Protocol DeFi cũng nên làm như vậy.

Xét từ góc độ thực tế, spear-phishing rẻ hơn, phát triển khai thác nhanh hơn, recon tự chủ hơn, và các trường hợp edge case ít tín hiệu sẽ được phát hiện sớm hơn. Phản ứng phòng thủ nên là:

• Máy làm việc của nhà phát triển cần được củng cố như endpoint đặc quyền

• Kiểm tra mã nguồn cần có AI hỗ trợ phân tích adversarial trong môi trường kiểm soát

• Quy trình signer mặc định phải có khả năng chống phishing

• Phát hiện bất thường và auto-response hạn chế nên giả định kẻ tấn công có tốc độ lặp lại nhanh hơn bất kỳ nhóm nào

Kể câu chuyện của Kelp chính là phiên bản lạc quan hơn của điều này. Cùng một khả năng AI đe dọa protocol, cũng có thể phòng thủ protocol. Một công cụ audit mã nguồn mở chạy trên Claude Code, đã phát hiện chính xác rủi ro của Kelp trước 12 ngày tấn công. Công cụ này không hoàn hảo: nó xếp rủi ro là trung bình, trong khi thực tế là critical; không thể xuyên thủng cấu hình mà không cần xác minh onchain; và còn bỏ sót một điểm quan trọng: cấu hình DVN có thể tra cứu trên chain qua LayerZero EndpointV2 contracts.

Nhưng nó đã đặt ra các câu hỏi đúng mà người khác chưa từng nghĩ tới.

Đây chính là mô hình nên áp dụng tiếp theo. AI như một lớp an ninh độc lập, bất kỳ LP, protocol hay auditor nào cũng có thể đứng trước để vượt mặt trong việc di chuyển vốn.

An toàn trong DeFi không có nghĩa là chậm lại

Sau vụ của Kelp, quan điểm chung là DeFi có vấn đề về an toàn. Tôi cho rằng cách framing này đã sai ngay từ đầu.

DeFi có các vấn đề về control plane, định giá khả năng hợp tác, và kỷ luật quản trị. Ba vấn đề này đều có giải pháp đã rõ từ ba mươi năm trước trong sổ tay rủi ro ngân hàng. Rào cản lớn nhất giữa DeFi và việc nâng cao an toàn cho người dùng chính là liệu các nhà sáng lập có thực sự thực thi chúng hay không.

An toàn trong DeFi không có nghĩa là chậm hơn. Slow và safe là hai thuộc tính khác nhau. Tính mở của người dùng, khả năng hợp tác 24/7 toàn cầu; kỷ luật ngân hàng trong control layer, thách thức độc lập, kiểm soát tốc độ máy, và đảm bảo liên tục — tất cả đều có thể cùng tồn tại.

Công cụ đã có sẵn. Playbook đã có sẵn. Vốn muốn có DeFi an toàn cũng đã có sẵn.

DeFi mới chỉ bắt đầu. Hãy đảm bảo nó còn tồn tại sau mười năm nữa.