Niềm tin vững chắc 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 là Cetus đã bị tấn công bởi hacker. Kẻ tấn công đã lợi dụng một lỗ hổng logic liên quan đến "vấn đề tràn số nguyên" để thực hiện một cuộc tấn công chính xác, dẫn đến thiệt hại tài sản lên đến hơn 200 triệu đô la. 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 tính đến thời điểm này trong năm, mà còn trở thành cuộc tấn công hacker tàn phá nhất kể từ khi mạng chính SUI được ra mắt.

Theo dữ liệu từ DefiLlama, TVL toàn chuỗi của SUI đã giảm mạnh hơn 330 triệu USD vào ngày xảy ra cuộc tấn công, số tiền khóa của giao thức Cetus đã ngay lập tức bay hơi 84%, giảm xuống còn 38 triệu USD. Do ảnh hưởng liên đới, nhiều đồng tiền hot trên SUI (bao gồm Lofi, Sudeng, Squirtle, v.v.) đã giảm từ 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 về độ 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 mạnh phục hồi và khả năng phục hồi mạnh mẽ. Mặc dù sự kiện Cetus đã gây ra sự biến động về niềm tin trong thời gian ngắ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 liên tục, mà ngược lại, đã thúc đẩy toàn bộ hệ sinh thái chú trọng hơn đến độ an toàn, 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ự kiện tấn công lần này, cơ chế đồng thuận 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, để hệ thống hóa cấu trúc sinh thái hiện tại của chuỗi công khai này đang ở giai đoạn phát triển sớm, và 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ố 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 xướng cho vay chớp nhoáng, thao túng giá cả

Tin tặc trước tiên sử dụng trượt giá tối đa để hoán đổi nhanh 10 tỷ haSUI qua cho vay chớp nhoáng, vay ra 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à trả lại tiền trong cùng một giao dịch, chỉ cần trả phí giao dịch, với đặc tính đòn bẩy cao, rủi ro thấp và chi phí thấp. Hacker đã lợi dụng cơ chế này để kéo giảm giá thị trường trong một khoảng thời gian ngắn và kiểm soát chính xác nó trong một khoảng rất 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, định giá chính xác trong khoảng từ 300,000 đến 300,200, với độ rộng giá chỉ là 1.00496621%.

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

②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 hàm checked_shlw có lỗ hổng, cuối cùng chỉ thu được 1 token.

Về bản chất 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. Kẻ tấn công đã thiết lập các tham số bất thường, tạo ra đầ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 ngắn: Khi thực hiện phép dịch n << 64 trên giá trị số n, do việc dịch vượt quá độ rộng bit hợp lệ của kiểu dữ liệu uint256 (256 bit), đã xảy ra việc cắt ngắn 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 dự kiến, 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, kết quả cuối cùng bằng 1, tức là hacker chỉ cần thêm 1 token, có thể đổi ra lượng thanh khoản khổng lồ.

③ Rút thanh khoản

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

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

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

• 6000 triệu USD

• 490 triệu USD Haedal Staked SUI

• 1950 triệu USD 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 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 thiếu sót trong thư viện toán học của Cetus, không phải do lỗi cơ chế giá của giao thức hay lỗi trong kiến trúc nền tảng. Mặt khác, lỗ hổng chỉ giới hạn ở Cetus và không liên quan đến mã của SUI. Nguyên nhân lỗ hổng nằm ở một điều kiện biên, chỉ cần sửa hai dòng mã là có thể loại bỏ hoàn toàn rủi ro; sau khi sửa xong, có thể ngay lập tức triển khai lên mạng chính, đảm bảo rằng logic hợp đồng tiếp theo đầ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 mà không có sự cố trong hai năm, Cetus Protocol đã thực hiện nhiều lần kiểm toán, nhưng không phát hiện ra lỗ hổng, nguyên nhân chính là do thư viện Integer_Mate được sử dụng cho các phép toán toán học không nằ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 những tình huống hiếm hoi với tính thanh khoản cực cao, từ đó 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 các bài kiểm tra 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 đã âm thầm tồn tại một thời gian dài trước khi được phát hiện.

