Niềm tin kiên định sau cuộc 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. Một 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 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 thao tác chính xác, dẫn đến thiệt hại tài sản lên tới 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 nay trong năm nay, 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 ra mắt.
Theo dữ liệu từ DefiLlama, TVL toàn chuỗi SUI đã giảm mạnh hơn 330 triệu USD vào ngày xảy ra cuộc tấn công, trong khi số tiền khóa của giao thức Cetus đã 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 (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 đối với tính an toàn và sự ổn định của hệ sinh thái SUI.
Nhưng sau cơn sóng xung kích 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 đã gây ra sự dao động về niềm tin trong thời gian ngắn, nhưng dòng tiền trên chuỗi và mức độ hoạt động của người dùng không bị suy giảm liên tục, mà ngược lại, đã thúc đẩy toàn bộ hệ sinh thái nâng cao sự chú ý đến an ninh, 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, tin tặc đã 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 như sau:
①Khởi xướ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 qua vay chớp nhoáng, vay ra một lượng lớn vốn, thực hiện thao túng giá.
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í giao dịch, có tính năng đòn bẩy cao, rủi ro thấp và chi phí thấp. Tin tặc đã 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 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, xác định 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 đủ số lượng token và thanh khoản lớn để thành công thao túng giá haSUI. Sau đó, họ lại thao túng một số token không có giá trị thực.
②Thêm thanh khoản
Kẻ tấn công tạo ra vị trí thanh khoản hẹp, tuyên bố thêm thanh khoản, nhưng do tồn tại lỗ hổng trong hàm checked_shlw, cuối cùng chỉ thu được 1 token.
Về bản chất, điều này là do hai lý do:
Cài đặt 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. Hacker thông qua việc thiết lập các tham số bất thường, cấu trúc đầu vào luôn nhỏ hơn giới hạn này, 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 trái n << 64 trên giá trị số n, do dịch vượt quá độ rộng bit hiệu quả của kiểu dữ liệu uint256 (256 bit), dữ liệu bị cắt. Phần tràn bit cao tự động bị loại bỏ, dẫn đến kết quả tính toán thấp hơn 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 khoảng nhỏ hơn 1, nhưng do làm tròn lên, cuối cùng tính ra lại bằng 1, tức là kẻ tấn công chỉ cần thêm 1 mã thông báo, thì có thể đổi được một lượng thanh khoản khổng lồ.
③Rút thanh khoản
Thực hiện 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 ra 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 nhóm thanh khoản.
Tình trạng mất mát tài sản nghiêm trọng, cuộc tấn công đã dẫn đến việc đánh cắp các tài sản sau:
1290 triệu SUI (khoảng 5400 triệu đô la Mỹ)
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 lần này của Cetus có ba đặc điểm:
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 Cetus, không phải là lỗi cơ chế giá của giao thức hay lỗi kiến trúc cơ sở. Mặt khác, lỗ hổng chỉ giới hạn ở chính Cetus và không liên quan đến mã 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 xong có thể ngay lập tức triển khai lên mạng chính, đảm bảo logic hợp đồng sau này đầy đủ, ngăn chặn lỗ hổng này.
Tính ẩn danh cao: Hợp đồng đã hoạt động ổn định không lỗi 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 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 để xây dựng chính xác khoảng giao dịch, tạo ra những tình huống cực kỳ hiếm hoi với tính thanh khoản cực cao, mới kích hoạt logic bất thường, cho thấy vấn đề này khó phát hiện bằng 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 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,
Không chỉ là vấn đề riêng 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 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 khi thêm tính thanh khoản, trong việc tính toán số lượng token cần thiết, đã sử dụng sai giá trị để kiểm tra giới hạn trên và sử dụng phép dịch bit thay vì 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 cao như vậy.
Các lỗ hổng tương tự đã xuất hiện trong các ngôn ngữ khác (như Solidity, Rust), thậm chí vì sự 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 rất yếu. Trong lịch sử đã xảy ra các trường hợp tràn số trong phép cộng, phép trừ, phép nhân, nguyên nhân trực tiếp đều là do kết quả phép toán vượt quá giới hạn. Ví dụ, hai hợp đồng thông minh BEC và SMT trong ngôn ngữ Solidity đã 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 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 khuôn khổ ủy quyền chứng minh quyền lợi (DeleGated Proof of Stake, gọi tắt là DPoS), mặc dù cơ chế DPoS có thể tăng lên thông lượng giao dịch, nhưng không thể cung cấp mức độ phi tập trung cực 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 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ự mình vận hành nút, chỉ cần ký quỹ SUI và ủy quyền cho các người xác thực ứ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 của 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 người xác thực đáng tin cậy. Đây cũng là một lợi thế lớn của DPoS so với PoS truyền thống.
Đại diện cho vòng lặp xuất khối: Một số ít các trình xác thực đượ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 mỗi chu kỳ kiểm 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 lại tập hợp Validator, đảm bảo sự năng động của các nút, tính nhất quán lợi ích và sự phi tập trung.
Ưu điểm 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ý đượ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 đạt được mức phí giao dịch người dùng thấp.
An toàn cao: Cơ chế staking và ủy thác làm tăng đồng bộ chi phí và rủi ro tấn công; kết hợp với cơ chế tịch thu trên chuỗi, có hiệu quả kiềm chế 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 Fault), 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 rằng ngay cả khi một số nút làm sai, mạng vẫn có thể duy trì hoạt động an toàn và hiệu quả. Khi 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 hơn hai phần ba số phiếu để có thể 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ể, đã thực hiện sự thỏa hiệp giữa phi tập trung và hiệu suất. DPoS trong tam giác "không thể" về an ninh - phi tập trung - khả năng mở rộng, chọn giảm số lượng nút phá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ất định, nhưng đã nâng cao đáng kể thông lượng mạng và tốc độ giao dịch.
3.2 Trong cuộc tấn công này, SUI đã thể hiện như thế nào
Cơ chế đóng băng hoạt động 3.2.1
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 vào chuỗi. Các nút 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 thi 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 minh này 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à 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ê. Do chức năng này đã có trong ứng dụng khách, nên khi có 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 rất khó để phối hợp tất cả các người xác thực 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 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 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 là có sự 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 công bố danh sách đen, về lý thuyết, các xác nhận viên có thể chọn xem có áp dụng nó hay không ------ nhưng 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ệ quỹ của người dùng, nhưng bản chất của 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à nó giống như một lớp bảo mật bổ sung nhằm ứ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 là cơ chế bảo đảm 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 những nhà đầu tư lớn, 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 an toàn cho vốn, 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 có thể 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ư nhỏ lẻ, những người đóng góp vào sự hoạt động của hệ sinh thái, những người ủng hộ mạnh mẽ cho sự xây dựng cộng đồng và công nghệ. Dự án cũng hy vọng có thể thu hút nhà đầu tư nhỏ lẻ tham gia xây dựng, từ đó 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 vốn.
Judgment "liệu có trung tâm hóa hay không" là yếu tố then chốt, đó là người dùng có quyền kiểm soát tài sản hay không. Ở điểm này, SUI nhờ vào Move biên.
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.
12 thích
Phần thưởng
12
6
Chia sẻ
Bình luận
0/400
Web3ProductManager
· 07-25 10:49
nhìn vào dữ liệu giữ chân người dùng... cuộc tấn công này có thể là một điểm cản trở lớn cho việc áp dụng phổ biến thật lòng mà nói
Xem bản gốcTrả lời0
MEVHunterWang
· 07-25 10:48
Lỗ hổng lớn như vậy mà không ai phát hiện? Thật bất ngờ.
Xem bản gốcTrả lời0
fren.eth
· 07-25 10:48
Thảm hại quá, đã thua lỗ mấy đợt rồi.
Xem bản gốcTrả lời0
¯\_(ツ)_/¯
· 07-25 10:46
chơi đùa với mọi người một chút, lúc nào thì nên tăng lên thì sẽ tăng lên.
Xem bản gốcTrả lời0
MetaverseMigrant
· 07-25 10:26
Chuyến xe này không còn nữa mà vẫn dám nhập một vị thế thật sự là những chiến sĩ.
Phân tích hệ sinh thái SUI: Khả năng phục hồi và tiềm năng tăng lên lâu dài sau sự kiện tấn công Cetus
Niềm tin kiên định sau cuộc 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. Một 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 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 thao tác chính xác, dẫn đến thiệt hại tài sản lên tới 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 nay trong năm nay, 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 ra mắt.
Theo dữ liệu từ DefiLlama, TVL toàn chuỗi SUI đã giảm mạnh hơn 330 triệu USD vào ngày xảy ra cuộc tấn công, trong khi số tiền khóa của giao thức Cetus đã 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 (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 đối với tính an toàn và sự ổn định của hệ sinh thái SUI.
Nhưng sau cơn sóng xung kích 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 đã gây ra sự dao động về niềm tin trong thời gian ngắn, nhưng dòng tiền trên chuỗi và mức độ hoạt động của người dùng không bị suy giảm liên tục, mà ngược lại, đã thúc đẩy toàn bộ hệ sinh thái nâng cao sự chú ý đến an ninh, 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, tin tặc đã 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 như sau:
①Khởi xướ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 qua vay chớp nhoáng, vay ra một lượng lớn vốn, thực hiện thao túng giá.
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í giao dịch, có tính năng đòn bẩy cao, rủi ro thấp và chi phí thấp. Tin tặc đã 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 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, xác định 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 đủ số lượng token và thanh khoản lớn để thành công thao túng giá haSUI. Sau đó, họ lại thao túng một số token không có giá trị thực.
②Thêm thanh khoản
Kẻ tấn công tạo ra vị trí thanh khoản hẹp, tuyên bố thêm thanh khoản, nhưng do tồn tại lỗ hổng trong hàm checked_shlw, cuối cùng chỉ thu được 1 token.
Về bản chất, điều này là do hai lý do:
Cài đặt 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. Hacker thông qua việc thiết lập các tham số bất thường, cấu trúc đầu vào luôn nhỏ hơn giới hạn này, 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 trái n << 64 trên giá trị số n, do dịch vượt quá độ rộng bit hiệu quả của kiểu dữ liệu uint256 (256 bit), dữ liệu bị cắt. Phần tràn bit cao tự động bị loại bỏ, dẫn đến kết quả tính toán thấp hơn 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 khoảng nhỏ hơn 1, nhưng do làm tròn lên, cuối cùng tính ra lại bằng 1, tức là kẻ tấn công chỉ cần thêm 1 mã thông báo, thì có thể đổi được một lượng thanh khoản khổng lồ.
③Rút thanh khoản
Thực hiện 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 ra 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 nhóm thanh khoản.
Tình trạng mất mát tài sản nghiêm trọng, cuộc tấn công đã dẫn đến việc đánh cắp các tài sản sau:
1290 triệu SUI (khoảng 5400 triệu đô la Mỹ)
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 lần này của Cetus có ba đặc điểm:
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 Cetus, không phải là lỗi cơ chế giá của giao thức hay lỗi kiến trúc cơ sở. Mặt khác, lỗ hổng chỉ giới hạn ở chính Cetus và không liên quan đến mã 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 xong có thể ngay lập tức triển khai lên mạng chính, đảm bảo logic hợp đồng sau này đầy đủ, ngăn chặn lỗ hổng này.
Tính ẩn danh cao: Hợp đồng đã hoạt động ổn định không lỗi 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 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 để xây dựng chính xác khoảng giao dịch, tạo ra những tình huống cực kỳ hiếm hoi với tính thanh khoản cực cao, mới kích hoạt logic bất thường, cho thấy vấn đề này khó phát hiện bằng 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 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,
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 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 khi thêm tính thanh khoản, trong việc tính toán số lượng token cần thiết, đã sử dụng sai giá trị để kiểm tra giới hạn trên và sử dụng phép dịch bit thay vì 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 cao như vậy.
Các lỗ hổng tương tự đã xuất hiện trong các ngôn ngữ khác (như Solidity, Rust), thậm chí vì sự 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 rất yếu. Trong lịch sử đã xảy ra các trường hợp tràn số trong phép cộng, phép trừ, phép nhân, nguyên nhân trực tiếp đều là do kết quả phép toán vượt quá giới hạn. Ví dụ, hai hợp đồng thông minh BEC và SMT trong ngôn ngữ Solidity đã 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 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 khuôn khổ ủy quyền chứng minh quyền lợi (DeleGated Proof of Stake, gọi tắt là DPoS), mặc dù cơ chế DPoS có thể tăng lên thông lượng giao dịch, nhưng không thể cung cấp mức độ phi tập trung cực 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 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ự mình vận hành nút, chỉ cần ký quỹ SUI và ủy quyền cho các người xác thực ứ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 của 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 người xác thực đáng tin cậy. Đây cũng là một lợi thế lớn của DPoS so với PoS truyền thống.
Đại diện cho vòng lặp xuất khối: Một số ít các trình xác thực đượ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 mỗi chu kỳ kiểm 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 lại tập hợp Validator, đảm bảo sự năng động của các nút, tính nhất quán lợi ích và sự phi tập trung.
Ưu điểm 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ý đượ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 đạt được mức phí giao dịch người dùng thấp.
An toàn cao: Cơ chế staking và ủy thác làm tăng đồng bộ chi phí và rủi ro tấn công; kết hợp với cơ chế tịch thu trên chuỗi, có hiệu quả kiềm chế 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 Fault), 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 rằng ngay cả khi một số nút làm sai, mạng vẫn có thể duy trì hoạt động an toàn và hiệu quả. Khi 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 hơn hai phần ba số phiếu để có thể 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ể, đã thực hiện sự thỏa hiệp giữa phi tập trung và hiệu suất. DPoS trong tam giác "không thể" về an ninh - phi tập trung - khả năng mở rộng, chọn giảm số lượng nút phá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ất định, nhưng đã nâng cao đáng kể thông lượng mạng và tốc độ giao dịch.
3.2 Trong cuộc tấn công này, SUI đã thể hiện như thế nào
Cơ chế đóng băng hoạt động 3.2.1
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 vào chuỗi. Các nút 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 thi 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 minh này 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à 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ê. Do chức năng này đã có trong ứng dụng khách, nên khi có 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 rất khó để phối hợp tất cả các người xác thực 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 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 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 là có sự 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 công bố danh sách đen, về lý thuyết, các xác nhận viên có thể chọn xem có áp dụng nó hay không ------ nhưng 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ệ quỹ của người dùng, nhưng bản chất của 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à nó giống như một lớp bảo mật bổ sung nhằm ứ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 là cơ chế bảo đảm 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 những nhà đầu tư lớn, 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 an toàn cho vốn, 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 có thể 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ư nhỏ lẻ, những người đóng góp vào sự hoạt động của hệ sinh thái, những người ủng hộ mạnh mẽ cho sự xây dựng cộng đồng và công nghệ. Dự án cũng hy vọng có thể thu hút nhà đầu tư nhỏ lẻ tham gia xây dựng, từ đó 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 vốn.
Judgment "liệu có trung tâm hóa hay không" là yếu tố then chốt, đó là người dùng có quyền kiểm soát tài sản hay không. Ở điểm này, SUI nhờ vào Move biên.