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 là Cetus đã gặp phải một cuộc tấn công từ 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 các thao tác chính xác, dẫn đến thiệt hại tài sản hơn 200 triệu đô la. Sự kiện này không chỉ là một trong những vụ tai nạn 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 có sức 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 SUI đã một lần 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 thậm chí đã ngay lập tức bốc hơi 84%, xuống còn 38 triệu USD. Bị ảnh hưởng liên quan, nhiều token hot trên SUI đã 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 đố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 mạnh phục hồi và khả năng hồi phục mạnh mẽ. Mặc dù sự kiện Cetus đã mang lại sự dao động về lòng tin trong ngắn hạn, nhưng vốn và mức độ hoạt động của người dùng trên chuỗi không gặp phải sự suy giảm kéo dài, mà trái lại, đã thúc đẩy toàn bộ hệ sinh thái chú trọng đáng kể đến vấn đề an toàn, xây dựng cơ sở hạ tầng và chất lượng dự án.
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 đội ngũ 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 số trong thời gian ngắn. Đường đi của cuộc 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á
Tin tặc trước tiên đã lợi dụng trượt giá tối đa để trao đổi 100 tỷ haSUI qua vay chớp nhoáng, cho vay một lượng lớn vốn để thao túng giá cả.
Flash loan 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í, có đặc điểm đòn bẩy cao, rủi ro thấp và chi phí thấp. Hacker đã lợi dụng cơ chế này để làm giảm giá thị trường trong thời gian ngắn và kiểm soát chính xác trong một khoảng rất hẹp.
Sau đó, kẻ tấn công chuẩn bị tạo ra một vị trí thanh khoản cực kỳ hẹp, xác định chính xác khoảng giá giữa mức 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%.
Bằng cách trên, hacker đã sử dụng đủ số lượng token và thanh khoản khổng lồ để thành công điều khiển giá haSUI. Sau đó, họ lại tiếp tục thao túng một vài token không có giá trị thực.
②Thêm tính 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:
Thiết lập mặt nạ quá rộng: tương đương với một giới hạn bổ sung thanh khoản cực lớn, dẫn đến việc xác minh đầ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, tạo ra đầu vào luôn nhỏ hơn giới hạn đó, từ đó vượt qua kiểm tra tràn.
Dữ liệu tràn bị cắt: Khi thực hiện thao tác dịch n << 64 trên giá trị n, do độ dịch chuyển vượt quá độ rộng bit hiệu quả của kiểu dữ liệu uint256 (256 bit), đã xảy ra hiện tượng cắt dữ liệu. Phần tràn cao bị loại bỏ tự động, dẫn đến kết quả tính toán thấp hơn nhiều so với mong đợi, 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 nhỏ hơn khoảng 1, nhưng do được làm tròn lên, kết quả cuối cùng bằng 1, nghĩa là hacker chỉ cần thêm 1 token, có thể đổi lấy khối lượng thanh khoản khổng lồ.
③ Rút thanh khoản
Tiến hành hoàn trả khoản vay chớp nhoáng, giữ lại lợi nhuận khổng lồ. Cuối cùng rút đi tổng giá trị lên tới hàng trăm triệu đô la từ nhiều bể thanh khoản.
Tình hình tổn thất tài chính nghiêm trọng, cuộc tấn công đã dẫn đến việc các tài sản 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ỗi này của Cetus có ba đặc điểm:
Chi phí sửa chữa rất thấp: Một mặt, nguyên nhân cơ bản của sự cố Cetus là một sự thiếu sót trong thư viện toán học Cetus, không phải là lỗi cơ chế giá của giao thức hay lỗi kiến trúc nền tảng. Mặt khác, lỗ hổng chỉ giới hạn trong bản thân Cetus và không liên quan đến mã nguồn của 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 hai dòng mã là có thể hoàn toàn loại bỏ rủi ro; sau khi sửa chữa hoàn tất, có thể ngay lập tức triển khai lên mạng chính, đảm bảo logic hợp đồng trong tương lai đầy đủ, ngăn chặn lỗ hổng này.
Tính ẩn giấu 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 lần kiểm toán, nhưng không phát hiện ra lỗ hổng, lý do chính là thư viện Integer_Mate được sử dụng cho tính 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 để xây dựng chính xác khoảng giao dịch, tạo ra một tình huống cực kỳ hiếm hoi với tính thanh khoản rất cao, mới kích hoạt logic bất thường, cho thấy loại vấn đề nà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 đã tiềm ẩn một thời gian dài mới được phát hiện.
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 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 khi thêm thanh khoản, trong việc 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à các phép cộng, trừ, nhân, chia thông thường trong Move sẽ tự động kiểm tra tình huống tràn, không xảy ra vấn đề cắt bớt 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í do thiếu bảo vệ tràn số nguyên mà dễ bị khai thác hơ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ố trong phép 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ụ, 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 bằng cách cấu trúc các tham số một cách khéo léo, thực hiện tấn công chuyển khoản quá mức.
3. Cơ chế đồng thuận của SUI
Giới thiệu về cơ chế đồng thuận SUI 3.1
Tổng quan:
SUI áp dụng khuôn khổ ủy thác chứng minh quyền lợi (DeleGated Proof of Stake, viết tắt là DPoS). Mặc dù cơ chế DPoS có thể cải thiện thông lượng giao dịch, nhưng nó không thể cung cấp mức độ phi tập trung cao 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 bình 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 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 mà chỉ cần đặt cọc SUI và ủy thác cho các thẩm định viên ứng cử, từ đó 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 cho người dùng thông thường, cho phép họ tham gia vào sự đồng thuận mạng bằng cách "thuê" các thẩm định 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 nhận viên đượ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ố phiếu bầu, tiến hành luân phiên động, bầu lại tập hợp Validator, đảm bảo sức sống của nút, tính nhất quán lợi ích, và phi tập trung.
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 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 mức phí giao dịch của người dùng thấp hơn.
An toàn cao: Cơ chế staking và ủy thác khiến chi phí và rủi ro tấn công đồng bộ tăng lên; kết hợp với cơ chế tịch thu trên chuỗi, hiệu quả kiềm chế hành vi ác ý.
Trong cơ chế đồng thuận của SUI, một thuật toán dựa trên BFT (tolerant Byzantine) được áp dụng, yêu cầu hơn hai phần ba số phiếu từ 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 rằng ngay cả khi một số nút nhỏ xấu, mạng vẫn có thể duy trì an toàn và hoạt động hiệu quả. Mọi nâng cấp hoặc quyết định quan trọng đều cần hơn hai phần ba số phiếu để được thực hiện.
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ể trong việc cân bằng giữa phân quyền và hiệu quả. DPoS trong tam giác "không thể" về an toàn - phân quyền - 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 PoS hoặc PoW thuần túy đã từ bỏ một mức độ phân quyền hoàn toàn nhất định, nhưng đã nâng cao đáng kể khả năng xử lý 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ã nguồn, đây là việc 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, có 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 tương đương với việc 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 được 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 các địa chỉ được liệt kê. Do chức năng này đã có trong ứng dụng khách, 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ó chức năng này, ngay cả khi SUI chỉ có 113 xác thực viên, Cetus rất khó để phối hợp tất cả các xác thực viên phản hồi lần lượ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ỳ 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. 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 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 nó) 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, lý thuyết là các xác thực viên có thể chọn có áp dụng nó hay không -- nhưng 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ù chức năng này bảo vệ quỹ 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 ứng phó với các tình huống bất ngờ, đảm bảo an toàn cho tài sản của người dùng.
Về bản chất là một cơ chế đảm bảo an toàn. Tương tự như một "dây chống trộm" buộc vào cửa, chỉ được kích hoạt cho những người muốn xâm nhập vào nhà, tức là những người có ý định xấu với giao thức. Đối với người dùng:
Đối với những người nắm giữ lớn, những nhà cung cấp thanh khoản chính, giao thức là điều mà họ muốn đảm bảo an toàn cho vốn nhất, vì thực tế dữ liệu trên chuỗi tvl hoàn toàn là do những người nắm giữ lớn đóng góp, muốn 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 các nhà đầu tư nhỏ lẻ, những người đóng góp vào sự sống động của hệ sinh thái, những người hỗ trợ mạnh mẽ cho việc xây dựng công nghệ và cộng đồng. Phía dự án cũng hy vọng có thể thu hút các nhà đầu tư nhỏ lẻ cùng xây dựng, như vậy mới có thể dần dần hoàn thiện hệ sinh thái, tăng cường tỷ lệ giữ chân. Còn đối với lĩnh vực defi, điều quan trọng nhất vẫn là an toàn tài chính.
Để xác định "liệu có trung tâm hóa hay không", chìa khóa nằm ở việc người dùng có quyền kiểm soát tài sản hay không. Ở điểm này, SUI thông qua ngôn ngữ lập trình Move đã thể hiện sự
Trang này có thể chứa nội dung của bên thứ ba, được cung cấp chỉ nhằm mục đích thông tin (không phải là tuyên bố/bảo đảm) và không được coi là sự chứng thực cho quan điểm của Gate hoặc là lời khuyên về tài chính hoặc chuyên môn. Xem Tuyên bố từ chối trách nhiệm để biết chi tiết.
10 thích
Phần thưởng
10
6
Đăng lại
Chia sẻ
Bình luận
0/400
RektRecorder
· 5giờ trước
Ghế đầu hàng đầu của hiện trường thua lỗ lớn
Xem bản gốcTrả lời0
LiquidityNinja
· 5giờ trước
Nhìn xuống rồi, đã cắt lỗ.
Xem bản gốcTrả lời0
MevHunter
· 5giờ trước
Ngồi đợi đổ hàng, ngày dài tháng rộng.
Xem bản gốcTrả lời0
NeverVoteOnDAO
· 5giờ trước
Cũng không phải lần đầu bị hack, quen thì tốt.
Xem bản gốcTrả lời0
BtcDailyResearcher
· 5giờ trước
Cắt lỗ ra ngoài rồi gg
Xem bản gốcTrả lời0
consensus_whisperer
· 5giờ trước
Đã nát như vậy mà còn muốn lừa người khác bắt dao rơi?
Hệ sinh thái SUI thể hiện sức mạnh bền bỉ: Phân tích nâng cấp an toàn sau cuộc tấn công Cetus và tiềm năng tăng lên lâu dài
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 là Cetus đã gặp phải một cuộc tấn công từ 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 các thao tác chính xác, dẫn đến thiệt hại tài sản hơn 200 triệu đô la. Sự kiện này không chỉ là một trong những vụ tai nạn 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 có sức 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 SUI đã một lần 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 thậm chí đã ngay lập tức bốc hơi 84%, xuống còn 38 triệu USD. Bị ảnh hưởng liên quan, nhiều token hot trên SUI đã 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 đố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 mạnh phục hồi và khả năng hồi phục mạnh mẽ. Mặc dù sự kiện Cetus đã mang lại sự dao động về lòng tin trong ngắn hạn, nhưng vốn và mức độ hoạt động của người dùng trên chuỗi không gặp phải sự suy giảm kéo dài, mà trái lại, đã thúc đẩy toàn bộ hệ sinh thái chú trọng đáng kể đến vấn đề an toàn, xây dựng cơ sở hạ tầng và chất lượng dự án.
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 đội ngũ 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 số trong thời gian ngắn. Đường đi của cuộc 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á
Tin tặc trước tiên đã lợi dụng trượt giá tối đa để trao đổi 100 tỷ haSUI qua vay chớp nhoáng, cho vay một lượng lớn vốn để thao túng giá cả.
Flash loan 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í, có đặc điểm đòn bẩy cao, rủi ro thấp và chi phí thấp. Hacker đã lợi dụng cơ chế này để làm giảm giá thị trường trong thời gian ngắn và kiểm soát chính xác trong một khoảng rất hẹp.
Sau đó, kẻ tấn công chuẩn bị tạo ra một vị trí thanh khoản cực kỳ hẹp, xác định chính xác khoảng giá giữa mức 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%.
Bằng cách trên, hacker đã sử dụng đủ số lượng token và thanh khoản khổng lồ để thành công điều khiển giá haSUI. Sau đó, họ lại tiếp tục thao túng một vài token không có giá trị thực.
②Thêm tính 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:
Thiết lập mặt nạ quá rộng: tương đương với một giới hạn bổ sung thanh khoản cực lớn, dẫn đến việc xác minh đầ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, tạo ra đầu vào luôn nhỏ hơn giới hạn đó, từ đó vượt qua kiểm tra tràn.
Dữ liệu tràn bị cắt: Khi thực hiện thao tác dịch n << 64 trên giá trị n, do độ dịch chuyển vượt quá độ rộng bit hiệu quả của kiểu dữ liệu uint256 (256 bit), đã xảy ra hiện tượng cắt dữ liệu. Phần tràn cao bị loại bỏ tự động, dẫn đến kết quả tính toán thấp hơn nhiều so với mong đợi, 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 nhỏ hơn khoảng 1, nhưng do được làm tròn lên, kết quả cuối cùng bằng 1, nghĩa là hacker chỉ cần thêm 1 token, có thể đổi lấy khối lượng thanh khoản khổng lồ.
③ Rút thanh khoản
Tiến hành hoàn trả khoản vay chớp nhoáng, giữ lại lợi nhuận khổng lồ. Cuối cùng rút đi tổng giá trị lên tới hàng trăm triệu đô la từ nhiều bể thanh khoản.
Tình hình tổn thất tài chính nghiêm trọng, cuộc tấn công đã dẫn đến việc các tài sản 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ỗi này của Cetus có ba đặc điểm:
Chi phí sửa chữa rất thấp: Một mặt, nguyên nhân cơ bản của sự cố Cetus là một sự thiếu sót trong thư viện toán học Cetus, không phải là lỗi cơ chế giá của giao thức hay lỗi kiến trúc nền tảng. Mặt khác, lỗ hổng chỉ giới hạn trong bản thân Cetus và không liên quan đến mã nguồn của 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 hai dòng mã là có thể hoàn toàn loại bỏ rủi ro; sau khi sửa chữa hoàn tất, có thể ngay lập tức triển khai lên mạng chính, đảm bảo logic hợp đồng trong tương lai đầy đủ, ngăn chặn lỗ hổng này.
Tính ẩn giấu 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 lần kiểm toán, nhưng không phát hiện ra lỗ hổng, lý do chính là thư viện Integer_Mate được sử dụng cho tính 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 để xây dựng chính xác khoảng giao dịch, tạo ra một tình huống cực kỳ hiếm hoi với tính thanh khoản rất cao, mới kích hoạt logic bất thường, cho thấy loại vấn đề nà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 đã tiềm ẩn một thời gian dài mới được phát hiện.
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 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 khi thêm thanh khoản, trong việc 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à các phép cộng, trừ, nhân, chia thông thường trong Move sẽ tự động kiểm tra tình huống tràn, không xảy ra vấn đề cắt bớt 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í do thiếu bảo vệ tràn số nguyên mà dễ bị khai thác hơ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ố trong phép 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ụ, 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 bằng cách cấu trúc các tham số một cách khéo léo, thực hiện tấn công chuyển khoản quá mức.
3. Cơ chế đồng thuận của SUI
Giới thiệu về cơ chế đồng thuận SUI 3.1
Tổng quan:
SUI áp dụng khuôn khổ ủy thác chứng minh quyền lợi (DeleGated Proof of Stake, viết tắt là DPoS). Mặc dù cơ chế DPoS có thể cải thiện thông lượng giao dịch, nhưng nó không thể cung cấp mức độ phi tập trung cao 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 bình 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 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 mà chỉ cần đặt cọc SUI và ủy thác cho các thẩm định viên ứng cử, từ đó 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 cho người dùng thông thường, cho phép họ tham gia vào sự đồng thuận mạng bằng cách "thuê" các thẩm định 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 nhận viên đượ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ố phiếu bầu, tiến hành luân phiên động, bầu lại tập hợp Validator, đảm bảo sức sống của nút, tính nhất quán lợi ích, và phi tập trung.
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 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 mức phí giao dịch của người dùng thấp hơn.
An toàn cao: Cơ chế staking và ủy thác khiến chi phí và rủi ro tấn công đồng bộ tăng lên; kết hợp với cơ chế tịch thu trên chuỗi, hiệu quả kiềm chế hành vi ác ý.
Trong cơ chế đồng thuận của SUI, một thuật toán dựa trên BFT (tolerant Byzantine) được áp dụng, yêu cầu hơn hai phần ba số phiếu từ 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 rằng ngay cả khi một số nút nhỏ xấu, mạng vẫn có thể duy trì an toàn và hoạt động hiệu quả. Mọi nâng cấp hoặc quyết định quan trọng đều cần hơn hai phần ba số phiếu để được thực hiện.
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ể trong việc cân bằng giữa phân quyền và hiệu quả. DPoS trong tam giác "không thể" về an toàn - phân quyền - 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 PoS hoặc PoW thuần túy đã từ bỏ một mức độ phân quyền hoàn toàn nhất định, nhưng đã nâng cao đáng kể khả năng xử lý 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ã nguồn, đây là việc 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, có 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 tương đương với việc 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 được 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 các địa chỉ được liệt kê. Do chức năng này đã có trong ứng dụng khách, 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ó chức năng này, ngay cả khi SUI chỉ có 113 xác thực viên, Cetus rất khó để phối hợp tất cả các xác thực viên phản hồi lần lượ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ỳ 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. 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 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 nó) 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, lý thuyết là các xác thực viên có thể chọn có áp dụng nó hay không -- nhưng 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ù chức năng này bảo vệ quỹ 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 ứng phó với các tình huống bất ngờ, đảm bảo an toàn cho tài sản của người dùng.
Về bản chất là một cơ chế đảm bảo an toàn. Tương tự như một "dây chống trộm" buộc vào cửa, chỉ được kích hoạt cho những người muốn xâm nhập vào nhà, tức là những người có ý định xấu với giao thức. Đối với người dùng:
Đối với những người nắm giữ lớn, những nhà cung cấp thanh khoản chính, giao thức là điều mà họ muốn đảm bảo an toàn cho vốn nhất, vì thực tế dữ liệu trên chuỗi tvl hoàn toàn là do những người nắm giữ lớn đóng góp, muốn 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 các nhà đầu tư nhỏ lẻ, những người đóng góp vào sự sống động của hệ sinh thái, những người hỗ trợ mạnh mẽ cho việc xây dựng công nghệ và cộng đồng. Phía dự án cũng hy vọng có thể thu hút các nhà đầu tư nhỏ lẻ cùng xây dựng, như vậy mới có thể dần dần hoàn thiện hệ sinh thái, tăng cường tỷ lệ giữ chân. Còn đối với lĩnh vực defi, điều quan trọng nhất vẫn là an toàn tài chính.
Để xác định "liệu có trung tâm hóa hay không", chìa khóa nằm ở việc người dùng có quyền kiểm soát tài sản hay không. Ở điểm này, SUI thông qua ngôn ngữ lập trình Move đã thể hiện sự