Bạn có nghĩ rằng "tấn công flash loan" chỉ là màn kịch hacker trong phim, hoàn toàn khác với việc bạn gửi tiền vào Vault để nhận lãi?Vụ Summer.fi lần này lỗ ròng 6 triệu USD, nhưng lại bắt đầu từ một chuỗi thao tác gửi tiền, rút tiền hoàn toàn hợp pháp. Bài viết này sẽ không biến nó thành công nghệ đen bí ẩn, mà sẽ giúp bạn gỡ rối các hiểu lầm, lỗ hổng hạch toán và quy trình tấn công, cuối cùng cho bạn biết liệu số tiền bạn để trong Vault có đáng lo hay không.
Tấn công flash loan có phải là hacker xâm nhập ví của bạn? 3 hiểu lầm phổ biến nhất của người mới
Tấn công flash loan nghe có vẻ giống tình tiết phim — một hacker nhắm vào ví của bạn, chỉ vài giây là bẻ khóa private key rồi rút sạch tiền?Trong sự việc lần này của Summer.fi, không có ví của ai bị xâm nhập cả, kẻ tấn công chỉ dùng những chức năng hoàn toàn công khai của giao thức, và thổi phồng dữ liệu hạch toán khiến hệ thống tính sai.Hiểu rõ mấy hiểu lầm này, bạn mới nắm được quy trình tấn công phía sau, đây cũng là chỗ mình thấy nhiều người mới hiểu sai nhất.
Hiểu lầm 1: Tưởng rằng chỉ khi lộ private key mới gọi là bị mất trộm
Nhiều người vừa nghe "giao thức bị tấn công" là phản xạ ngay nghĩ đến chuyện private key bị đánh cắp, ví bị hack. Phản xạ này thường đúng với lừa đảo phishing hay app ví giả, nhưng áp dụng cho giao thức Vault như Summer.fi thì không đúng. Kẻ tấn công từ đầu đến cuối không hề lấy được private key của bất kỳ ai, cũng không dùng quyền quản trị viên — khoản flash loan hắn vay, số tiền hắn gửi vào, thao tác rút tiền hắn thực hiện, tất cả đều là chức năng bình thường mà Summer.fi mở cho mọi người dùng.
Nói cách khác, lỗ hổng lần này không nằm ở việc "khóa của ai bị đánh cắp", mà nằm ở cách giao thức tính toán tài sản trong Vault.Cho dù bạn giữ private key kỹ đến đâu, chỉ cần logic hạch toán bản thân có sơ hở, tài sản vẫn có thể bị thổi phồng đến mức mất giá trị. Đây cũng là lý do vì sao chỉ lo phòng phishing, phòng link giả thôi là chưa đủ — rủi ro trong chính thiết kế của Vault mới là bài học thực sự cần ghi nhớ từ sự việc này.
Hiểu lầm 2: Tưởng tấn công flash loan giống lừa đảo vay nợ thông thường
Một hiểu lầm phổ biến khác là coi tấn công flash loan như phiên bản phóng đại của lừa đảo nợ xấu, kiểu vay một khoản lớn để làm chuyện xấu rồi để lại đống nợ và bỏ trốn. Nhưng quy tắc của flash loan hoàn toàn khác: nó yêu cầu việc vay và trả phải hoàn tất trong cùng một block, cùng một giao dịch. Nếu chưa trả hết, cả giao dịch sẽ thất bại ngay lập tức, coi như chưa từng xảy ra.
Điều này có nghĩa là kẻ tấn công hoàn toàn không thể chịu rủi ro "quỵt nợ" — hắn buộc phải thao túng khoản vay 65,4 triệu USD để kiếm lời vượt vốn gốc trong một khoảng thời gian cực ngắn thì mới có thể toàn thân rút lui.Yếu tố then chốt của kiểu tấn công này là có tìm được sơ hở trong logic hạch toán hay không, chứ không phải gan có to hay không.Người mới nếu chỉ chú ý vào "vay bao nhiêu tiền" thì sẽ bỏ lỡ thủ đoạn thao túng thực sự cần quan tâm, đồng thời đánh giá thấp công sức chuẩn bị đằng sau kiểu tấn công này.
Hiểu lầm 3: Tưởng giao thức tạm dừng rút tiền nghĩa là tiền đã được thu hồi
Sau khi sự việc Summer.fi bùng nổ, giao thức nhanh chóng tạm dừng rút tiền ở tất cả các Vault, hành động này thường bị người mới hiểu nhầm thành "tiền đã được bảo toàn" hoặc "thiệt hại đã được cầm máu".Thực tế, tạm dừng rút tiền chỉ là để ngăn lỗ hổng tiếp tục bị lợi dụng, chặn đứng việc thêm tài sản của người dùng bị rút cạn bằng thủ đoạn tương tự, còn việc tiền có được thu hồi hay không là chuyện hoàn toàn khác.
Số tiền 6 triệu USD bị đánh cắp đã được đổi qua Curve thành DAI, rồi chảy vào Tornado Cash — loại công cụ trộn coin (mixer) này — tính đến hiện tại vẫn chưa có tiến độ thu hồi nào được công bố công khai. Khi bạn thấy các từ như "đã tạm dừng", "đang điều tra" trong thông báo của giao thức, điều đó chỉ có nghĩa là giao thức đang cầm máu, không có nghĩa là tiền của bạn đã lấy lại được. Nói cách khác, việc tạm dừng rút tiền bảo vệ những người dùng chưa bị ảnh hưởng, còn số tiền đã bị đánh cắp là chuyện hoàn toàn khác, đừng nhầm lẫn hai việc này với nhau.
Vì sao hạch toán Vault lại dễ bị thổi phồng đến vậy? Hãy hiểu rõ điểm đột phá tấn công mang tên totalAssets()
Vault vốn chỉ là nơi gom tiền của mọi người lại để kiếm lợi nhuận, vậy tại sao khâu hạch toán lại dễ gặp sự cố đến vậy?Cốt lõi vấn đề nằm ở "giao thức tính giá trị hiện tại của bạn như thế nào", chứ không phải bản thân cách giữ tiền có vấn đề gì.Hiểu rõ cách quy đổi share và hàm totalAssets() then chốt, bạn mới nhìn ra lỗ hổng của Summer.fi nằm ở bước nào.
Vault dùng share để quy đổi tài sản của bạn như thế nào
Số tiền bạn gửi vào Vault không được giao thức ghi sổ từng khoản một, mà được quy đổi thành một lượng "share" nhất định. Lấy tổng tài sản của Vault chia cho tổng số share đang lưu hành, ta được giá trị mỗi share, khi rút tiền (redeem) bạn lấy số share nhân ngược lại đơn giá này để tính ra được nhận lại bao nhiêu tài sản. Cách thiết kế này tiện lợi, dễ kết hợp (composable), nhưng cái giá phải trả là cả hệ thống chỉ tin vào một con số duy nhất — tổng tài sản của Vault thực sự là bao nhiêu.
Chỉ cần con số tổng tài sản bị tính sai hoặc bị thao túng, thì dù bạn gửi tiền cẩn thận đến đâu, số tiền tính ra khi rút cũng sẽ bị sai lệch theo. Trong kiến trúc của Summer.fi, việc tính toán này do hợp đồng FleetCommander đảm nhiệm, bên dưới nó kết nối với nhiều module chiến lược gọi là Ark, đưa tiền vào các giao thức cho vay khác nhau để kiếm lợi nhuận.Logic quy đổi share bản thân nó không sai, cái sai là con số tổng tài sản được dùng để quy đổi.
totalAssets() là gì, vì sao kẻ có ý đồ xấu có thể thổi phồng nó
totalAssets() là một hàm trong hợp đồng Vault, có tác dụng báo cáo theo thời gian thực "Vault này hiện đang nắm giữ tổng cộng bao nhiêu tài sản", đơn giá của mỗi share được tính dựa trên con số này. Lần đầu mình đọc mô tả về lỗ hổng này, mình cũng khá bất ngờ vì vấn đề lại nằm ở một chỗ cơ bản đến vậy: khi tính toán, module Ark của Summer.fi cũng cộng luôn "tài sản được gửi trực tiếp vào địa chỉ hợp đồng" vào tổng tài sản, mà không phân biệt xem khoản tiền đó có đi qua quy trình gửi tiền chính thống hay không.
Thiết kế này đồng nghĩa với việc để lại một cửa hậu: chỉ cần có ai đó sẵn sàng "tặng" (donate) tài sản trực tiếp cho Ark mà không qua kênh gửi tiền bình thường, totalAssets() vẫn cộng khoản tiền đó vào, đẩy giá trị mỗi share lên cao.Cách làm của kẻ tấn công rất đơn giản: trước tiên gom share với chi phí thấp, sau đó tặng tài sản vào để đẩy đơn giá lên, cuối cùng dùng số share đang có để đổi lấy số tiền đã bị thổi phồng, hoàn toàn không cần lấy trộm một xu nào trong Vault ban đầu.Điểm đột phá này chính là cốt lõi của toàn bộ sự việc.
Vì sao flash loan có thể hoàn tất toàn bộ thao túng chỉ trong một block
Nếu không có flash loan, thủ đoạn thao túng nói trên rất khó thành lập, vì kẻ tấn công phải chuẩn bị trước một khoản vốn lớn để gom share, thổi phồng tài sản — chi phí vốn cao, rủi ro cũng lớn. Flash loan giải quyết đúng vấn đề này — vay ngay lập tức một khoản tiền khổng lồ, hoàn tất việc gom share, tặng tài sản, rút tiền chốt lời trong cùng một block, rồi trả lại khoản vay cả gốc lẫn lãi, toàn bộ quy trình diễn ra liền mạch.
Đây cũng là lý do vì sao kiểu tấn công này thường kết thúc chỉ trong vài giây, trong thời gian một block, bạn hoàn toàn không kịp phản ứng.Đối với người dùng thông thường, điều quan trọng không phải là hiểu cách kích hoạt flash loan, mà là nhìn ra một việc: bất kỳ Vault nào có thiết kế dựa vào việc tính tổng tài sản theo thời gian thực, đồng thời cho phép bên ngoài tặng tiền trực tiếp vào, về lý thuyết đều có thể bị nhắm tới bằng thủ đoạn tương tự.Đây cũng là lý do vì sao các công ty kiểm toán những năm gần đây đặc biệt chú ý đến kiểu tấn công "trục lợi trọn gói trong một block" này.
Sự việc Summer.fi mất 6 triệu USD thực tế đã diễn ra như thế nào? Phân tích toàn bộ quy trình tấn công flash loan
Sau khi hiểu rõ nguyên lý, cuộc tấn công lần này vào Summer.fi thực tế đã diễn ra từng bước như thế nào? Nhìn lại toàn bộ quy trình, bạn sẽ thấy mỗi bước đều khớp chính xác với lỗ hổng đã nói ở trên — đây là một kế hoạch hoàn chỉnh đã tính toán kỹ lợi nhuận từng bước, từ vay tiền, thổi phồng đến chốt lời, rồi rửa tiền, gần như liền mạch không hề có cảm giác ứng biến tại chỗ.Phân tích ba bước này, bạn sẽ hiểu rõ hơn vì sao kiểu tấn công này khó mà phòng tránh được.
Bước 1: Vay 65,4 triệu USD flash loan để gom share Silo trước
Bước đầu tiên, kẻ tấn công vay 65,4 triệu USD qua flash loan. Số tiền này không được dùng trực tiếp để tấn công Vault, mà trước tiên đem mua một loại tài sản tên là Silo: Varlamore USDC Growth, tích lũy thành một lượng share nhất định.Bước này nhìn qua chỉ giống một thao tác thị trường bình thường, không sử dụng bất kỳ lỗ hổng nào, cũng không kích hoạt cảnh báo, vì bản thân giao thức hoàn toàn cho phép người dùng mua loại tài sản này.Nhìn vào dữ liệu on-chain, bước này hoàn toàn hợp lệ, chỉ khi phân tích lại quy trình tấn công sau đó người ta mới ghép được mối liên hệ với các thao túng tiếp theo.
Bước này là để dọn đường cho thao túng phía sau — trước tiên nắm giữ đủ số share trong tay, thì mới có vốn liếng để hưởng lợi tối đa từ những share này sau khi giá trị tài sản bị thổi phồng. Nếu không có bước gom share trước này, thì dù có thổi phồng thành công totalAssets(), kẻ tấn công cũng chẳng thu được bao nhiêu lợi ích, toàn bộ kế hoạch sẽ không thành lập được.
Bước 2: Tặng tài sản vào Ark để thổi phồng totalAssets() của FleetCommander
Sau khi có được share, kẻ tấn công tiếp theo đem tài sản đã gom được tặng trực tiếp cho hợp đồng Ark, bỏ qua quy trình gửi tiền bình thường. Như đã nói ở trên, cách tính totalAssets() của FleetCommander không phân biệt "gửi tiền chính thống" với "tặng trực tiếp", nên khoản tài sản được tặng vào này lập tức bị cộng vào tổng tài sản của Vault.
Tổng tài sản của Vault ngay lập tức bị đẩy lên, nhưng số lượng share đang lưu hành lại không tăng theo, kết quả là giá trị tài sản mà mỗi share có thể đổi được bị đẩy lên một cách nhân tạo.Đây là hành động thao túng then chốt nhất trong toàn bộ sự việc, việc gom share trước đó chỉ là bước chuẩn bị, còn đây mới là cốt lõi của việc can thiệp vào con số hạch toán.Số lượng người gửi tiền, tình hình thị trường — tất cả đều không liên quan đến quá trình thổi phồng này, toàn bộ quá trình cũng không hề dùng bất kỳ quyền cửa hậu nào, đơn thuần là lỗ hổng trong logic tính toán bị phát hiện và khai thác triệt để.
Bước 3: Rút 70,9 triệu USD để chốt lời, tiền qua Curve đổi thành DAI rồi chảy vào Tornado Cash
Sau khi totalAssets() bị thổi phồng, số share trong tay kẻ tấn công lập tức trở nên có giá trị hơn, hắn đem số share đã gom trước đó đi rút (redeem), đổi lấy 70,9 triệu USD tài sản.Trừ đi khoản gốc và phí của flash loan 65,4 triệu USD đã vay, cộng thêm chi phí thao tác 64,8 triệu USD đã bỏ ra trước đó, lãi ròng thu được là 6 triệu USD, số tiền này được bỏ túi ngay lập tức, và tất cả diễn ra trong cùng một block, cùng một giao dịch.
Sau khi trục lợi xong, kẻ tấn công không để tiền nằm yên trên chain ban đầu, mà lập tức thông qua Curve đổi tài sản sang DAI — một loại stablecoin — để giảm rủi ro bị truy vết hoặc bị sàn giao dịch đóng băng, sau đó gửi DAI vào các công cụ trộn coin như Tornado Cash để cắt đứt dòng tiền. Tính đến hiện tại, tung tích của khoản tiền 6 triệu USD này vẫn chưa có tiến độ thu hồi nào được công bố.
Cùng lúc đó BONK DAO cũng gặp sự cố, các giao thức dạng Vault/ngân khố có đặc biệt nguy hiểm không?
Cùng thời điểm sự việc Summer.fi bùng nổ, ngân khố của BONK DAO cũng bị đồn là bị rút cạn khoảng 20 triệu USD, hai sự việc này có phải đồng nghĩa với việc các giao thức dạng Vault, ngân khố đặc biệt dễ gặp sự cố?Câu trả lời không đơn giản như vậy: thủ đoạn tấn công của hai sự việc hoàn toàn khác nhau, một bên là lỗ hổng hạch toán, một bên là cơ chế quản trị bị khai thác lỗ hổng.Hiểu rõ sự khác biệt này, bạn mới biết cần nhìn vào đâu để đánh giá rủi ro của một giao thức.
Tấn công quản trị của BONK DAO khác gì với thủ đoạn tấn công của Summer.fi
Vấn đề của Summer.fi nằm ở cách smart contract tính toán tài sản, còn vấn đề của BONK DAO hoàn toàn không nằm ở lỗ hổng code, mà nằm ở chính cơ chế biểu quyết quản trị.Kẻ tấn công chỉ bỏ ra khoảng 4 triệu USD để mua vào token BONK, tích lũy đủ trọng số biểu quyết, dùng nó để ủng hộ một đề xuất độc hại, chuyển số token BONK trị giá khoảng 20 triệu USD trong ngân khố — quy đổi ra lên tới 4,426 nghìn tỷ token — sang ví do chính hắn kiểm soát.
Toàn bộ quá trình hoàn toàn tuân theo quy tắc của giao thức để đi hết quy trình biểu quyết, không hề hack vào bất kỳ hệ thống nào, cũng không dùng bất kỳ private key nào, vấn đề nằm ở chỗ bản thân đề xuất đó không bị chặn lại. Điều này tương tự với mô hình "thao tác hợp pháp, thổi phồng con số" của Summer.fi, đều là lợi dụng kẽ hở trong chính quy tắc, chỉ khác là Summer.fi khai thác logic hạch toán, còn BONK DAO khai thác ngưỡng biểu quyết.
Tấn công quản trị và lỗ hổng smart contract, cái nào khó phòng hơn
Xét về độ khó phòng thủ, lỗ hổng smart contract ít nhất còn có thể bắt được nhờ kiểm toán (audit), mô phỏng trên testnet, rà soát code — lỗ hổng đã được viết cứng trong code, chỉ cần có người chịu bỏ thời gian kiểm tra thì về lý thuyết đều có thể phát hiện.Cái phiền phức của tấn công quản trị là ở chỗ, bản thân cơ chế biểu quyết không sai, cái sai là không thiết kế time lock (khóa thời gian), ngưỡng quorum (số lượng biểu quyết tối thiểu), và cơ chế đa chữ ký (multisig) xác nhận lại — những "phanh an toàn" kiểu này.
Lần này BONK DAO chính là không có time lock, đề xuất được thông qua là thực thi ngay lập tức, không cho ai bất kỳ khoảng thời gian phản ứng nào; cũng không có ngưỡng quorum tối thiểu, khiến một người chỉ bỏ ra 4 triệu USD cũng có thể chi phối quyết định của ngân khố trị giá 20 triệu USD. So với đó, tấn công quản trị khó giải quyết bằng bản vá sau sự việc hơn nhiều, vì vấn đề nằm ở chính tư duy thiết kế của toàn bộ cơ chế ra quyết định, không phải cứ sửa vài dòng code là xong.
Làm sao đánh giá thiết kế Vault/ngân khố của một giao thức có vùng đệm rủi ro hay không
Khi gặp một giao thức dạng Vault hoặc ngân khố, bạn có thể xem trước ba điều: thứ nhất, logic tính tài sản có bị ảnh hưởng bởi việc bên ngoài tặng tiền trực tiếp vào hay không; thứ hai, các thao tác quan trọng có time lock hay không, để cộng đồng có thời gian phản ứng; thứ ba, đề xuất quản trị có ngưỡng quorum tối thiểu và cơ chế đa chữ ký xác nhận lại hay không, để tránh việc một nhóm nhỏ người có thể chi phối dòng tiền khổng lồ.
Nếu cả ba điều này đều không có, nghĩa là giao thức đặt "hiệu quả" lên trước "phanh an toàn", một khi có người tìm ra sơ hở, sẽ không có bất kỳ vùng đệm nào để tranh thủ thời gian.Bạn không cần hiểu chi tiết code, nhưng mình khuyên bạn nên tập thói quen, trước khi gửi tiền hãy tra cứu tài liệu quản trị và mô tả thiết kế hợp đồng của giao thức xem có nhắc đến các cơ chế này không — đây là cách trực tiếp nhất, cũng đỡ tốn công sức nhất để đánh giá thể chất của một giao thức tốt hay xấu.
Sau khi sự việc xảy ra, tình trạng tiền của người dùng bị ảnh hưởng và quá trình xử lý đã đi đến đâu?
Sau khi tiền bị đánh cắp, giao thức thường sẽ ra thông báo ngay lập tức nói rằng đã xử lý, đang điều tra, nhưng những từ ngữ này cụ thể đại diện cho tiến độ gì?Phần này tổng hợp xem Summer.fi và BONK DAO mỗi bên đã đi đến bước nào, để bạn biết những hành động như "tạm dừng", "đóng băng", "báo cáo" thực tế có đổi lại được tiền cho bạn hay không.
Tiến độ xử lý hiện tại của Summer.fi (tạm dừng Vault và truy vết dòng tiền)
Guardian của giao thức Summer.fi, ngay sau khi sự việc xảy ra, đã lập tức tạm dừng toàn bộ các Vault thuộc Lazy Summer Protocol, nhằm ngăn lỗ hổng bị khai thác lặp lại và mở rộng thiệt hại. Các nhà nghiên cứu độc lập lần lượt công bố phân tích, xác nhận cuộc tấn công lần này hoàn toàn dựa vào các hàm hợp pháp như gửi tiền, rút tiền, rút vốn từ Ark bình thường, không liên quan đến việc lộ private key hay quyền quản trị viên.
Tính đến hiện tại, phía Summer.fi vẫn chưa đưa ra tuyên bố chính thức nào về sự việc này, việc truy vết dòng tiền chủ yếu đến từ sự theo dõi liên tục của cộng đồng phân tích on-chain, xác nhận rằng 6 triệu USD bị đánh cắp đã qua Curve đổi thành DAI, cuối cùng chảy vào Tornado Cash.Việc tạm dừng Vault giải quyết được vấn đề "không tiếp tục mất máu", không đồng nghĩa với việc đã thu hồi được bất kỳ khoản tài sản nào.
Diễn biến tiếp theo của BONK DAO (sàn giao dịch đóng băng nạp/rút, báo cáo cơ quan thực thi pháp luật)
Động thái của BONK DAO tương đối tích cực, đội ngũ công khai cho biết đang phối hợp với Solana Foundation cùng nhiều sàn giao dịch để truy vết và đóng băng số tiền phi pháp chảy vào sàn, đồng thời bắt đầu báo cáo vụ tấn công quản trị này lên cơ quan thực thi pháp luật. Một phần token BONK bị đánh cắp đã được quan sát thấy bắt đầu di chuyển đến địa chỉ sàn giao dịch, cho thấy kẻ tấn công có thể đang chuẩn bị rút tiền mặt.
Sàn giao dịch đóng băng nạp/rút, cơ quan thực thi pháp luật can thiệp điều tra — những hành động này có thể làm chậm tốc độ rút tiền mặt của kẻ tấn công, cũng nâng cao cơ hội thu hồi một phần tiền về sau, nhưng không có nghĩa nào đảm bảo rằng "tiền đã lấy lại được".BONK vì sự việc này mà giảm khoảng 8% đến 10%, đối với những người nắm giữ token hoặc từng đưa tiền vào quản trị ngân khố, đây là thiệt hại thực sự, không tự nhiên biến mất chỉ vì phía chính thức ra tuyên bố.
Vì sao tiền bị đóng băng/gắn cờ không đồng nghĩa với việc chắc chắn lấy lại được
Sàn giao dịch đóng băng tài khoản, nhà phân tích on-chain gắn cờ địa chỉ — những hành động này nghe có vẻ có tiến triển, nhưng việc có thu hồi được tiền hay không phụ thuộc vào nhiều điều kiện: kẻ tấn công có chuyển tài sản đến sàn giao dịch sẵn sàng hợp tác điều tra hay không, có đi qua công cụ trộn coin để cắt đứt truy vết trước đó hay không, cơ quan thực thi pháp luật tại địa phương có năng lực và thiện chí hợp tác xuyên biên giới hay không.
6 triệu USD của Summer.fi đã chảy vào Tornado Cash — mục đích tồn tại của loại công cụ này chính là làm cho việc truy vết dòng tiền mất hiệu lực, khiến độ khó thu hồi sau này tăng lên đáng kể. Ngược lại, vì một phần tiền của BONK DAO vẫn chưa hoàn toàn thoát khỏi tay kẻ tấn công, nên cơ hội bị sàn giao dịch chặn lại quả thực cao hơn.Cùng là những từ ngữ "đang đóng băng", "đang điều tra", nhưng xác suất thu hồi phía sau có thể khác nhau một trời một vực, người mới không nên vơ đũa cả nắm.
Trước khi gửi tiền vào Vault DeFi, 3 sai lầm phán đoán mà người mới thường mắc phải nhất
Đọc xong hai sự việc này, có thể bạn sẽ nghĩ, hay là tốt nhất đừng đụng vào các sản phẩm dạng Vault cho an toàn? Thực ra vấn đề không nằm ở việc có nên đụng vào hay không, mà nằm ở việc trước khi gửi tiền bạn có phán đoán đúng hay không.Nhiều người thất bại không phải vì tiền không đủ cẩn trọng, mà vì cách đánh giá giao thức ngay từ đầu đã dùng sai chỉ số.Phần này tổng hợp ba sai lầm phán đoán phổ biến nhất, giúp bạn điều chỉnh lại tâm thế.
Sai lầm 1: Chỉ nhìn APY mà không xem danh mục tài sản nền và thiết kế đòn bẩy của Vault
Con số APY đẹp mắt là căn cứ đầu tiên, thậm chí là căn cứ duy nhất mà nhiều người dùng để quyết định có gửi tiền hay không.Nhưng APY chỉ cho bạn biết "dự kiến kiếm được bao nhiêu" — hoàn toàn không cho bạn biết khoản lợi nhuận này đến từ đâu, là dựa vào chênh lệch lãi suất cho vay nền tảng, thao tác đòn bẩy, hay dựa vào một cơ chế nào đó cần liên tục có tiền mới đổ vào mới trụ được.Nguồn gốc lợi nhuận khác nhau thì rủi ro phải gánh cũng khác nhau một trời một vực.
Bản thân Vault của Summer.fi là phân bổ tiền vào nhiều module chiến lược Ark để kiếm lợi nhuận, module chiến lược càng nhiều, giao thức cho vay được kết nối càng phức tạp, thì bề mặt tấn công của hệ thống càng lớn — điều này hoàn toàn không liên quan gì đến việc APY cao hay thấp. Bỏ ra mười phút trước khi gửi tiền để tra cứu mô tả phân bổ tài sản của Vault sẽ giúp bạn đánh giá rủi ro tốt hơn nhiều so với việc chăm chăm nhìn con số APY nhảy múa.
Sai lầm 2: Tưởng rằng có giao thức nổi tiếng bảo chứng = smart contract không rủi ro
Summer.fi không phải một giao thức nhỏ vô danh, đằng sau nó có mức độ nổi tiếng và quy mô vốn nhất định, đây cũng là lý do không ít người dùng ban đầu sẵn sàng gửi tiền vào.Nhưng sự việc lần này chứng minh rằng, giao thức độ nổi tiếng và uy tín của đội ngũ không đồng nghĩa với code không có lỗ hổng, ngay cả đội ngũ dày dạn kinh nghiệm nhất cũng có thể để lại sơ hở chưa bị phát hiện trong logic tính toán tài sản.Quy mô lớn, người dùng nhiều, ngược lại càng dễ khiến người ta lơ là cảnh giác, quên làm những bài tập an toàn cơ bản nhất.
Coi "ai cũng đang dùng", "đã hoạt động lâu rồi" là bảo chứng an toàn duy nhất là cái bẫy tâm lý dễ mắc phải nhất. Cách làm thực tế hơn là xem giao thức có kiểm toán định kỳ hay không, mức độ công khai minh bạch của báo cáo kiểm toán ra sao, trước đây có từng có bug bounty (chương trình treo thưởng lỗi) hay không — bản thân mình khi đánh giá một giao thức mới, chắc chắn sẽ tìm báo cáo kiểm toán trước, không tìm thấy thì bỏ qua luôn.
Sai lầm 3: Bỏ qua việc bản thân công tắc tạm dừng khẩn cấp đã là lời thừa nhận rủi ro của giao thức
Hầu như tất cả các giao thức DeFi chính thống đều có cơ chế tạm dừng khẩn cấp, để guardian có thể lập tức dừng lại khi phát hiện bất thường, ngăn thiệt hại lan rộng. Thiết kế này thực ra đang nói với bạn một điều: chính đội ngũ giao thức cũng cho rằng hệ thống có khả năng xảy ra sai sót, nên mới cần dự phòng cái phanh này. Nhìn theo góc khác, nếu một hệ thống hoàn toàn không thể sai sót, thì căn bản không cần thiết kế loại công tắc khẩn cấp này.
Nhiều người thấy "có cơ chế tạm dừng" lại thấy yên tâm, hiểu nhầm rằng điều đó có nghĩa là luôn có người theo dõi, tiền tuyệt đối an toàn, nhưng lại bỏ qua tiền đề của việc cơ chế tạm dừng tồn tại chính là vì rủi ro vốn đã tồn tại từ trước.Trước khi gửi tiền, bạn thử nhìn theo góc khác xem: nếu ngay cả bản thân giao thức cũng đã dự phòng phanh khẩn cấp, thì bạn đã tự chuẩn bị một cái phanh cho tiền của mình chưa, ví dụ như phân bổ đa dạng vào các giao thức khác nhau, hoặc thiết lập cảnh báo giám sát cho tài sản?
Checklist tự bảo vệ mà người dùng thông thường có thể áp dụng, giảm rủi ro xuống mức thấp nhất
Nói nhiều hiểu lầm và lỗ hổng như vậy rồi, quay lại vấn đề thực tế nhất: bạn có thể làm gì để đưa rủi ro về mức bạn có thể chấp nhận được?Phần này tổng hợp những việc cần làm ở ba giai đoạn: trước khi gửi tiền, trong khi gửi tiền, và ngay khi sự việc xảy ra, giúp bạn biến nhận thức rủi ro trừu tượng thành những hành động cụ thể có thể làm theo, tiếp theo chúng ta sẽ tổng hợp từng bước theo trình tự thời gian.
Trước khi gửi tiền, làm sao để tra cứu báo cáo kiểm toán và lịch sử bug bounty của giao thức
Trước khi gửi tiền vào bất kỳ Vault nào, hãy dành thời gian tra cứu ba điều: giao thức có từng thuê công ty kiểm toán uy tín để kiểm toán hay không, báo cáo kiểm toán có được công khai để tra cứu hay không, có chương trình bug bounty vận hành lâu dài hay không. Những thông tin này thường có thể tìm thấy trên website hoặc tài liệu chính thức của giao thức, nếu một giao thức ngay cả báo cáo kiểm toán cũng không đưa ra được, hoặc chương trình treo thưởng chỉ mang tính hình thức, bạn nên nâng cao cảnh giác — số tiền thưởng có phản ánh hợp lý quy mô vốn mà giao thức đang quản lý hay không cũng đáng để bạn lưu ý.
Kiểm toán không phải thuốc tiên vạn năng, lỗ hổng của Summer.fi trước khi xảy ra sự việc cũng không phải là hoàn toàn chưa từng được rà soát, nhưng ít nhất kiểm toán và lịch sử bug bounty có thể phản ánh đội ngũ của một giao thức có sẵn lòng đầu tư nguồn lực để tìm lỗ hổng hay không.Việc kiểm chứng này không tốn quá nhiều thời gian, nhưng có thể giúp bạn loại bỏ hàng loạt giao thức thậm chí chưa làm cả bài tập cơ bản.
Trong khi gửi tiền, phân bổ đa dạng và thiết lập cảnh báo giám sát tài sản
Cho dù bạn đã sàng lọc giao thức kỹ càng, cũng không nên dồn hết vốn vào một Vault duy nhất. Phân bổ đa dạng vào các giao thức khác nhau, loại tài sản khác nhau có thể giảm hiệu quả rủi ro toàn bộ vốn của bạn về 0 chỉ vì một lỗ hổng duy nhất — logic này hoàn toàn giống với đầu tư truyền thống "đừng bỏ hết trứng vào một giỏ", chỉ khác là cái giỏ của DeFi được thay bằng smart contract.
Ngoài ra, khuyên bạn nên thiết lập cảnh báo giám sát cho tài sản của mình, ví dụ những chỉ số như totalAssets() của Vault biến động bất thường, một giao dịch có số tiền quá lớn — một khi kích hoạt sẽ thông báo cho bạn ngay lập tức.Loại công cụ giám sát này thường có thể tự thiết lập trên các nền tảng phân tích on-chain, tuy không thể ngăn tấn công xảy ra, nhưng có thể giúp bạn biết được bất thường ngay từ đầu, chứ không phải đọc tin tức sau đó mới phát hiện ra mình cũng là một trong những nạn nhân.
3 việc cần làm ngay khi sự việc xảy ra
Nếu chẳng may giao thức bạn gửi tiền thực sự gặp sự cố, hoảng loạn cũng chẳng ích gì, chỉ có xử lý theo trình tự cố định mới có thể khống chế thiệt hại ở mức thấp nhất, đồng thời giữ được bằng chứng cần thiết cho việc khiếu nại hoặc hỗ trợ điều tra sau này.Ba việc dưới đây, khuyên bạn nên làm theo thứ tự:
- Ngay lập tức xác nhận tình trạng tài sản của bản thân: xem thông báo chính thức và lịch sử ví trên block explorer, xác nhận xem tiền có thực sự bị ảnh hưởng hay không, tránh tự làm mình hoảng sợ, cũng tránh bỏ sót các vị thế bị ảnh hưởng.
- Chụp màn hình lưu lại toàn bộ lịch sử giao dịch và thông báo chính thức: bao gồm thời gian, số tiền của vụ tấn công, lịch sử gửi/rút tiền của chính bạn — những tài liệu này sau này dù là để phối hợp điều tra cùng giao thức, hay để báo án với cơ quan thực thi pháp luật, đều là bằng chứng cần thiết.
- Theo dõi kênh chính thức thay vì tin đồn cộng đồng: trong thời gian giao thức tạm dừng, rất dễ xuất hiện các trò lừa đảo lần hai như hỗ trợ giả mạo, link bồi thường giả — nhất định chỉ xác nhận tiến độ mới nhất qua các kênh đã được xác minh chính thức, không click vào bất kỳ link "hỗ trợ thu hồi tiền" nào được gửi qua tin nhắn riêng.
Sau khi làm xong ba việc này, mới đến lượt đánh giá xem có nên tiếp tục nắm giữ các vị thế khác hay không, có nên điều chỉnh phân bổ tài sản hay không.Điều tối kỵ nhất ngay khi sự việc xảy ra là "có bệnh vái tứ phương", tin bừa vào các dịch vụ "đại diện thu hồi tiền" không rõ nguồn gốc, khiến bản thân bị hại lần hai.
Kết luận
Sự việc lần này của Summer.fi, từ đầu đến cuối không hề dùng đến thủ đoạn xâm nhập thường thấy trong phim hacker, mà dựa hoàn toàn vào chức năng do chính giao thức mở ra, cộng thêm một lỗ hổng hạch toán chưa bị phát hiện. Bài học của BONK DAO cũng vậy, vấn đề không nằm ở việc code bị bẻ khóa, mà nằm ở chỗ chính quy tắc đã để lại sơ hở.Dụng ý của bài viết này không phải để bạn từ nay xa lánh hoàn toàn các Vault DeFi — mà là nhắc bạn rằng, bỏ thêm mười phút trước khi gửi tiền để tra kiểm toán, xem thiết kế quản trị, đáng giá hơn nhiều so với việc phải tìm tiền của mình trong lịch sử Tornado Cash sau khi sự việc đã xảy ra.
