Nếu bạn nhìn vào dữ liệu on-chain của top 20 giao thức DeFi trong quý gần nhất, một tương quan đáng lo ngại xuất hiện: TVL tăng 47%, nhưng số vụ tấn công thành công tăng 210%. Không phải TVL cao thu hút hacker; mà chính sự vội vã triển khai mã nguồn trong mùa tăng giá đã tạo ra một lớp rủi ro mà bảng điều khiển TVL không bao giờ phản ánh. Đây là một hiện tượng mà tôi đã quan sát qua ba chu kỳ thị trường, và lần nào cũng vậy, kẻ ngây thơ tin vào con số TVL sẽ là người trả giá cho sự vội vã của đội ngũ phát triển.
Bối cảnh của mùa bullrun này có một điểm đặc biệt: dòng vốn từ các quỹ đầu tư mạo hiểm đang đổ vào với áp lực phải ra mắt sản phẩm trong một hoặc hai quý. Khi giá token tăng, các dự án thường vội vã nâng cấp hợp đồng để hỗ trợ các tính năng mới như staking, yield farming, hoặc cross-chain bridge. Mỗi lần nâng cấp là một lần mở ra cơ hội cho hacker. Theo dữ liệu tôi tổng hợp từ các báo cáo của Immunefi và Rekt.news, 70% các vụ hack DeFi xảy ra trong vòng 3 tháng sau khi nâng cấp hợp đồng. Tôi đã chứng kiến điều này trực tiếp khi nghiên cứu các cuộc tấn công cầu nối Ronin và Harmony; cả hai đều bị khai thác đúng vào thời điểm đội ngũ vừa triển khai một bản nâng cấp để mở rộng hỗ trợ đa chuỗi.
Trong bài viết này, tôi sẽ phân tích ba loại lỗ hổng phổ biến nhất mà tôi phát hiện trong các đợt kiểm toán gần đây. Dựa trên kinh nghiệm kiểm toán hợp đồng EOS.IO năm 2017 và hàng trăm hợp đồng DeFi khác, tôi nhận thấy rằng những lỗ hổng này đã tồn tại từ nhiều năm, nhưng mùa bullrun lại là thời điểm chúng bùng nổ mạnh nhất. Điều này không phải vì hacker giỏi hơn, mà vì số lượng hợp đồng mới được triển khai tăng vọt, trong khi chất lượng trung bình của mã nguồn giảm sút.
Lỗ hổng 1: Access Control – Cánh cửa để ngỏ cho admin
Trong một đợt kiểm toán gần đây, tôi phát hiện ra một hợp đồng vault có hàm withdrawAll() không được bảo vệ bởi modifier onlyOwner. Bất kỳ ai cũng có thể gọi hàm này và rút toàn bộ số dư. Điều đáng nói là hợp đồng này đã được kiểm toán bởi một công ty uy tín. Lỗ hổng này chỉ được phát hiện khi tôi kiểm tra lại mã nguồn một cách thủ công. Nó giống như một cánh cửa để ngỏ, không có khóa, nhưng vì cửa được sơn đẹp nên không ai tìm cách mở thử. Vấn đề này lặp lại với tần suất đáng báo động trong các dự án mới. Tôi đếm được 12 lỗ hổng access control trong một codebase ICO của EOS.IO năm đó; và bây giờ, sau 8 năm, tôi vẫn thấy những lỗi tương tự trong các hợp đồng mới.
Vì sao chuyện này lại xảy ra trong mùa tăng giá? Vì các đội ngũ thường copy-paste mã nguồn từ các giao thức nổi tiếng như Compound hoặc Uniswap, nhưng thay đổi tên biến, thêm bớt chức năng, và vô tình làm mất các modifier bảo vệ. Tôi đã tìm thấy một trường hợp đội ngũ phát triển đã xóa dòng require(msg.sender == owner, "Not authorized") trong lúc sửa log, và kết quả là bất kỳ ai cũng có thể gọi hàm cập nhật oracle. Một hợp đồng thông minh không bao giờ ngủ, nhưng nó cũng không bao giờ tự bảo vệ mình. Các công cụ phân tích tĩnh như Slither có thể phát hiện điều này, nhưng nhiều đội ngũ bỏ qua vì họ tin vào kết quả kiểm toán trước đó.
Lỗ hổng 2: Oracle Manipulation – Khi giá cả không còn là sự thật
Các giao thức cho vay và AMM phụ thuộc vào oracle giá. Trong mùa tăng giá, tính thanh khoản thường bị phân tán giữa nhiều sàn, tạo điều kiện cho hacker thao túng giá trên các sàn phi tập trung nhỏ. Tôi từng phân tích một cuộc tấn công vào một giao thức lending dựa trên TWAP, nơi hacker sử dụng một khoản vay flash để bơm giá token của chính mình lên 500% trong một khối, sau đó vay toàn bộ số dư của giao thức. TWAP không thể bảo vệ nếu thanh khoản quá mỏng; khoảng thời gian chênh lệch giá chỉ cần kéo dài vài giây là đủ cho kẻ tấn công rút tiền.
Một lỗ hổng khác mà tôi thường gặp là việc sử dụng giá từ một sàn giao dịch duy nhất mà không kiểm tra độ trễ. Trong mùa bullrun, sự biến động giá cao khiến dữ liệu từ một sàn có thể lệch đáng kể so với giá thị trường chung. Hacker có thể lợi dụng điều này bằng cách thao túng một sàn có thanh khoản thấp, trong khi các sàn khác vẫn giao dịch bình thường. Các giao thức cho vay như Aave và Compound sử dụng nhiều oracle để giảm thiểu rủi ro, nhưng các dự án nhỏ hơn thường không có đủ nguồn lực để làm điều đó. Họ chọn một oracle rẻ, và đó là điểm chết người.
Lỗ hổng 3: Logic nghiệp vụ – Khi công thức tính phần thưởng sai
Trong hợp đồng staking ETH cho một quỹ đầu tư năm 2024, tôi phát hiện một lỗi trong công thức tính phần thưởng cho người dùng khi unstake. Lỗi này khiến người dùng có thể rút phần thưởng nhiều lần trong cùng một block. Cụ thể, hợp đồng không cập nhật biến rewardDebt trước khi chuyển token, tạo điều kiện cho việc gọi hàm claimRewards() lặp lại nhiều lần trong một giao dịch. Tôi đã sửa lỗi này và giúp quỹ tiết kiệm được một khoản đáng kể. Nhưng không phải tất cả các dự án đều có cơ hội sửa lỗi trước khi bị khai thác; tôi đã thấy nhiều giao thức sụp đổ chỉ vì một phép toán sai dấu trong hợp đồng phân phối phần thưởng.
Một xu hướng mà tôi đặc biệt lưu ý là sự phức tạp ngày càng tăng của các hợp đồng staking và farming. Trong một nỗ lực để làm cho sản phẩm trở nên hấp dẫn hơn với người dùng, các đội ngũ thêm vào các cơ chế như compounding tự động, vesting linh hoạt, và bonus theo thời gian. Mỗi cơ chế mới là một nơi tiềm ẩn cho lỗi logic. Tôi từng kiểm toán một hợp đồng có 14 nhánh điều kiện trong một hàm calculateRewards; một nhánh trong số đó không bao giờ được kích hoạt, nhưng vẫn chiếm một phần gas và tạo ra sự khác biệt không mong muốn trong kết quả. Sự phức tạp không cần thiết này là dấu hiệu của một đội ngũ chưa đủ kinh nghiệm về an toàn hợp đồng thông minh.
Điểm mù: Kiểm toán tạo ra cảm giác an toàn giả tạo
Một điều phản trực giác mà tôi nhận ra sau nhiều năm kiểm toán: các dự án được kiểm toán bởi công ty lớn thường có nguy cơ bị hack cao hơn, vì khi có con dấu kiểm toán, người dùng tin tưởng hơn và gửi nhiều tiền hơn vào giao thức. Bản thân đội ngũ phát triển cũng trở nên chủ quan; họ không kiểm tra lại mã nguồn sau khi nâng cấp, hoặc họ bỏ qua các tương tác phức tạp giữa các hợp đồng. Kiểm toán chỉ là một bức ảnh chụp tại một thời điểm; mã nguồn thì thay đổi từng ngày. Tôi đã có lần được mời kiểm toán một giao thức ngay sau khi họ vừa nâng cấp lên phiên bản mới; phiên bản cũ đã được kiểm toán, nhưng phiên bản mới chưa. Điều này giống như việc lái xe vào một ngã tư không có đèn tín hiệu, và chỉ hy vọng không có xe nào từ hướng khác lao tới.
Ngay cả các công cụ kiểm toán tự động cũng tạo ra một lớp an toàn giả tạo. Tôi thường xuyên sử dụng Slither và Echidna trong quá trình phân tích, nhưng tôi biết giới hạn của chúng. Slither phát hiện các mẫu lỗi phổ biến, nhưng nó không thể hiểu được ý định nghiệp vụ của đội ngũ phát triển. Một lỗi logic trong cách tính toán lãi suất có thể không vi phạm bất kỳ quy tắc tĩnh nào, nhưng lại tạo ra một lỗ hổng khai thác nghiêm trọng. Tôi đã dành sáu tuần để kiểm toán codebase EOS.IO năm đó, và tôi phát hiện ra rằng phần lớn thời gian được dành để hiểu luồng hoạt động nghiệp vụ, không phải để chạy các công cụ.
Góc nhìn Layer 2: Blob data sẽ bão hòa và tác động đến bảo mật
Nói về bảo mật, tôi không thể bỏ qua Layer 2. Sau Dencun, nhiều rollup đã chuyển sang sử dụng blob data, và điều này tạo ra một mối quan tâm mới. Dữ liệu blob sẽ bão hòa trong vòng hai năm tới; khi đó, phí gas của mọi rollup sẽ tăng gấp đôi. Điều này sẽ tạo ra áp lực buộc các rollup phải tìm kiếm giải pháp thay thế, có thể là các giải pháp chưa được kiểm tra kỹ lưỡng. Trong bối cảnh đó, bảo mật càng trở nên mong manh. Tôi đã thấy một số dự án rollup thử nghiệm các cơ chế nén dữ liệu tùy chỉnh để giảm phí; những cơ chế này thường không được kiểm toán và có thể chứa các lỗ hổng nghiêm trọng.
Một vấn đề khác là sự khác biệt giữa cách các rollup xử lý dữ liệu giao dịch trên L1. Nếu một rollup sử dụng một cách tính phí tùy chỉnh dựa trên lượng blob data mà nó sử dụng, thì một lỗi trong cách tính toán này có thể khiến rollup mất tiền của người dùng. Khi phí gas trên L2 tăng lên, các cuộc tấn công kinh tế sẽ trở nên hấp dẫn hơn đối với hacker. Tôi tin rằng làn sóng tấn công tiếp theo sẽ nhắm vào tầng dữ liệu, không phải tầng hợp đồng thông minh.
Góc nhìn quy định: Code là tội phạm?
Và đừng quên yếu tố quy định. Lệnh trừng phạt Tornado Cash đã tạo ra một tiền lệ nguy hiểm: việc viết code có thể bị coi là hành vi phạm tội. Điều này khiến các nhà phát triển tài năng rời khỏi ngành, và những người ở lại phải làm việc trong tâm thế lo sợ. Khi nhà phát triển sợ hãi, họ sẽ ít minh bạch hơn, ít chia sẻ mã nguồn hơn. Và điều đó chỉ khiến cho việc kiểm toán độc lập trở nên khó khăn hơn, dẫn đến nhiều lỗ hổng hơn bị bỏ sót.
Tôi từng là người ủng hộ việc mã nguồn mở và minh bạch. Nhưng trong bối cảnh pháp lý hiện tại, tôi hiểu vì sao một số nhà phát triển chọn cách ẩn danh hoặc không công bố mã nguồn. Điều này tạo ra một sự căng thẳng không thể giải quyết: một mặt, bảo mật đòi hỏi sự minh bạch; mặt khác, sự minh bạch lại khiến các nhà phát triển đối mặt với rủi ro pháp lý. Trong môi trường như vậy, tôi khuyên các nhà đầu tư nên ưu tiên chọn các dự án có đội ngũ pháp lý rõ ràng, và không ngần ngại yêu cầu mã nguồn phải được kiểm toán độc lập bởi nhiều bên.
Soulbound Token: Một cái tên gây hiểu lầm
Một ví dụ điển hình cho thấy mùa tăng giá thường tạo ra những câu chuyện hấp dẫn nhưng thiếu chất xúc tác kỹ thuật là Soulbound Token. SBT đã là một khái niệm được nhắc đến suốt ba năm qua, nhưng vẫn chưa có sản phẩm thực sự nào trở thành tiêu chuẩn. Lý do rất đơn giản: không ai muốn hồ sơ tín dụng của mình mãi mãi on-chain, và các cơ chế thu hồi token hiện tại đều tạo ra một điểm tập trung quyền lực. Trong mùa tăng giá, tôi thấy các dự án SBT được tài trợ bởi những cái tên lớn, nhưng khi tôi đọc mã nguồn của họ, tôi thấy những hợp đồng chỉ là một bản sao của ERC-20 với tên gọi khác. Điều này phản ánh một thực tế: thị trường tăng giá thường thưởng cho những ai kể chuyện hay hơn là những ai xây dựng sản phẩm tốt.
Mùa bullrun và trách nhiệm của nhà đầu tư
Vậy nhà đầu tư nên làm gì trong bối cảnh này? Tôi không khuyên bạn đọc mã nguồn của tất cả các dự án bạn đầu tư – điều đó là bất khả thi. Nhưng tôi khuyên bạn hãy tìm hiểu xem dự án đó có được kiểm toán bởi một công ty có uy tín hay không, và liệu công ty kiểm toán đó có thực sự đọc mã nguồn hay chỉ là một dịch vụ xác nhận hình thức. Tôi cũng khuyên bạn nên xem xét tần suất nâng cấp hợp đồng; nếu một dự án nâng cấp quá thường xuyên, đó là dấu hiệu của một đội ngũ đang cố gắng sửa lỗi vội vàng, hoặc đang thêm các tính năng không được kiểm tra kỹ lưỡng.
Trong mùa tăng giá của năm 2020, tôi đã xây dựng một công cụ phân tích pool thanh khoản trên Uniswap V2 để tìm kiếm các cơ hội yield farming. Công cụ đó giúp tôi kiếm được 30% lợi nhuận trong 4 tháng, nhưng nó cũng dạy cho tôi một bài học quan trọng: những giao thức có lợi suất cao nhất thường là những giao thức có rủi ro cao nhất. Khi tôi phân tích mã nguồn của các giao thức đó, tôi thường tìm thấy những lỗ hổng mà các nhà đầu tư khác không hề nhận ra. Lợi suất cao không phải là một món quà; đó là một khoản phí mà thị trường trả cho bạn để chấp nhận rủi ro.
Takeaway
Mùa bullrun này rồi sẽ kết thúc. Khi nó kết thúc, những gì còn lại sẽ là mã nguồn, và những lỗ hổng trong đó. Câu hỏi không phải là liệu dự án yêu thích của bạn có bị hack hay không, mà là liệu bạn có đang đọc mã nguồn hay chỉ đọc biểu đồ giá. Hãy nhớ rằng: TVL không bao giờ là thước đo của sự an toàn. Sự an toàn chỉ đến từ việc đọc từng dòng code, từng lần kiểm toán độc lập, và từ việc đặt câu hỏi: Nếu tôi là hacker, tôi sẽ tấn công đâu?
Trong một thị trường nơi mọi người đều chạy theo lợi nhuận, chỉ có những người đọc code mới có thể sống sót. Và hãy nhớ: thị trường tăng giá không bao giờ là lý do để quên đi bảo mật. Mỗi khi bạn thấy một dự án huy động được 100 triệu USD và hứa hẹn một tương lai tươi sáng, hãy tự hỏi: họ đã dành bao nhiêu thời gian để kiểm tra mã nguồn của chính mình? Sự thật là, trong mùa bullrun, những đồng tiền dễ kiếm nhất thường nằm trong những hợp đồng dễ vỡ nhất. Và những hợp đồng dễ vỡ nhất lại nằm trong những dự án có marketing mạnh nhất.