Niềm tin kiên định sau khủng hoảng an ninh: Tại sao SUI vẫn có tiềm năng tăng lên lâu dài?

1. Phản ứng dây chuyền do một cuộc tấn công gây ra

Vào ngày 22 tháng 5 năm 2025, giao thức AMM hàng đầu được triển khai trên mạng SUI, Cetus, đã遭遇黑客攻击. Kẻ tấn công đã lợi dụng một lỗi logic liên quan đến "vấn đề tràn số nguyên" để thực hiện thao tác chính xác, dẫn đến thiệt hại trên 200 triệu đô la tài sản. Sự kiện này không chỉ là một trong những sự cố an ninh lớn nhất trong lĩnh vực DeFi cho đến nay trong năm nay, mà còn trở thành cuộc tấn công của hacker gây thiệt hại nhất kể từ khi mạng chính SUI ra mắt.

Theo dữ liệu từ DefiLlama, TVL toàn chuỗi của SUI trong ngày xảy ra cuộc tấn công đã giảm hơn 330 triệu đô la, trong khi số tiền khóa của giao thức Cetus đã bay hơi 84% chỉ trong chốc lát, giảm xuống còn 38 triệu đô la. Do ảnh hưởng dây chuyền, nhiều token hot trên SUI (bao gồm Lofi, Sudeng, Squirtle, v.v.) đã giảm 76% đến 97% chỉ trong vòng một giờ, gây ra sự quan tâm rộng rãi của thị trường đối với tính an toàn và sự ổn định của hệ sinh thái SUI.

Nhưng sau làn sóng chấn động này, hệ sinh thái SUI đã thể hiện sức bền và khả năng phục hồi mạnh mẽ. Mặc dù sự kiện Cetus đã mang lại sự dao động về niềm tin trong ngắn hạn, nhưng vốn trên chuỗi và mức độ hoạt động của người dùng không gặp phải sự suy giảm kéo dài, mà ngược lại, đã thúc đẩy toàn bộ hệ sinh thái tăng cường sự chú ý đến an ninh, xây dựng cơ sở hạ tầng và chất lượng dự án.

Klein Labs sẽ xem xét nguyên nhân của sự cố tấn công này, cơ chế đồng thuận của các nút SUI, tính an toàn của ngôn ngữ MOVE và sự phát triển của hệ sinh thái SUI, để phân tích cấu trúc sinh thái hiện tại của chuỗi công khai này vẫn đang ở giai đoạn phát triển sớm, cũng như thảo luận về tiềm năng phát triển trong tương lai.

2. Phân tích nguyên nhân tấn công sự kiện Cetus

2.1 quy trình thực hiện tấn công

Theo phân tích kỹ thuật của nhóm Slow Mist về sự kiện tấn công Cetus, hacker đã thành công trong việc khai thác một lỗ hổng tràn số học quan trọng trong giao thức, nhờ vào vay chớp nhoáng, thao túng giá chính xác và khuyết điểm hợp đồng, đã đánh cắp hơn 200 triệu đô la tài sản kỹ thuật số chỉ trong thời gian ngắn. Đường tấn công có thể được chia thành ba giai đoạn chính:

①Khởi động vay chớp nhoáng, thao túng giá cả

Tin tặc trước tiên đã lợi dụng trượt giá tối đa để hoán đổi 100 tỷ haSUI bằng cách vay nhanh, cho vay một lượng lớn vốn để thao túng giá cả.

Vay chớp nhoáng cho phép người dùng vay và hoàn trả tiền trong cùng một giao dịch, chỉ cần trả phí dịch vụ, có đặc điểm là đòn bẩy cao, rủi ro thấp và chi phí thấp. Hacker đã lợi dụng cơ chế này để hạ thấp giá thị trường trong thời gian ngắn và kiểm soát nó chính xác trong một khoảng hẹp.

Sau đó, kẻ tấn công chuẩn bị tạo ra một vị thế thanh khoản cực kỳ hẹp, đặt chính xác khoảng giá giữa mức báo giá thấp nhất là 300,000 và mức giá cao nhất là 300,200, với độ rộng giá chỉ là 1.00496621%.

Thông qua cách trên, hacker đã sử dụng một số lượng token đủ lớn và thanh khoản khổng lồ để thành công thao túng giá haSUI. Sau đó, họ lại thao túng một số token vô giá trị khác.

② Thêm thanh khoản

