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 thao tác 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 cho đến nay trong năm nay, mà còn trở thành cuộc tấn công mạng tàn phá nhất kể từ khi mạng chính SUI ra mắt.
Theo dữ liệu, TVL toàn chuỗi SUI đã giảm mạnh hơn 330 triệu USD trong ngày xảy ra tấn công, số tiền khóa của giao thức Cetus thậm chí đã bốc hơi 84% chỉ trong chốc lát, giảm xuống còn 38 triệu USD. Bị ảnh hưởng nối tiếp, nhiều token phổ biến 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 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 được sức mạnh kiên cường và khả năng phục hồi mạnh mẽ. Mặc dù sự kiện Cetus đã mang lại sự dao động niềm tin trong ngắn hạn, nhưng tiề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.
Bài viết này sẽ xoay quanh nguyên nhân của vụ tấn công này, cơ chế đồng thuận của 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 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à khám phá tiềm năng phát triển trong tương lai của 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ũ an ninh về sự kiện tấn công Cetus, kẻ tấn công đã thành công 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à các lỗi hợp đồng, đã đánh cắp hơn 200 triệu đô la tài sản số trong một khoảng thời gian ngắn. Đường đi 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 bằng vay chớp nhoáng, cho vay một lượng lớn tiền, thực hiện thao túng giá.
Vay chớp nhoáng cho phép người dùng vay mượn và hoàn trả tiền trong cùng một giao dịch, chỉ cần trả phí dịch vụ, có đặc tính đò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ạ 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, với khoảng giá được xác định chính xác 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%.
Thông qua cách trên, hacker đã sử dụng đủ số lượng token và thanh khoản khổng lồ để thành công thao túng 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 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 nguyên nhân:
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 bằng cách thiết lập thông số bất thường, tạo ra đầu vào luôn nhỏ hơn giới hạn đó, do đó vượt qua việc phát hiện 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ị 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 hiện tượng cắ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, do đó 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, nên cuối cùng tính ra bằng 1, tức là hacker chỉ cần thêm 1 token, có thể đổi lấy 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 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 sau đây bị đánh cắp:
1290 triệu đồng SUI (khoảng 5400 triệu USD)
6000 triệu USD 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 này
Lỗ hổng của Cetus có ba đặc điểm:
Chi phí sửa chữa cực kỳ thấp: Một mặt, nguyên nhân cơ bản của sự cố Cetus là một sai sót trong thư viện toán Cetus, không phải 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 chính Cetus, 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ể loại bỏ hoàn toàn 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 sau này đầ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ó sự cố trong hai năm qua, đã trải qua 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à do 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 để chính xác xây dựng 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 được 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ù mắt của mọi 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 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 đố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 việc thêm thanh khoản khi tính toán số lượng token cần thiết, đầu tiên đã sử dụng sai giá trị để 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ì Move sẽ tự động kiểm tra tình huống tràn, không xảy ra vấn đề cắt bớt chữ số 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 (chẳng hạn như Solidity, Rust), thậm chí vì 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ố cộng, tràn số trừ, tràn số 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 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, thực hiện tấn công chuyển khoản vượt 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 quyền chứng minh cổ phần (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 độ 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 thông thường khó có thể trực tiếp ảnh hưởng đế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 đóng SUI và ủy thác cho các ứng viên xác thực, có thể tham gia vào đả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 đồ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 tròn 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 mỗi chu kỳ bỏ phiếu kết thúc, dựa trên trọng số phiếu bầu, tiến hành luân chuyển động, bầu lại tập hợp các Validator, đảm bảo tính linh hoạt của nút, sự đồng nhất lợi ích và tính phi tập trung.
Lợi thế 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ể. Nhờ đó, 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 cho người dùng thấp hơn.
An toàn cao: Cơ chế staking và ủy thác làm tăng đồng bộ chi phí tấn công và rủi ro; 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 ý.
Đồ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ố ít nút làm ác, mạng vẫn có thể duy trì an toàn và hoạt động hiệu quả. Trong 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 để thực hiện.
Về bản chất, DPoS thực sự là một giải pháp thỏa hiệp của tam giác không thể, đã thực hiện thỏa hiệp giữa phi tập trung và hiệu suất. DPoS trong "tam giác không thể" an toàn - phi tập trung - khả năng mở rộng, chọn giảm số lượng nút sản xuất 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 độ nhất định của phi tập trung hoàn toàn, nhưng đã tăng đáng kể khả năng thông lượng của 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
Cơ chế đóng băng hoạt động 3.2.1
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ã, điều này khiến các giao dịch chuyển tiề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 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 đã 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ê. Do chức năng này đã có trong ứng dụng khách, nên 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 người xác thực, sẽ rất khó để phối hợp tất cả các người xác thực phản hồi một cách lần lượt trong thời gian ngắn.
3.2.2 Ai có quyền sửa đổ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 điều hành nút nào cũng 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 riêng 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 là có sự phối hợp. Do đây là "cập nhật khẩn cấp do đội ngũ thúc đẩy", nên về cơ bản, quỹ (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.
Công bố danh sách đen, về lý thuyết, các nhà xác thực 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 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 khẩn cấp, đảm bảo an toàn cho quỹ 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" được 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 ngôi 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à điều muốn đảm bảo tính an toàn của vốn nhất, 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ư nhỏ lẻ, những người đóng góp vào sự năng động của hệ sinh thái, và những người ủng hộ mạnh mẽ trong việc xây dựng công nghệ và cộng đồng. Các 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 dần hoàn thiện hệ sinh thái và 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
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.
Đằng sau tính bền vững của hệ sinh thái SUI: Phân tích sự kiện tấn công Cetus và thảo luận về tiềm năng phát triển trong tương lai
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 thao tác 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 cho đến nay trong năm nay, mà còn trở thành cuộc tấn công mạng tàn phá nhất kể từ khi mạng chính SUI ra mắt.
Theo dữ liệu, TVL toàn chuỗi SUI đã giảm mạnh hơn 330 triệu USD trong ngày xảy ra tấn công, số tiền khóa của giao thức Cetus thậm chí đã bốc hơi 84% chỉ trong chốc lát, giảm xuống còn 38 triệu USD. Bị ảnh hưởng nối tiếp, nhiều token phổ biến 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 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 được sức mạnh kiên cường và khả năng phục hồi mạnh mẽ. Mặc dù sự kiện Cetus đã mang lại sự dao động niềm tin trong ngắn hạn, nhưng tiề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.
Bài viết này sẽ xoay quanh nguyên nhân của vụ tấn công này, cơ chế đồng thuận của 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 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à khám phá tiềm năng phát triển trong tương lai của 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ũ an ninh về sự kiện tấn công Cetus, kẻ tấn công đã thành công 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à các lỗi hợp đồng, đã đánh cắp hơn 200 triệu đô la tài sản số trong một khoảng thời gian ngắn. Đường đi 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 bằng vay chớp nhoáng, cho vay một lượng lớn tiền, thực hiện thao túng giá.
Vay chớp nhoáng cho phép người dùng vay mượn và hoàn trả tiền trong cùng một giao dịch, chỉ cần trả phí dịch vụ, có đặc tính đò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ạ 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, với khoảng giá được xác định chính xác 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%.
Thông qua cách trên, hacker đã sử dụng đủ số lượng token và thanh khoản khổng lồ để thành công thao túng 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 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 nguyên nhân:
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 bằng cách thiết lập thông số bất thường, tạo ra đầu vào luôn nhỏ hơn giới hạn đó, do đó vượt qua việc phát hiện 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ị 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 hiện tượng cắ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, do đó 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, nên cuối cùng tính ra bằng 1, tức là hacker chỉ cần thêm 1 token, có thể đổi lấy 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 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 sau đây bị đánh cắp:
1290 triệu đồng SUI (khoảng 5400 triệu USD)
6000 triệu USD 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 này
Lỗ hổng của Cetus có ba đặc điểm:
Chi phí sửa chữa cực kỳ thấp: Một mặt, nguyên nhân cơ bản của sự cố Cetus là một sai sót trong thư viện toán Cetus, không phải 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 chính Cetus, 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ể loại bỏ hoàn toàn 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 sau này đầ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ó sự cố trong hai năm qua, đã trải qua 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à do 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 để chính xác xây dựng 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 được 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ù mắt của mọi 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 kiểm tra 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 việc thêm thanh khoản khi tính toán số lượng token cần thiết, đầu tiên đã sử dụng sai giá trị để 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ì Move sẽ tự động kiểm tra tình huống tràn, không xảy ra vấn đề cắt bớt chữ số 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 (chẳng hạn như Solidity, Rust), thậm chí vì 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ố cộng, tràn số trừ, tràn số 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 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, thực hiện tấn công chuyển khoản vượt 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 quyền chứng minh cổ phần (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 độ 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 thông thường khó có thể trực tiếp ảnh hưởng đế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 đóng SUI và ủy thác cho các ứng viên xác thực, có thể tham gia vào đả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 đồ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 tròn 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 mỗi chu kỳ bỏ phiếu kết thúc, dựa trên trọng số phiếu bầu, tiến hành luân chuyển động, bầu lại tập hợp các Validator, đảm bảo tính linh hoạt của nút, sự đồng nhất lợi ích và tính phi tập trung.
Lợi thế 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ể. Nhờ đó, 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 cho người dùng thấp hơn.
An toàn cao: Cơ chế staking và ủy thác làm tăng đồng bộ chi phí tấn công và rủi ro; 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 ý.
Đồ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ố ít nút làm ác, mạng vẫn có thể duy trì an toàn và hoạt động hiệu quả. Trong 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 để thực hiện.
Về bản chất, DPoS thực sự là một giải pháp thỏa hiệp của tam giác không thể, đã thực hiện thỏa hiệp giữa phi tập trung và hiệu suất. DPoS trong "tam giác không thể" an toàn - phi tập trung - khả năng mở rộng, chọn giảm số lượng nút sản xuất 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 độ nhất định của phi tập trung hoàn toàn, nhưng đã tăng đáng kể khả năng thông lượng của 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
Cơ chế đóng băng hoạt động 3.2.1
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ã, điều này khiến các giao dịch chuyển tiề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 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 đã 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ê. Do chức năng này đã có trong ứng dụng khách, nên 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 người xác thực, sẽ rất khó để phối hợp tất cả các người xác thực phản hồi một cách lần lượt trong thời gian ngắn.
3.2.2 Ai có quyền sửa đổ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 điều hành nút nào cũng 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 riêng 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 là có sự phối hợp. Do đây là "cập nhật khẩn cấp do đội ngũ thúc đẩy", nên về cơ bản, quỹ (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.
Công bố danh sách đen, về lý thuyết, các nhà xác thực 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 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 khẩn cấp, đảm bảo an toàn cho quỹ 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" được 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 ngôi 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à điều muốn đảm bảo tính an toàn của vốn nhất, 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ư nhỏ lẻ, những người đóng góp vào sự năng động của hệ sinh thái, và những người ủng hộ mạnh mẽ trong việc xây dựng công nghệ và cộng đồng. Các 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 dần hoàn thiện hệ sinh thái và 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