Dự án vừa huy động 120 triệu USD trong vòng Series A — với một hàm settle() được viết sai thứ tự cập nhật state. Trên Etherscan, hợp đồng ấy đang giữ hơn 40.000 ETH từ người dùng bơm thanh khoản trong vòng 72 giờ qua. Tôi không nói về một altcoin lạ; tôi nói về một giao thức lending đang được xếp hạng “Audited by 3 firms” trên trang chủ của họ.
Khi thị trường tăng, sự chú ý tập trung vào TVL, vào đồ thị giá, vào những câu chuyện tokenomics. Nhưng những gì tôi nhìn thấy — với tư cách một người đã dành 23 năm quan sát ngành và kiểm toán từ 0x Protocol v2 cho đến các ZK-Rollup mới — là một lớp bụi kỹ thuật phủ dày bên dưới lớp sơn marketing. Và lớp bụi đó, đến một thời điểm, sẽ bùng cháy.
Sự kiện khiến tôi viết bài này đến từ một báo cáo audit nội bộ mà tôi vừa hoàn thành cho một giao thức farm — tên tôi không thể tiết lộ theo NDA — nhưng cấu trúc lỗi thì tôi có thể nói: họ đã tối ưu gas bằng cách gộp transfer() và updateReward() vào một external call duy nhất. Kết quả là toàn bộ hệ thống tính toán phần thưởng bị lệch pha khi có hai giao dịch chạy trong cùng một block. Với giá token tăng 400% trong một tháng, người dùng không quan tâm. Nhưng khi giá điều chỉnh 30%, những người rút tiền trước sẽ hút sạch quỹ phần thưởng của những người đến sau.
Tôi gọi đây là “khoảng lặng của sự chấp nhận”: trong chu kỳ tăng trưởng, con người có xu hướng gán chất lượng cho thành công. Một giao thức giữ được TVL tăng nghĩa là nó “đang hoạt động tốt”. Nhưng từ góc độ kỹ thuật, TVL tăng không chứng minh được tính đúng đắn của logic; nó chỉ chứng minh rằng chưa ai đủ động cơ để khai thác lỗ hổng. Và đây là điểm cốt lõi mà tôi muốn phân tích sâu trong bài này: sự khác biệt giữa “bảo mật được chứng minh” và “bảo mật chưa bị phá vỡ” — một sự khác biệt mà thị trường bull run tàn nhẫn nhất lại bỏ qua hoàn toàn.
Để hiểu tại sao tôi lên tiếng lúc này, chúng ta cần nhìn lại bức tranh giao thức trong năm 2025-2026. Sau Dencun, chi phí calldata giảm mạnh, và làn sóng rollup mọc lên như nấm. Các team launch sản phẩm trong 6 tuần thay vì 6 tháng. Họ dùng các framework có sẵn, clone codebase từ các giao thức thành công, rồi thêm vào một lớp incentive phức tạp để thu hút thanh khoản. Về mặt kỹ thuật, đây là một quá trình reverse-engineering vội vã: họ biết cách lắp ráp các khối, nhưng họ không xây dựng được sự hiểu biết sâu về từng khối đó hoạt động trong điều kiện biên.
Một trong những vấn đề nghiêm trọng nhất tôi gặp trong các đợt audit gần đây không nằm ở phần code thông minh. Nó nằm ở phần oracle. Các team mới — đặc biệt là những team từ nền tảng tài chính truyền thống chuyển sang — có xu hướng coi oracle như một API bình thường. Họ gọi getPrice() và tin rằng con số trả về là sự thật. Nhưng trong DeFi, giá không phải là sự thật; giá là một hàm số của trạng thái thanh khoản tại một thời điểm cụ thể. Nếu bạn dùng một DEX pool nông làm oracle cho một giao thức lending, bạn đã vô tình tạo ra một cánh cửa cho phép kẻ tấn công thao túng giá bằng một giao dịch lớn — không cần phải chạy bot phức tạp, chỉ cần một khoản vay flash.
Trong quá trình kiểm toán 0x Protocol v2 năm 2018, tôi đã học được một bài học mà tôi áp dụng cho đến ngày nay: lỗ hổng nghiêm trọng nhất không nằm ở phần code được viết cẩn thận nhất, mà nằm ở giả định về hành vi của các thành phần bên ngoài. 0x dựa vào off-chain relayers để khớp lệnh; giả định của họ là các relayers sẽ hoạt động trung thực vì họ được khuyến khích bằng phí. Nhưng tôi đã phát hiện ra rằng một relayer có thể ký một order với một price khác với price trên sàn, và nếu sàn không kiểm tra kỹ, người dùng sẽ mất tiền. Vấn đề không phải là code sai; vấn đề là model niềm tin không được kiểm chứng.
Bài học đó dẫn tôi đến một quan sát cấu trúc về chu kỳ thị trường hiện tại: bull run không tạo ra lỗ hổng, nhưng nó tạo ra sự phân tán rủi ro. Khi TVL tăng nhanh, lượng người dùng mới tham gia tăng theo cấp số nhân — và phần lớn những người dùng mới này không có kỹ năng đọc hiểu mã nguồn. Họ dựa vào một hệ thống tín nhiệm xã hội: “Dự án này được audit bởi ba công ty lớn, vậy nó an toàn.” Nhưng một bản audit không phải là một chứng nhận bảo mật vĩnh viễn. Nó là một bức ảnh chụp X-quang tại một thời điểm. Kể từ thời điểm ấy, protocol sẽ tiếp tục thay đổi, và mỗi lần thay đổi là một bề mặt tấn công mới.
Một ví dụ cụ thể: Tôi đã từng kiểm toán một early-stage lending protocol — một dự án fork từ Compound nhưng thêm vào tính năng cross-margin. Về lý thuyết, cross-margin giúp tăng hiệu quả sử dụng vốn. Nhưng về mặt triển khai, nó đòi hỏi một hệ thống theo dõi vị thế tổng hợp phức tạp. Sau hai tuần audit, tôi phát hiện ra rằng khi một user có vị thế ở hai pool khác nhau và một trong hai pool đó bị thanh lý, hệ thống sẽ tính toán lại collateral theo một công thức không bao gồm phí thanh lý. Kết quả: người thanh lý chỉ nhận được 80% số tiền họ bỏ ra trong trường hợp thanh lý đồng thời. Họ khai thác điều này thành một cơ hội kinh doanh — họ chạy bot, chờ đúng thời điểm hai pool cùng bị thanh lý, rồi thu lợi phần chênh lệch.
Đội ngũ đã sửa lỗi, nhưng câu hỏi mà tôi muốn đặt ra — và cũng là câu hỏi mà tôi tin là trọng tâm của bài viết này — là: Làm thế nào để một giao thức phân biệt được giữa "được bảo mật" và "chưa bị khai thác"? Trong một thị trường tăng, sự khác biệt này gần như không thể nhận ra từ bên ngoài. Nhưng với tư cách một auditor, tôi có một khung phân tích — một bộ 12 chỉ số đánh giá rủi ro — mà tôi sử dụng để phân loại các giao thức thành ba tầng: an toàn có điều kiện, rủi ro có kiểm soát, và nguy hiểm tiềm ẩn. Trong bài viết này, tôi sẽ chia sẻ ba trong số các chỉ số đó, những chỉ số mà tôi thấy thường bị bỏ qua nhất.
Chỉ số đầu tiên là "reentrancy surface coverage" — tôi không chỉ đếm các hàm có modifier chống reentrancy, mà tôi xem xét các điểm mà state được cập nhật trước khi gọi một external contract. Một giao thức có thể có nonReentrant trên tất cả các hàm, nhưng nếu nó gọi một external contract trước khi cập nhật state ở bất kỳ một nhánh nào — dù là nhánh error handling — thì toàn bộ hệ thống vẫn bị lộ. Trong các đợt audit của tôi, khoảng 30% các giao thức mới mắc lỗi này. Thị trường không nhìn thấy, vì không ai chạy một exploit thành công. Nhưng đến khi có một người thông minh và đủ động cơ, họ sẽ hút sạch.
Chỉ số thứ hai là "oracle dependency depth" — mức độ đa dạng của các nguồn dữ liệu giá. Một giao thức dùng Chainlink cho ETH/USD nhưng dùng một DEX pool đơn lẻ cho một token dài hạn — đó là một sự không nhất quán về bảo mật. Kẻ tấn công sẽ không bao giờ tấn công vào nơi bảo mật tốt nhất; họ sẽ tấn công vào đúng điểm yếu nhất. Trong một bull run, các token mới ra đời liên tục, và thanh khoản cho các token này thường cạn kiệt trong những giờ giá trị thấp. Nếu một giao thức cho phép vay thế chấp bằng những token này mà không có một cơ chế kiểm tra độ trượt giá (slippage check) ở tầng oracle, đó là một quả bom hẹn giờ.
Chỉ số thứ ba là "state transition redundancy" — khả năng phục hồi khi một giao dịch thất bại ở giữa quá trình thực thi. Các giao thức mới thường tối ưu hóa cho trường hợp thông thường: deposit, borrow, withdraw — tất cả diễn ra một cách trơn tru. Nhưng điều gì xảy ra khi một khoản vay bị thanh lý trong khi một phần collateral đang được dùng để farm ở một giao thức khác? Nếu không có một cơ chế dự phòng, toàn bộ hệ thống có thể rơi vào trạng thái inconsistent. Và khi hệ thống rơi vào trạng thái inconsistent trong một bull run, mọi người sẽ rút tiền — và sự rút tiền hoảng loạn ấy chính là sự kiện "black swan" của giao thức.
Tôi nhớ lại quá trình nghiên cứu Celestia năm 2022 — thị trường gấu, nhưng tôi dành 6 tháng để phân tích kiến trúc modular của họ. Vào thời điểm đó, tôi đã viết một bài phân tích dài 10.000 từ về cơ chế Data Availability Sampling, và tôi đã nhận ra một điều: các giao thức mạnh nhất không phải là những giao thức có ít lỗi nhất, mà là những giao thức có khả năng thừa nhận và xử lý lỗi một cách có hệ thống. Celestia không tuyên bố "chúng tôi an toàn vì chúng tôi có DAS"; họ tuyên bố "chúng tôi có một cơ chế để phát hiện khi dữ liệu không có sẵn". Đó là một sự khác biệt cơ bản về triết lý bảo mật — từ phòng thủ sang phát hiện.
Điều đó đưa tôi đến một góc nhìn ngược đời mà tôi muốn chia sẻ: trong một bull run, sự hoài nghi về bảo mật có thể là một chỉ báo tốt cho sức khỏe dài hạn của một giao thức. Các team chấp nhận bị chỉ trích, công khai các báo cáo audit (kể cả phần chưa được giải quyết), và thiết lập một kênh bug bounty với phần thưởng xứng đáng — những team đó đang xây dựng một nền văn hóa kỹ thuật thực sự. Ngược lại, những team chỉ tập trung vào metrics và marketing, những team né tránh các câu hỏi kỹ thuật khó, là những team mà tôi xếp vào danh sách "theo dõi đặc biệt" trong các báo cáo rủi ro của mình.
Vào năm 2024, khi SEC phê duyệt ETF Bitcoin, tôi được mời tư vấn cho các quỹ đầu tư lớn tại Seattle về rủi ro bảo mật của cơ chế lưu ký. Một trong những câu hỏi tôi thường xuyên gặp: "Nếu Bitcoin được lưu ký bởi một custodian có bảo hiểm, liệu rủi ro có được loại bỏ?" Câu trả lời của tôi là không. Bảo hiểm không loại bỏ rủi ro; nó chỉ chuyển giao rủi ro tài chính sang một bên thứ ba. Nhưng rủi ro kỹ thuật — lỗ hổng trong cơ chế multisig, lỗ hổng trong quy trình quản lý khóa, lỗ hổng trong việc xác thực giao dịch giữa các hệ thống — vẫn còn nguyên. Và trong một thị trường tăng, khi khối lượng giao dịch tăng gấp 10 lần, khả năng xảy ra lỗi trong quy trình vận hành cũng tăng theo cấp số nhân.
Tôi muốn minh họa điểm này bằng một ví dụ về một cross-chain bridge mà tôi đã phân tích gần đây. Bridge này sử dụng một mạng lưới các validator để xác nhận các giao dịch giữa hai chain. Hệ thống của họ có vẻ an toàn: multisig 7/11, mỗi validator chạy trong một môi trường TEE riêng biệt. Nhưng khi tôi nhìn vào phần code xử lý message, tôi thấy rằng họ sử dụng một cơ chế "signature aggregation" để tiết kiệm gas — nghĩa là họ chỉ cần 4 trên 11 chữ ký hợp lệ để xác nhận một message trong một số điều kiện nhất định. Điều kiện đó phụ thuộc vào một biến toàn cục có thể bị thay đổi bởi bất kỳ validator nào thông qua một proposal. Vậy là trên lý thuyết, một nhóm 4 validator có thể thông qua một proposal để giảm ngưỡng xuống còn 1, rồi ký một giao dịch rút tiền.
Khi tôi báo cáo vấn đề này cho đội ngũ, họ trả lời: "Nhưng 4 validator không thể thông qua một proposal vì proposal cũng cần chữ ký của ít nhất 7 người." Họ đã đúng về mặt logic, nhưng họ đã bỏ sót một trường hợp: khi một validator bị xâm nhập, kẻ tấn công có thể kiểm soát tất cả các khóa của validator đó. Nếu kẻ tấn công đó chiếm được 4 validator, họ có thể tạo ra một tình huống mà 4 validator khác phải bỏ phiếu theo — ví dụ, bằng cách gửi một message khẩn cấp yêu cầu thay đổi ngưỡng vì lý do "bảo trì khẩn cấp". Và nếu hệ thống không có một cơ chế kiểm tra danh tính người gửi message — không có một trường "source" trong struct — thì message khẩn cấp giả mạo đó sẽ được xử lý như một yêu cầu chính đáng.
Đây chính xác là loại lỗ hổng mà tôi gọi là "khoảng cách giữa lý thuyết và thực thi". Trên giấy tờ, cơ chế 7/11 multisig là an toàn. Trong thực tế, nó có thể bị phá vỡ bởi một chuỗi các sự kiện mà không ai dự tính đầy đủ. Và trong một bull run, những chuỗi sự kiện này càng dễ xảy ra hơn vì các team thường bị quá tải vì phải vận hành nhiều thứ cùng lúc: token listing, market making, partnership, marketing — trong khi các kỹ sư bảo mật thì ít hơn so với mức cần thiết.
Quan điểm của tôi, qua bài viết này, không phải là "DeFi không an toàn" hay "don't trust any protocol". Quan điểm của tôi là: trong một bull run, phần lớn mọi người đánh giá rủi ro dựa trên giá trị tài sản họ đang nắm giữ, chứ không phải dựa trên cấu trúc kỹ thuật của giao thức họ đang sử dụng. Một người có 10 ETH trong một lending protocol sẽ cảm thấy rằng rủi ro của họ là sự biến động của ETH. Họ không nhìn thấy rằng rủi ro thực sự là một hàm số của mã nguồn họ đang gửi tiền vào.
Và khi rủi ro đó xảy ra — khi một exploit được kích hoạt — cái giá phải trả không chỉ là số tiền bị mất. Cái giá phải trả là niềm tin. Và niềm tin, trong một thị trường tăng, là thứ duy nhất duy trì sự tăng trưởng. Nếu ba giao thức lớn bị hack trong cùng một quý, toàn bộ TVL của DeFi sẽ co lại, không phải vì người dùng không tin vào công nghệ, mà vì người dùng không tin vào khả năng quản lý rủi ro của những người xây dựng.
Vậy giải pháp là gì? Câu trả lời, đối với tôi, không nằm ở việc thêm nhiều bản audit hơn. Nó nằm ở việc xây dựng một văn hóa kỹ thuật coi trọng sự minh bạch về rủi ro: công khai các điểm chưa hoàn thiện, công khai các mô hình tấn công có thể xảy ra, và thiết lập các cơ chế phát hiện lỗi tự động (formal verification, fuzzing, invariant testing) ngay từ đầu quá trình phát triển. Một giao thức có 50 bài test invariant và 10 bài stress test sẽ an toàn hơn nhiều so với một giao thức có 3 bản audit từ các công ty nổi tiếng nhưng không có một bài kiểm tra biên nào.
Nhìn về tương lai, tôi tin rằng sự hội tụ giữa AI và Crypto sẽ tạo ra một làn sóng rủi ro mới — đặc biệt là trong lĩnh vực ZK-Proofs được sử dụng để xác thực dữ liệu huấn luyện AI trong các mô hình on-chain. Trong một nghiên cứu gần đây, tôi đã phát hiện ra một lỗ hổng trong cơ chế xác thực của một zk-Rollup mới: họ sử dụng một circuit để xác minh rằng một mô hình AI được huấn luyện đúng cách, nhưng circuit đó không kiểm tra xem dữ liệu đầu vào có bị nhiễm bẩn bởi một kẻ tấn công hay không. Nói cách khác, một kẻ tấn công có thể tạo ra một proof hợp lệ cho một mô hình đã bị huấn luyện sai. Đây là một lỗ hổng tri thức — một vấn đề mà không có công cụ bảo mật truyền thống nào có thể phát hiện.
Đối với các nhà đầu tư — dù là lớn hay nhỏ — bài học rút ra từ tất cả những phân tích này là: khi một giao thức tuyên bố "đã được kiểm toán", hãy đọc báo cáo audit. Không phải để hiểu từng dòng, mà để tìm phần "Known Issues" và phần "Disclaimer". Nếu báo cáo audit không có phần "Known Issues" — hoặc tệ hơn, không có phần "Disclaimer" — hãy cẩn thận. Một báo cáo trung thực phải thừa nhận rằng ít nhất một số vấn đề chưa thể giải quyết ngay lập tức. Và nếu mọi thứ trong báo cáo đều là "Pass" — không có một ngoại lệ nào — thì báo cáo ấy, nhiều khả năng, là một sản phẩm marketing hơn là một sản phẩm kỹ thuật.
Trong 23 năm quan sát ngành, tôi đã chứng kiến ba chu kỳ tăng trưởng lớn sụp đổ, và trong cả ba lần, nguyên nhân không đến từ công nghệ cốt lõi — nó đến từ văn hóa quản lý rủi ro yếu kém. Mỗi lần như vậy, ngành lại than khóc, rồi tự xây dựng lại với một lớp tiêu chuẩn mới. Điều khác biệt có thể xảy ra lần này — điều tôi hy vọng sẽ xảy ra — là sự chú trọng vào bảo mật sẽ trở thành một tiêu chuẩn được đánh giá, chứ không phải một huy hiệu được dán lên trang chủ. Bởi vì như tôi đã nói từ đầu: một mã nguồn sạch sẽ không phải là một tuyên bố chiến thắng; nó là một lời hứa vẫn còn để ngỏ. Và trong thị trường tăng này, lời hứa đó sẽ được kiểm chứng — dù sớm hay muộn.