Kẻ tấn công tạo ra các vị trí thanh khoản hẹp, tuyên bố thêm thanh khoản, nhưng do lỗ hổng trong hàm checked_shlw, cuối cùng chỉ nhận được 1 token.

Về bản chất, điều này là do hai lý do:

1. Thiết lập mặt nạ quá rộng: tương đương với một giới hạn thêm thanh khoản cực lớn, dẫn đến việc kiểm tra đầu vào của người dùng trong hợp đồng trở nên vô nghĩa. Tin tặc đã thiết lập các tham số bất thường, cấu tạo đầu vào luôn nhỏ hơn giới hạn đó, từ đó vượt qua kiểm tra tràn.

2. Dữ liệu tràn bị cắt đứt: Khi thực hiện thao tác dịch n << 64 trên giá trị số n, do sự dịch chuyển vượt quá chiều rộng bit hiệu quả của kiểu dữ liệu uint256 (256 bit), đã xảy ra việc cắt đứt dữ liệu. Phần tràn bit cao bị tự động loại bỏ, dẫn đến kết quả tính toán thấp hơn nhiều so với mong đợi, từ đó khiến hệ thống đánh giá thấp số lượng haSUI cần thiết để đổi. Kết quả tính toán cuối cùng khoảng nhỏ hơn 1, nhưng do được làm tròn lên, cuối cùng tính được là 1, tức là hacker chỉ cần thêm 1 token, thì có thể đổi được lượng thanh khoản khổng lồ.

③ Rút thanh khoản

Thực hiện thanh toán vay chớp nhoáng, giữ lại lợi nhuận khổng lồ. Cuối cùng rút tổng giá trị lên tới hàng trăm triệu đô la tài sản mã thông báo từ nhiều pool thanh khoản.

Tình trạng mất mát tài chính nghiêm trọng, cuộc tấn công đã dẫn đến việc sau đây bị đánh cắp:

• 12,9 triệu SUI (khoảng 54 triệu USD)

• 6000 triệu đô la Mỹ USDC

• 490 triệu USD Haedal Staked SUI

• 1950 triệu đô la TOILET

• Các token khác như HIPPO và LOFI giảm 75-80%, thanh khoản cạn kiệt

2.2 Nguyên nhân và đặc điểm của lỗ hổng lần này

Lỗ hổng của Cetus lần này có ba đặc điểm:

1. Chi phí sửa chữa cực thấp: Một mặt, nguyên nhân cơ bản của sự kiện Cetus là một sai sót trong thư viện toán học Cetus, không phải lỗi cơ chế giá của giao thức hay lỗi kiến trúc cơ bản. Mặt khác, lỗ hổng chỉ giới hạn trong chính Cetus và không liên quan đến mã nguồn SUI. Nguyên nhân của lỗ hổng nằm ở một điều kiện biên, chỉ cần sửa đổi hai dòng mã là có thể loại bỏ hoàn toàn rủi ro; Sau khi sửa chữa hoàn tất, có thể triển khai ngay trên mạng chính, đảm bảo logic hợp đồng sau này đầy đủ và ngăn chặn lỗ hổng này.

2. Tính ẩn danh cao: Hợp đồng đã hoạt động ổn định không có lỗi trong hai năm qua, Cetus Protocol đã thực hiện nhiều cuộc kiểm toán, nhưng không phát hiện ra lỗ hổng nào, nguyên nhân chính là do thư viện Integer_Mate được sử dụng cho tính toán toán học không được bao gồm trong phạm vi kiểm toán.

Tin tặc sử dụng giá trị cực đoan để chính xác xây dựng khoảng giao dịch, tạo ra các tình huống hiếm gặp với tính thanh khoản cực cao, mới kích hoạt logic bất thường, cho thấy các vấn đề như vậy khó có thể phát hiện qua thử nghiệm thông thường. Những vấn đề này thường nằm trong vùng mù của tầm nhìn con người, vì vậy chúng đã tồn tại trong một thời gian dài trước khi được phát hiện.

3. Không phải vấn đề duy nhất của Move:

Move vượt trội hơn nhiều ngôn ngữ hợp đồng thông minh về an ninh tài nguyên và kiểm tra loại, được tích hợp kiểm tra gốc cho vấn đề tràn số nguyên trong các tình huống phổ biến. Lần tràn này xảy ra do việc thêm tính thanh khoản khi tính toán số lượng token cần thiết, đầu tiên đã sử dụng giá trị sai để kiểm tra giới hạn tối đa, và đã sử dụng phép dịch bit thay cho phép nhân thông thường, trong khi nếu là phép cộng, trừ, nhân, chia thông thường trong Move sẽ tự động kiểm tra tình trạng tràn, sẽ không xảy ra vấn đề cắt bớt bit cao như vậy.

