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. Một phản ứng dây chuyền gây ra bởi một cuộc tấn công
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 đã遭遇黑客攻击, 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 tổn thất hơn 200 triệu đô la tài sản. Sự kiện này không chỉ là một trong những sự cố an ninh lớn nhất trong lĩnh vực DeFi tính đến thời điểm này trong năm, mà còn trở thành cuộc tấn công của hacker gây thiệt hại lớn nhất kể từ khi mạng chính SUI đi vào hoạt động.
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, số tiền khóa của giao thức Cetus còn 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 liên quan, nhiều token nổi bật 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 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 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 bị suy giảm liên tục, 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.
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á cả chính xác và khiếm khuyết 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 vay chớp nhoáng, thao túng giá cả
Tin tặc trước tiên đã lợi dụng trượt giá tối đa để hoán đổi 100 tỷ haSUI bằng cách vay mượn một lượng lớn vốn, thực hiện thao túng giá.
Cho vay chớp nhoáng cho phép người dùng vay và hoàn trả tiền trong cùng một giao dịch, chỉ cần trả phí dịch vụ, với đặ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 nó trong một khoảng hẹp.
Sau đó, kẻ tấn công chuẩn bị tạo ra một vị thế thanh khoản cực kỳ hẹp, đặt chính xác khoảng giá giữa mức báo giá thấp nhất là 300,000 và mức giá cao nhất là 300,200, với độ rộng giá chỉ là 1.00496621%.
Thông qua cách trên, tin tặc đã sử dụng một số lượng token đủ lớn và thanh khoản khổng lồ để thành công thao túng giá haSUI. Sau đó, họ lại nhằm vào một vài token không có giá trị thực để thao túng.
②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ỉ 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 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, 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 bị cắt ngắn do tràn: Khi thực hiện thao tác dịch chuyển n << 64 trên giá trị số n, do sự dịch chuyển vượt quá bề rộng bit hợp lệ của kiểu dữ liệu uint256 (256 bit), đã xảy ra 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 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, cuối cùng tính ra lại bằng 1, tức là hacker chỉ cần thêm 1 token, có thể đổi lấy số 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ài sản mã thông báo từ nhiều bể thanh khoản.
Tình trạng mất mát vố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:
12,9 triệu SUI (khoảng 54 triệu USD)
6000 triệu đô la 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 học 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. Nguồn gốc 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 hoàn thiện, ngăn chặn lỗ hổng này.
Độ ẩn danh cao: Hợp đồng đã hoạt động ổn định trong hai năm mà không gặp sự cố, Cetus Protocol đã trải qua nhiều lần kiểm toán, nhưng không phát hiện ra lỗ hổng nào, nguyên nhân chính là do thư viện Integer_Mate dùng cho tính toán toán học không nằm trong phạm vi kiểm toán.
Các hacker sử dụng giá trị cực đoan để chính xác cấu trúc khoảng giao dịch, tạo ra những tình huống rất hiếm hoi với thanh khoản cực cao, mới kích hoạt logic bất thường, cho thấy các vấn đề này khó có thể được phát hiện thông qua các thử nghiệm thông thường. Các vấn đề này thường nằm trong vùng mù trong tầm nhìn của mọi người, do đó đã ẩn nấp một thời gian dài trước khi đượ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 ninh tài nguyên và kiểm tra kiểu, tích hợp kiểm tra nguyên bản 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 vì khi thêm tính thanh khoản, trong việc tính toán số lượng mã thông báo 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 chuyển, trong khi nếu là các phép toán cộng, trừ, nhân, chia thông thường thì trong Move sẽ tự động kiểm tra tình trạng tràn, sẽ không xảy ra vấn đề cắt bớt bit cao như vậy.
Các lỗ hổng tương tự cũng đã xuất hiện ở 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 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 do kết quả tính toán vượt quá giới hạn. 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 xây dựng các tham số một cách khéo léo, thực hiện chuyển khoản vượt mức để tấn công.
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 quyền chứng minh cổ phần (DeleGated Proof of Stake, viết 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 bình thường khó có thể ảnh hưởng trực tiếp đến quản trị mạng.
Số lượng 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ự mình vận hành nút, chỉ cần đặt cược SUI và ủy thác cho các xác thực viên ứng cử, có thể tham gia 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 ngưỡng 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 xác thực viên đá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 những người xác thực được chọn theo thứ tự cố định hoặc ngẫu nhiên để xuất khối, tăng tốc độ xác nhận và nâng cao TPS.
Bầu cử động: Sau mỗi chu kỳ bỏ phiếu, dựa trên trọng số bỏ phiếu, thực hiện quay vòng động, tái bầu cử tập hợp Validator, đảm bảo tính năng động của nút, nhất quán lợi ích và tính 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 cấp độ mili giây, đáp ứng nhu cầu TPS cao.
Chi phí thấp: Số 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 đồng thời chi phí và rủi ro của các cuộc tấn công; kết hợp với cơ chế tịch thu trên chuỗi, hiệu quả ngăn chặn các hành vi xấu.
Đồng thời, trong cơ chế đồng thuận của SUI, đã sử dụng thuật toán dựa trên BFT (Toleransi lỗi Byzantine), yêu cầu hơn hai phần ba số phiếu từ các xác thực phải đạt được sự đồng thuận để xác nhận giao dịch. Cơ chế này đảm bảo rằng ngay cả khi một số nút nhỏ làm hại, mạng vẫn có thể duy trì an toàn và hoạt động 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 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 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ể" về an toàn - phi tập trung - khả năng mở rộng, 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 độ nhất định của sự phi tập trung hoàn toàn, nhưng đã nâng cao đáng kể khả năng thông lượng mạng và tốc độ giao dịch.
3.2 Hiệu suất của SUI trong cuộc tấn công này
3.2.1 Cơ chế đóng băng hoạt động
Trong sự kiện này, SUI đã nhanh chóng đóng băng các địa chỉ liên quan đến kẻ tấn công.
Từ góc độ mã, nó làm cho các giao dịch chuyển khoản không thể được đóng gói lên 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 hiện các 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 tương đương với việc thực hiện một cơ chế giống như 'đóng băng tài khoản' trong tài chính truyền thống ở cấp độ đồng thuận.
SUI本身内置了 từ chối danh sách (deny list) cơ chế, đâ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 khách hàng, 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ó để 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 xác thực viên. Bất kỳ ai chạy nút đều có thể chỉnh sửa tệp này, tải lại nóng hoặc khởi động lại nút và cập nhật danh sách. Bề ngoài, mỗi xác thực viên 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 là có sự phối hợp 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, lý thuyết là các xác nhận 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 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 ở tầng giao thức, nó giống như một lớp bảo vệ an ninh bổ sung để đối phó với những 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, đây là cơ chế bảo đảm an toàn. Giống 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 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à thứ mà họ muốn đảm bảo an toàn tài chính nhất, bởi vì thực tế dữ liệu trên chuỗi tvl đều 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 độ hoạt động của hệ sinh thái, và là những người ủng hộ mạnh mẽ cho sự xây dựng công nghệ và cộng đồng. Nhóm dự án cũng hy vọng có thể thu hút nhà đầu tư nhỏ lẻ tham gia xây dựng, như vậy mới có thể 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, vấn đề quan trọng nhất vẫn là an toàn tài chính.
Chìa khóa để đánh giá "có trung tâm hóa hay không" là người dùng có quyền kiểm soát tài sản hay không. Ở điểm này, SUI đã thể hiện quyền của người dùng thông qua ngôn ngữ lập trình Move.
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.
11 thích
Phần thưởng
11
5
Chia sẻ
Bình luận
0/400
SchrodingersPaper
· 07-21 04:20
Lại một đợt Rekt nữa, SUI giết tôi một vạn lần... nhưng tôi vẫn không thể kìm được muốn theo pullback.
Xem bản gốcTrả lời0
MEVHunterLucky
· 07-21 04:18
sui thảm về thảm, dù sao thì tôi nhớ là không bị lỗ bao giờ
SUI sinh thái thể hiện khả năng chống chịu: Phân tích sự an toàn sau cuộc tấn công Cetus và tiềm năng phát triển lâu dài
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. Một phản ứng dây chuyền gây ra bởi một cuộc tấn công
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 đã遭遇黑客攻击, 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 tổn thất hơn 200 triệu đô la tài sản. Sự kiện này không chỉ là một trong những sự cố an ninh lớn nhất trong lĩnh vực DeFi tính đến thời điểm này trong năm, mà còn trở thành cuộc tấn công của hacker gây thiệt hại lớn nhất kể từ khi mạng chính SUI đi vào hoạt động.
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, số tiền khóa của giao thức Cetus còn 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 liên quan, nhiều token nổi bật 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 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 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 bị suy giảm liên tục, 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.
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á cả chính xác và khiếm khuyết 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 vay chớp nhoáng, thao túng giá cả
Tin tặc trước tiên đã lợi dụng trượt giá tối đa để hoán đổi 100 tỷ haSUI bằng cách vay mượn một lượng lớn vốn, thực hiện thao túng giá.
Cho vay chớp nhoáng cho phép người dùng vay và hoàn trả tiền trong cùng một giao dịch, chỉ cần trả phí dịch vụ, với đặ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 nó trong một khoảng hẹp.
Sau đó, kẻ tấn công chuẩn bị tạo ra một vị thế thanh khoản cực kỳ hẹp, đặt chính xác khoảng giá giữa mức báo giá thấp nhất là 300,000 và mức giá cao nhất là 300,200, với độ rộng giá chỉ là 1.00496621%.
Thông qua cách trên, tin tặc đã sử dụng một số lượng token đủ lớn và thanh khoản khổng lồ để thành công thao túng giá haSUI. Sau đó, họ lại nhằm vào một vài token không có giá trị thực để thao túng.
②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ỉ 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 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, 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 bị cắt ngắn do tràn: Khi thực hiện thao tác dịch chuyển n << 64 trên giá trị số n, do sự dịch chuyển vượt quá bề rộng bit hợp lệ của kiểu dữ liệu uint256 (256 bit), đã xảy ra 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 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, cuối cùng tính ra lại bằng 1, tức là hacker chỉ cần thêm 1 token, có thể đổi lấy số 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ài sản mã thông báo từ nhiều bể thanh khoản.
Tình trạng mất mát vố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:
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 học 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. Nguồn gốc 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 hoàn thiện, ngăn chặn lỗ hổng này.
Độ ẩn danh cao: Hợp đồng đã hoạt động ổn định trong hai năm mà không gặp sự cố, Cetus Protocol đã trải qua nhiều lần kiểm toán, nhưng không phát hiện ra lỗ hổng nào, nguyên nhân chính là do thư viện Integer_Mate dùng cho tính toán toán học không nằm trong phạm vi kiểm toán.
Các hacker sử dụng giá trị cực đoan để chính xác cấu trúc khoảng giao dịch, tạo ra những tình huống rất hiếm hoi với thanh khoản cực cao, mới kích hoạt logic bất thường, cho thấy các vấn đề này khó có thể được phát hiện thông qua các thử nghiệm thông thường. Các vấn đề này thường nằm trong vùng mù trong tầm nhìn của mọi người, do đó đã ẩn nấp 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 ninh tài nguyên và kiểm tra kiểu, tích hợp kiểm tra nguyên bản 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 vì khi thêm tính thanh khoản, trong việc tính toán số lượng mã thông báo 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 chuyển, trong khi nếu là các phép toán cộng, trừ, nhân, chia thông thường thì trong Move sẽ tự động kiểm tra tình trạng tràn, sẽ không xảy ra vấn đề cắt bớt bit cao như vậy.
Các lỗ hổng tương tự cũng đã xuất hiện ở 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 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 do kết quả tính toán vượt quá giới hạn. 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 xây dựng các tham số một cách khéo léo, thực hiện chuyển khoản vượt mức để tấn công.
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 quyền chứng minh cổ phần (DeleGated Proof of Stake, viết 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 bình thường khó có thể ảnh hưởng trực tiếp đến quản trị mạng.
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ự mình vận hành nút, chỉ cần đặt cược SUI và ủy thác cho các xác thực viên ứng cử, có thể tham gia 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 ngưỡng 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 xác thực viên đá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 những người xác thực được chọn theo thứ tự cố định hoặc ngẫu nhiên để xuất khối, tăng tốc độ xác nhận và nâng cao TPS.
Bầu cử động: Sau mỗi chu kỳ bỏ phiếu, dựa trên trọng số bỏ phiếu, thực hiện quay vòng động, tái bầu cử tập hợp Validator, đảm bảo tính năng động của nút, nhất quán lợi ích và tính 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 cấp độ mili giây, đáp ứng nhu cầu TPS cao.
Chi phí thấp: Số 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 đồng thời chi phí và rủi ro của các cuộc tấn công; kết hợp với cơ chế tịch thu trên chuỗi, hiệu quả ngăn chặn các hành vi xấu.
Đồng thời, trong cơ chế đồng thuận của SUI, đã sử dụng thuật toán dựa trên BFT (Toleransi lỗi Byzantine), yêu cầu hơn hai phần ba số phiếu từ các xác thực phải đạt được sự đồng thuận để xác nhận giao dịch. Cơ chế này đảm bảo rằng ngay cả khi một số nút nhỏ làm hại, mạng vẫn có thể duy trì an toàn và hoạt động 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 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 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ể" về an toàn - phi tập trung - khả năng mở rộng, 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 độ nhất định của sự phi tập trung hoàn toàn, nhưng đã nâng cao đáng kể khả năng thông lượng mạng và tốc độ giao dịch.
3.2 Hiệu suất của SUI trong cuộc tấn công này
3.2.1 Cơ chế đóng băng hoạt động
Trong sự kiện này, SUI đã nhanh chóng đóng băng các địa chỉ liên quan đến kẻ tấn công.
Từ góc độ mã, nó làm cho các giao dịch chuyển khoản không thể được đóng gói lên 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 hiện các 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 tương đương với việc thực hiện một cơ chế giống như 'đóng băng tài khoản' trong tài chính truyền thống ở cấp độ đồng thuận.
SUI本身内置了 từ chối danh sách (deny list) cơ chế, đâ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 khách hàng, 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ó để 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 xác thực viên. Bất kỳ ai chạy nút đều có thể chỉnh sửa tệp này, tải lại nóng hoặc khởi động lại nút và cập nhật danh sách. Bề ngoài, mỗi xác thực viên 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 là có sự phối hợp 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, lý thuyết là các xác nhận 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 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 ở tầng giao thức, nó giống như một lớp bảo vệ an ninh bổ sung để đối phó với những 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, đây là cơ chế bảo đảm an toàn. Giống 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 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à thứ mà họ muốn đảm bảo an toàn tài chính nhất, bởi vì thực tế dữ liệu trên chuỗi tvl đều 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 độ hoạt động của hệ sinh thái, và là những người ủng hộ mạnh mẽ cho sự xây dựng công nghệ và cộng đồng. Nhóm dự án cũng hy vọng có thể thu hút nhà đầu tư nhỏ lẻ tham gia xây dựng, như vậy mới có thể 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, vấn đề quan trọng nhất vẫn là an toàn tài chính.
Chìa khóa để đánh giá "có trung tâm hóa hay không" là người dùng có quyền kiểm soát tài sản hay không. Ở điểm này, SUI đã thể hiện quyền của người dùng thông qua ngôn ngữ lập trình Move.