3. Không phải chỉ có vấn đề của Move:

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

Các lỗ hổng tương tự cũng đã xuất hiện trên 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 các trường hợp tràn số khi cộng, trừ, nhân, nguyên nhân trực tiếp đều là do kết quả phép 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 đã vượt qua các câu lệnh kiểm tra trong hợp đồng thông qua các tham số được cấu trúc cẩn thận, thực hiện tấn công chuyển tiền vượt mức.

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

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

Tổng quan:

SUI áp dụng khung ủy thác quyền chứng minh (DeleGated Proof of Stake, viết tắt là DPoS), cơ chế DPoS mặc dù có thể tăng lên thông lượng giao dịch, nhưng không thể cung cấp mức độ phân quyền cực cao như PoW (chứng minh công việc). Do đó, mức độ phân quyền 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ó có thể ả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 quyền 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 quyền cho các người xác thực ứng cử viên, có thể tham gia vào việc đả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 đối với người dùng thông thường, giúp họ có thể tham gia vào sự đồng thuận mạng thông qua việc "thuê" các người xác thực đá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 quay xuất khối: Một số ít các validator được chọn theo thứ tự cố định hoặc ngẫu nhiên để xuất khối, nâng cao tốc độ xác nhận và tăng lên TPS.

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

Lợi ích của DPoS:

• Hiệu suất 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 mức 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ý 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 đạt được phí giao dịch người dùng thấp hơn.

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

Đồng thời, trong cơ chế đồng thuận của SUI, đã áp dụng thuật toán dựa trên BFT (tolerant Byzantine), yêu cầu hơn hai phần ba số phiếu của các xác thực viên phải đạt được sự đồng thuận để xác nhận giao dịch. Cơ chế này đảm bảo ngay cả khi một số ít nút hành động xấu, 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 quan trọng nào, cũng cần phải có hơn hai phần ba số phiế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 sự thỏa hiệp giữa phi tập trung và hiệu quả. DPoS trong "tam giác không thể" giữa an toàn - phi tập trung - khả năng mở rộng, lựa chọn giảm số lượng nút xuất khối hoạt động để đổi lấy hiệu suất cao hơn, so với PoS thuần túy hoặc PoW đã từ bỏ một mức độ phi tập trung hoàn toàn, 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 địa chỉ liên quan đến kẻ tấn công.

Từ góc độ mã, nó khiến cho các giao dịch chuyển khoản không thể được đóng gói lên chuỗi. Node xác minh là thành phần cốt lõi của chuỗi khối SUI, chịu trách nhiệm xác minh giao dịch và thực hiện quy tắc giao thức. Bằng cách tập thể bỏ qua các giao dịch liên quan đến kẻ tấn công, những người xác minh này thực sự đã 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ỉ đã được liệt kê. Vì chức năng này đã có trong ứng dụng khách, nên khi cuộc tấn công xảy ra,

SUI có thể ngay lập tức đóng băng địa chỉ của hacker. Nếu không có chức năng này, ngay cả khi SUI chỉ có 113 người xác thực, Cetus sẽ rất khó khăn trong việc phối hợp tất cả các người xác thực để trả lờ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 trình xác thực. Bất kỳ người nào 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. Bề ngoài, mỗi trình xác thực dường như đang tự do thể hiện các 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 các chính sách an ninh, việc cập nhật cấu hình quan trọng này thường được phối hợp. Bởi vì đây là "cập nhật khẩn cấp do đội ngũ SUI thúc đẩy", do đó 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 phát hành danh sách đen, về lý thuyết, các xác thực viê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 mặc định sẽ tự động áp dụng nó. Do đó, mặc dù chức năng này bảo vệ tài sả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 vệ an toàn bổ sung nhằm đối phó với các tình huống phát sinh, đảm bảo an toàn cho tài sản của người dùng.

Về bản chất là cơ chế đảm bảo an toàn. Tương tự 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 tính thanh khoản chính, giao thức là điều mà họ muốn đảm bảo tính an toàn cho vốn, vì thực tế dữ liệu trên chuỗi tvl hoàn toàn 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 tính an toàn.

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