Các lỗ hổng tương tự cũng đã xuất hiện trong các ngôn ngữ khác (như Solidity, Rust), thậm chí dễ bị khai thác hơn do thiếu bảo vệ tràn số nguyên; trước khi cập nhật phiên bản Solidity, việc kiểm tra tràn số rất yếu. Trong lịch sử, đã xảy ra tràn số khi cộng, trừ, nhân, và nguyên nhân trực tiếp đều là do kết quả tính toán vượt quá phạm vi. Ví dụ, các lỗ hổng trên hai hợp đồng thông minh BEC và SMT của ngôn ngữ Solidity đều đã bị tấn công thông qua các tham số được cấu trúc một cách tinh vi, vượt qua các câu lệnh kiểm tra trong hợp đồng và thực hiện chuyển tiền quá mức.

3. Cơ chế đồng thuận của SUI

3.1 Giới thiệu cơ chế đồng thuận SUI

Tổng quan:

SUI áp dụng khung ủy thác chứng minh quyền lợi (DeleGated Proof of Stake, viết tắt là DPoS), cơ chế DPoS mặc dù có thể tăng lên khả năng xử lý giao dịch, nhưng không thể cung cấp mức độ phi tập trung cực cao giống như PoW (chứng minh công việc). Do đó, mức độ phi tập trung của SUI tương đối thấp, ngưỡng quản trị tương đối cao, người dùng thông thường khó khăn để ảnh hưởng trực tiếp đến quản trị mạng.

• Số lượng người xác thực trung bình: 106

• Thời gian trung bình của Epoch: 24 giờ

Cơ chế quy trình:

• Ủy thác quyền lợi: Người dùng thông thường không cần tự vận hành nút, chỉ cần đặt cọc SUI và ủy thác cho các xác thực viên ứng cử, có thể tham gia đảm bảo an ninh mạng và phân phối phần thưởng. Cơ chế này có thể giảm bớt rào cản tham gia cho người dùng thông thường, cho phép họ tham gia đồng thuận mạng thông qua việc "thuê" các xác thực viên đáng tin cậy. Đây cũng là một trong những lợi thế lớn của DPoS so với PoS truyền thống.

• Đại diện cho vòng lặp tạo khối: Một số ít các xác thực được chọn theo thứ tự cố định hoặc ngẫu nhiên để tạo khối, nâng cao tốc độ xác nhận và tăng lên TPS.

• Bầu cử động : Sau mỗi chu kỳ bỏ phiếu, dựa trên trọng số bỏ phiếu, tiến hành luân phiên động, tái bầu chọn tập hợp Validator, đảm bảo sự năng động của nút, tính nhất quán về lợi ích, và sự phi tập trung.

Ưu điểm của DPoS:

• Hiệu quả cao: Do số lượng nút tạo khối có thể kiểm soát, mạng có thể hoàn thành xác nhận trong mili giây, đáp ứng nhu cầu TPS cao.

• Chi phí thấp: Số lượng nút tham gia đồng thuận ít hơn, băng thông mạng và tài nguyên tính toán cần thiết cho việc đồng bộ thông tin và tổng hợp chữ ký được giảm đáng kể. Do đó, chi phí phần cứng và vận hành giảm, yêu cầu về sức mạnh tính toán giảm, chi phí thấp hơn. Cuối cùng, phí giao dịch của người dùng cũng thấp hơn.

• An toàn cao: Cơ chế staking và ủy thác làm cho chi phí và rủi ro của các cuộc tấn công tăng lên đồng bộ; kết hợp với cơ chế tịch thu trên chuỗi, hiệu quả kiềm chế hành vi xấu.

Trong cơ chế đồng thuận của SUI, đã áp dụng thuật toán dựa trên BFT (Toleran lỗi Byzantine), yêu cầu hơn hai phần ba số phiếu của những người xác thực phải đạt được sự đồng thuận để xác nhận giao dịch. Cơ chế này đảm bảo rằng ngay cả khi một số nút làm ác, mạng vẫn có thể duy trì an toàn và hoạt động hiệu quả. Để thực hiện bất kỳ nâng cấp hoặc quyết định lớn nào, cũng cần phải có hơn hai phần ba số phiếu bầu.

