Một dòng code thiếu kiểm tra totalSupply trong hợp đồng mint NFT từng khiến tôi đốt 0.1 ETH để tạo ra 50 NFT bất hợp pháp. Đó là năm 2021, tôi audit một dự án clone CryptoPunks trên BSC. Lỗi nằm ở hàm mint không kiểm tra nguồn cung tối đa, cho phép mint vô hạn. Tôi báo cáo, team vá sau 2 ngày, nhưng 200 NFT đã tồn tại trên chuỗi. Vụ việc lên Cointelegraph. Tôi kể chuyện này vì NAVI Prime, framework cho vay tùy chỉnh rủi ro mới trên Sui, cũng có thể ẩn chứa những lỗi tương tự – chỉ khác là thay vì mint NFT, nó kiểm soát hàng triệu USD thanh khoản. Câu hỏi đặt ra: khi bạn cho phép tùy chỉnh tham số rủi ro cho từng khoản vay, bạn đang mở ra cánh cửa cho khai thác hay đang xây dựng một hệ thống linh hoạt hơn?
Context: Sui và cuộc chơi cho vay tầng lớp
Navi Protocol là một trong những giao thức cho vay hàng đầu trên Sui Network. Sui, với Move language và cơ chế đồng thuận song song, đang cố gắng cạnh tranh với Ethereum bằng tốc độ và bảo mật. NAVI Prime, được công bố gần đây, là một khung cho vay phân tầng: cho phép thiết lập tham số rủi ro khác nhau cho các nhóm người vay khác nhau. Nghe có vẻ giống Aave v3 với eMode và cô lập tài sản, nhưng trên Sui. Theo phân tích từ báo cáo gốc, đây là một cải tiến dần dần, không phải đột phá. Tuy nhiên, điều làm tôi chú ý là sự thiếu minh bạch: không có thông tin kiểm toán, không có chi tiết về tham số, không có tiết lộ về đội ngũ. Đây là một lá cờ đỏ điển hình trong DeFi. Khi bạn xây dựng bot arbitrage trên Uniswap v2, bạn biết chính xác công thức AMM và phí. Ở đây, tôi không biết NAVI Prime dùng oracle nào, ngưỡng thanh lý ra sao, hay ai có quyền thay đổi tham số. Điều đó khiến tôi, với tư cách một kỹ sư từng dò mã ICO và phát hiện lỗi reentrancy, cảm thấy bất an.
Core: Phân tích kỹ thuật – Tùy chỉnh rủi ro có thực sự mới?
Hãy nhìn vào mã giả. Trong một giao thức cho vay điển hình, bạn có một hàm borrow() với tham số chung. Với NAVI Prime, bạn có thể có nhiều borrow() khác nhau cho từng loại người vay, mỗi loại có LTV riêng, lãi suất riêng, và tài sản thế chấp riêng. Điều này tương tự Aave v3, nhưng có một điểm khác biệt: Sui Move cho phép kiểm tra tài sản ở cấp độ module, giảm thiểu reentrancy. Tuy nhiên, sự phức tạp tăng lên. Dựa trên kinh nghiệm audit của tôi, mỗi tham số tùy chỉnh là một bề mặt tấn công mới. Ví dụ, nếu bạn thiết lập LTV quá cao cho một loại tài sản biến động, bạn có thể tạo ra cơ hội thanh lý không bền vững. Tôi từng thấy một giao thức trên BSC sụp đổ vì tham số thanh lý quá chặt, khiến thanh khoản bị khóa trong các cuộc đấu giá. NAVI Prime cần một cơ chế quản trị mạnh để điều chỉnh các tham số này, nhưng điều đó lại dẫn đến tập trung hóa quyền lực. Nếu 10 người nắm giữ đa số token quản trị, họ có thể thay đổi tham số để có lợi cho mình. Đây không phải lý thuyết – tôi đã thấy nó xảy ra với một dự án fork Compound. Ngoài ra, Sui vẫn còn mới. Cơ sở hạ tầng oracle của nó (có thể là Pyth hoặc Switchboard) chưa được kiểm chứng trong thị trường gấu kéo dài. Một oracle fail có thể gây ra thanh lý hàng loạt. Tôi nhớ năm 2020, khi tôi chạy bot yield farming, tôi mất 2 ETH vì slippage – một dạng lỗi oracle. Ở quy mô lớn hơn, điều này có thể phá hủy toàn bộ pool.
Một điểm khác: mô hình lãi suất hoàn toàn tùy tiện, chẳng liên quan gì đến cung-cầu thị trường thực. Tôi đã nói điều này về Aave và Compound, và NAVI cũng không ngoại lệ. Họ đặt lãi suất dựa trên công thức do đội ngũ hoặc quản trị quyết định, không phải dựa trên dữ liệu thị trường thực. Điều này tạo ra cơ hội arbitrage giữa các giao thức, nhưng cũng tạo ra rủi ro khi lãi suất không phản ánh rủi ro thực sự của tài sản. Ví dụ, nếu một stablecoin mất peg, lãi suất vay của nó có thể không tăng kịp, dẫn đến chạy đua rút tiền.
Contrarian: Điểm mù – Tùy chỉnh rủi ro có thể giết chết thanh khoản
Phần lớn phân tích cho rằng tùy chỉnh rủi ro là tốt vì nó thu hút nhiều người vay hơn. Tôi không đồng ý. Thực tế, tùy chỉnh rủi ro có thể làm giảm thanh khoản tổng thể. Khi bạn chia thị trường thành nhiều phân khúc, mỗi phân khúc có một pool thanh khoản riêng, bạn đang làm loãng thanh khoản. Điều này trái ngược với ý tưởng ban đầu của DeFi: tổng hợp thanh khoản để tạo ra hiệu quả. Hãy nhìn Uniswap v2: một pool cho mỗi cặp, thanh khoản tập trung. Với Aave v3, eMode chỉ hoạt động trong một số điều kiện nhất định. NAVI Prime có thể tạo ra hàng chục thị trường con, mỗi thị trường có thanh khoản mỏng. Nếu một thị trường con bị tấn công, toàn bộ hệ thống có thể bị ảnh hưởng do tính kết nối thông qua tài sản thế chấp. Tôi đã thấy điều này trong một dự án NFT lending: họ tạo ra các pool riêng cho từng bộ sưu tập, và khi một bộ sưu tập giảm giá, các pool khác cũng bị ảnh hưởng vì người vay dùng chung tài sản thế chấp. NAVI Prime cần một cơ chế cách ly thực sự, không chỉ là tùy chỉnh tham số. Nếu không, nó chỉ là một lớp sơn mới trên cùng một vấn đề cũ.
Một điểm mù khác: không có thông tin kiểm toán. Trong 21 năm quan sát ngành, tôi chưa bao giờ thấy một giao thức cho vay nghiêm túc nào ra mắt mà không có ít nhất hai bản kiểm toán từ các công ty như Trail of Bits hay OpenZeppelin. Việc NAVI Prime không công bố kiểm toán là một tín hiệu xấu. Nó có thể là do họ đang trong quá trình kiểm toán, hoặc tệ hơn, họ không muốn công bố kết quả. Từng audit một dự án DeFi Nigeria, tôi phát hiện 7 lỗi, trong đó 2 lỗi nghiêm trọng về access control. Nếu không có kiểm toán, những lỗi đó có thể đã gây ra thiệt hại lớn. Với NAVI Prime, tôi khuyên các nhà phát triển nên tự kiểm tra mã nguồn nếu có thể, hoặc ít nhất đọc các báo cáo kiểm toán khi chúng được công bố.
Takeaway: Dự báo lỗ hổng – Quản trị là trái tim của vấn đề
Tôi dự đoán rằng trong 3-6 tháng tới, lỗ hổng đầu tiên của NAVI Prime sẽ không phải là lỗi smart contract, mà là lỗi quản trị. Cụ thể, một đề xuất thay đổi tham số rủi ro sẽ được thông qua với số phiếu thấp, dẫn đến việc thiết lập LTV quá cao cho một tài sản, gây ra thanh lý hàng loạt. Điều này đã xảy ra với nhiều giao thức cho vay, và NAVI Prime với nhiều tham số tùy chỉnh sẽ càng dễ bị tổn thương. Câu hỏi đặt ra: bạn có sẵn sàng gửi tài sản của mình vào một giao thức mà tham số rủi ro có thể thay đổi chỉ sau một cuộc bỏ phiếu với 10% tổng số phiếu? Tôi thì không, trừ khi tôi thấy một cơ chế quản trị mạnh mẽ với thời gian khóa và đa số tuyệt đối. Hãy nhớ: Uniswap v2 bot? Đừng quên deadline. NAVI Prime? Đừng quên quản trị.