Về bản chất, DPoS thực sự là một giải pháp thỏa hiệp cho tam giác không thể, thực hiện việc thỏa hiệp giữa phi tập trung và hiệu quả. DPoS trong "tam giác không thể" về an toàn - phi tập trung - khả năng mở rộng, chọn giảm số lượng nút tạo khối hoạt động để đổi lấy hiệu suất cao hơn, so với Pure PoS hoặc PoW đã từ bỏ một mức độ hoàn toàn phi tập trung, nhưng đã nâng cao đáng kể thông lượng mạng và tốc độ giao dịch.

3.2 Hiệu suất của SUI trong cuộc tấn công này

3.2.1 cơ chế đóng băng hoạt động

Trong sự kiện này, SUI đã nhanh chóng đóng băng các địa chỉ liên quan đến kẻ tấn công.

Từ góc độ mã, điều này khiến cho giao dịch chuyển khoản không thể được đóng gói lên chuỗi. Các nút xác thực là thành phần cốt lõi của chuỗi khối SUI, chịu trách nhiệm xác thực giao dịch và thực hiện các quy tắc giao thức. Bằng cách tập thể phớt lờ các giao dịch liên quan đến kẻ tấn công, những người xác thực này giống như đang thực hiện một cơ chế tương tự như 'đóng băng tài khoản' trong tài chính truyền thống ở cấp độ đồng thuận.

SUI bản thân tích hợp cơ chế danh sách từ chối (deny list), đây là một chức năng danh sách đen có thể ngăn chặn bất kỳ giao dịch nào liên quan đến địa chỉ bị liệt kê. Do chức năng này đã có sẵn trong khách hàng, vì vậy khi xảy ra tấn công

SUI có thể ngay lập tức đóng băng địa chỉ của hacker. Nếu không có tính năng này, ngay cả khi SUI chỉ có 113 xác thực viên, Cetus sẽ rất khó để phối hợp tất cả các xác thực viên phản hồi từng người một trong thời gian ngắn.

3.2.2 Ai có quyền thay đổi danh sách đen?

TransactionDenyConfig là tệp cấu hình YAML/TOML được tải cục bộ bởi mỗi xác thực viên. Bất kỳ ai chạy nút đều có thể chỉnh sửa tệp này, tải lại nóng hoặc khởi động lại nút, và cập nhật danh sách. Nhìn bề ngoài, mỗi xác thực viên dường như đang tự do thể hiện giá trị của mình.

Trên thực tế, để đảm bảo tính nhất quán và hiệu quả của chính sách an ninh, việc cập nhật cấu hình quan trọng này thường được điều phối. Do đây là "cập nhật khẩn cấp do đội ngũ SUI thúc đẩy", nên về cơ bản là Quỹ SUI (hoặc các nhà phát triển được ủy quyền của họ) thiết lập và cập nhật danh sách từ chối này.

SUI công bố danh sách đen, về lý thuyết các thợ xác nhận có thể chọn có áp dụng nó hay không ------ nhưng trên thực tế hầu hết mọi người đều mặc định sẽ tự động áp dụng nó. Do đó, mặc dù tính năng này bảo vệ vốn của người dùng, nhưng về bản chất nó thực sự có một mức độ tập trung nhất định.

3.2.3 Bản chất của chức năng danh sách đen

Chức năng danh sách đen thực ra không phải là logic của tầng giao thức, mà giống như một lớp bảo mật bổ sung để ứng phó với các tình huống bất ngờ, đảm bảo an toàn cho quỹ của người dùng.

Về bản chất, đây là cơ chế đảm bảo an toàn. Nó giống như một "chuỗi chống trộm" buộc vào cửa, chỉ được kích hoạt đối với những người muốn xâm nhập vào nhà, tức là những người có ý định xấu đối với giao thức. Đối với người dùng:

• Đối với các nhà đầu tư lớn, những người cung cấp thanh khoản chính, giao thức là thứ mà họ muốn đảm bảo an toàn cho quỹ nhất, bởi vì thực tế dữ liệu trên chuỗi tvl hoàn toàn là do các nhà đầu tư lớn đóng góp, để giao thức phát triển lâu dài, chắc chắn sẽ ưu tiên đảm bảo an toàn.

• Đối với nhà đầu tư nhỏ lẻ, những người đóng góp vào độ hoạt động của hệ sinh thái, sự hỗ trợ mạnh mẽ trong việc xây dựng công nghệ và cộng đồng.