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. Phản ứng dây chuyền do một cuộc tấn công gây ra
Ngày 22 tháng 5 năm 2023, giao thức AMM hàng đầu Cetus được triển khai trên mạng SUI đã遭遇 một cuộc tấn công của 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 hơn 200 triệu USD. 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 cho đến nay trong năm nay, mà còn trở thành cuộc tấn công của hacker có sức phá hoại lớn 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 vào ngày xảy ra tấn công đã giảm mạnh hơn 330 triệu USD, số tiền bị khóa của giao thức Cetus thậm chí đã bốc hơi 84% trong nháy mắt, giảm xuống còn 38 triệu USD. Bị ảnh hưởng theo, 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 đã mang lại sự dao động niềm tin trong thời gian ngắn, nhưng nguồn vốn trên chuỗi và mức độ hoạt động của người dùng không gặp phải sự suy giảm liên tục, mà ngược lại, đã thúc đẩy toàn bộ hệ sinh thái gia tăng sự chú ý đến tính an toàn, 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 lần 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 hệ sinh thái của SUI, tổng hợp lại cấu trúc hệ sinh thái hiện tại của chuỗi công khai vẫn đang trong giai đoạn phát triển sớm, và thảo luận về tiềm năng phát triển trong tương lai.
2. Phân tích nguyên nhân tấn công sự kiện Cetus
2.1 Quy trình thực hiện tấn công
Theo phân tích kỹ thuật của đội ngũ Slow Mist về sự kiện tấn công Cetus, tin tặc đã thành công khai thác một lỗi tràn số học quan trọng trong giao thức, nhờ vào vay nhanh, thao túng giá chính xác và lỗi hợp đồng, đã đánh cắp hơn 200 triệu đô la tài sản kỹ thuật số trong thời gian ngắn. Đường tấn công có thể được chia thành ba giai đoạn chính:
①Khởi động cho vay nhanh, thao túng giá cả
Các hacker trước tiên đã lợi dụng việc trượt giá tối đa để trao đổi 100 tỷ haSUI qua vay chớp nhoáng, vay ra một lượng lớn vốn để thao túng giá cả.
Vay chớp nhoáng cho phép người dùng vay và hoàn trả tiền trong cùng một giao dịch, chỉ cần trả phí giao dịch, với đặc tính đòn bẩy cao, rủi ro thấp và chi phí thấp. Tin tặc đã lợi dụng cơ chế này để kéo 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 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 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 đã lợi dụng 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 thao túng một số 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 có lỗ hổng trong hàm checked_shlw, cuối cùng chỉ nhận được 1 token.
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 tính 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 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 phép dịch n << 64 trên giá trị số n, do phép dịch vượt quá bề rộng bit hiệu quả của kiểu dữ liệu uint256 (256 bit), đã xảy ra việc cắt dữ liệu. Phần tràn ở các bit cao bị tự động loại bỏ, dẫn đến kết quả phép 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, tức là hacker chỉ cần thêm 1 token, họ có thể đổi lấy lượng thanh khoản khổng lồ.
③Rút thanh khoản
Thực hiện thanh toán 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 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 sau đây bị đánh cắp:
12,9 triệu SUI (khoảng 54 triệu USD)
6000 triệu đô la USDC
490万美元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 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ự cố Cetus là do một sơ suất trong thư viện toán Cetus, không phải do 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ã của SUI. Nguyên nhân lỗ hổng nằm ở một điều kiện biên, chỉ cần sửa hai dòng mã là có thể loại bỏ hoàn toàn rủi ro; sau khi sửa xong có thể ngay lập tức triển khai lên mạng chính, đảm bảo rằng logic hợp đồng 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 qua, giao thức Cetus đã trải qua nhiều lần kiểm toán, nhưng không phát hiện ra lỗ hổng, nguyên nhân chính là do thư viện Integer_Mate được sử dụng cho các phép toán toán học không nằm trong phạm vi kiểm toán.
Các hacker đã lợi 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 rất cao, từ đó kích hoạt logic bất thường, cho thấy loại vấn đề này khó 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 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 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 thanh khoản, trong quá trình 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, 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 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ự cũng đã xuất hiện trong các ngôn ngữ khác (như Solidity, Rust), thậm chí dễ bị khai thác hơn do thiếu bảo vệ tràn số nguyên; trước khi cập nhật phiên bản Solidity, việc kiểm tra tràn số rất yếu. Lịch sử đã xảy ra các trường hợp tràn số khi cộng, trừ, nhân, nguyên nhân trực tiếp đều do kết quả tính 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 đã bị tấn công bằng cách sử dụng các tham số được xây dựng tinh vi để vượt qua các câu lệnh kiểm tra trong hợp đồng, thực hiện chuyển tiền vượt quá.
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 chứng minh quyền lợi uỷ thác (DeleGated Proof of Stake, viết tắt là DPoS), cơ chế DPoS mặc dù có thể nâng cao 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ể 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 thác quyền lợi: Người dùng bình thường không cần tự 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 đảm bảo an ninh mạng và phân phối phần thưởng. Cơ chế này giúp giảm ngưỡng tham gia cho người dùng bình thường, cho phép họ tham gia đồ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 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 ra khối: Một số ít các xác thực viên được chọn theo thứ tự cố định hoặc ngẫu nhiên để ra 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ố phiếu bầu, tiến hành luân chuyển động, tái bầu chọn tập hợp Validator, đảm bảo sự sống động của nút, sự 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 mili giây, đáp ứng nhu cầu TPS cao.
Chi phí thấp: Số lượng nút tham gia đồng thuận ít hơn, băng thông mạng và tài nguyên tính toán cần thiết cho việc đồng bộ thông tin và tổng hợp chữ ký giảm đáng kể. Do đó, chi phí phần cứng và vận hành giảm, yêu cầu về sức mạnh tính toán giảm, chi phí thấp hơn. Cuối cùng đạt được phí giao dịch người dùng thấp hơn.
An toàn cao: Cơ chế đặt cọc 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, hiệu quả trong việc kiềm chế hành vi xấu.
Trong khi đó, trong cơ chế đồng thuận của SUI, một thuật toán dựa trên BFT (toleran lỗi 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 làm hại, mạng vẫn có thể duy trì hoạt động an toàn và hiệu quả. Để thực hiện bất kỳ nâng cấp hoặc quyết định quan trọng nào, cũng cần phải có hơn hai phần ba số phiếu.
Về bản chất, DPoS thực sự là một giải pháp thỏa hiệp cho tam giác không thể, thực hiện sự thỏa hiệp giữa phi tập trung và hiệu 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 xuất 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 độ hoàn toàn phi tập trung, nhưng đã nâng cao đáng kể khả năng xử lý mạng và tốc độ giao dịch.
3.2 Trong cuộc tấn công này, SUI đã tăng lên.
Cơ chế đóng băng 3.2.1 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.
Xét từ góc độ mã, điều này khiến 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 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 thi 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 giống như đã 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ó 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 đã tồn tại trong client, 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ó tính năng này, ngay cả khi SUI chỉ có 113 xác thực viên, Cetus sẽ rất khó để phối hợp tất cả các xác thực viên 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 đang 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 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 chiến lược 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 họ) 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 thực viên có thể chọn có áp dụng nó hay không ------ nhưng trên thực tế, hầu hết mọi người sẽ tự động áp dụng nó. Do đó, mặc dù chức năng này bảo vệ tài sản của người dùng, nhưng 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 chất không phải là logic cơ bản của 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 đố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 người nắm giữ lớn, nhà cung cấp tính thanh khoản chính, các 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 do những người nắm giữ 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, những người hỗ trợ mạnh mẽ cho việc xây dựng công nghệ và cộng đồng. Đội ngũ dự án cũng hy vọng có thể
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.
8 thích
Phần thưởng
8
4
Chia sẻ
Bình luận
0/400
GetRichLeek
· 13giờ trước
Chơi dở rồi Rekt nhưng vẫn không nhịn được mua đáy sui
Xem bản gốcTrả lời0
ShadowStaker
· 07-26 06:40
tính bền vững của mạng đang bị thử nghiệm fr... nhưng những lỗ hổng tràn số nguyên này đã trở nên cũ kỹ smh. đâu là sự xác thực đúng đắn?
SUI sinh thái độ bền vững thể hiện Tiềm năng tăng lên lâu dài vẫn tồn tại sau khủng hoảng an toàn
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. Phản ứng dây chuyền do một cuộc tấn công gây ra
Ngày 22 tháng 5 năm 2023, giao thức AMM hàng đầu Cetus được triển khai trên mạng SUI đã遭遇 một cuộc tấn công của 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 hơn 200 triệu USD. 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 cho đến nay trong năm nay, mà còn trở thành cuộc tấn công của hacker có sức phá hoại lớn 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 vào ngày xảy ra tấn công đã giảm mạnh hơn 330 triệu USD, số tiền bị khóa của giao thức Cetus thậm chí đã bốc hơi 84% trong nháy mắt, giảm xuống còn 38 triệu USD. Bị ảnh hưởng theo, 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 đã mang lại sự dao động niềm tin trong thời gian ngắn, nhưng nguồn vốn trên chuỗi và mức độ hoạt động của người dùng không gặp phải sự suy giảm liên tục, mà ngược lại, đã thúc đẩy toàn bộ hệ sinh thái gia tăng sự chú ý đến tính an toàn, 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 lần 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 hệ sinh thái của SUI, tổng hợp lại cấu trúc hệ sinh thái hiện tại của chuỗi công khai vẫn đang trong giai đoạn phát triển sớm, và thảo luận về tiềm năng phát triển trong tương lai.
2. Phân tích nguyên nhân tấn công sự kiện Cetus
2.1 Quy trình thực hiện tấn công
Theo phân tích kỹ thuật của đội ngũ Slow Mist về sự kiện tấn công Cetus, tin tặc đã thành công khai thác một lỗi tràn số học quan trọng trong giao thức, nhờ vào vay nhanh, thao túng giá chính xác và lỗi hợp đồng, đã đánh cắp hơn 200 triệu đô la tài sản kỹ thuật số trong thời gian ngắn. Đường tấn công có thể được chia thành ba giai đoạn chính:
①Khởi động cho vay nhanh, thao túng giá cả
Các hacker trước tiên đã lợi dụng việc trượt giá tối đa để trao đổi 100 tỷ haSUI qua vay chớp nhoáng, vay ra một lượng lớn vốn để thao túng giá cả.
Vay chớp nhoáng cho phép người dùng vay và hoàn trả tiền trong cùng một giao dịch, chỉ cần trả phí giao dịch, với đặc tính đòn bẩy cao, rủi ro thấp và chi phí thấp. Tin tặc đã lợi dụng cơ chế này để kéo 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 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 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 đã lợi dụng 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 thao túng một số 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 có lỗ hổng trong hàm checked_shlw, cuối cùng chỉ nhận được 1 token.
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 tính 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 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 phép dịch n << 64 trên giá trị số n, do phép dịch vượt quá bề rộng bit hiệu quả của kiểu dữ liệu uint256 (256 bit), đã xảy ra việc cắt dữ liệu. Phần tràn ở các bit cao bị tự động loại bỏ, dẫn đến kết quả phép 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, tức là hacker chỉ cần thêm 1 token, họ có thể đổi lấy lượng thanh khoản khổng lồ.
③Rút thanh khoản
Thực hiện thanh toán 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 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 sau đây bị đánh cắp:
12,9 triệu SUI (khoảng 54 triệu USD)
6000 triệu đô la USDC
490万美元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 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ự cố Cetus là do một sơ suất trong thư viện toán Cetus, không phải do 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ã của SUI. Nguyên nhân lỗ hổng nằm ở một điều kiện biên, chỉ cần sửa hai dòng mã là có thể loại bỏ hoàn toàn rủi ro; sau khi sửa xong có thể ngay lập tức triển khai lên mạng chính, đảm bảo rằng logic hợp đồng 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 qua, giao thức Cetus đã trải qua nhiều lần kiểm toán, nhưng không phát hiện ra lỗ hổng, nguyên nhân chính là do thư viện Integer_Mate được sử dụng cho các phép toán toán học không nằm trong phạm vi kiểm toán.
Các hacker đã lợi 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 rất cao, từ đó kích hoạt logic bất thường, cho thấy loại vấn đề này khó 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 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 thanh khoản, trong quá trình 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, 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 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ự cũng đã xuất hiện trong các ngôn ngữ khác (như Solidity, Rust), thậm chí dễ bị khai thác hơn do thiếu bảo vệ tràn số nguyên; trước khi cập nhật phiên bản Solidity, việc kiểm tra tràn số rất yếu. Lịch sử đã xảy ra các trường hợp tràn số khi cộng, trừ, nhân, nguyên nhân trực tiếp đều do kết quả tính 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 đã bị tấn công bằng cách sử dụng các tham số được xây dựng tinh vi để vượt qua các câu lệnh kiểm tra trong hợp đồng, thực hiện chuyển tiền vượt quá.
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 chứng minh quyền lợi uỷ thác (DeleGated Proof of Stake, viết tắt là DPoS), cơ chế DPoS mặc dù có thể nâng cao 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ể 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 thác quyền lợi: Người dùng bình thường không cần tự 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 đảm bảo an ninh mạng và phân phối phần thưởng. Cơ chế này giúp giảm ngưỡng tham gia cho người dùng bình thường, cho phép họ tham gia đồ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 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 ra khối: Một số ít các xác thực viên được chọn theo thứ tự cố định hoặc ngẫu nhiên để ra 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ố phiếu bầu, tiến hành luân chuyển động, tái bầu chọn tập hợp Validator, đảm bảo sự sống động của nút, sự 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 mili giây, đáp ứng nhu cầu TPS cao.
Chi phí thấp: Số lượng nút tham gia đồng thuận ít hơn, băng thông mạng và tài nguyên tính toán cần thiết cho việc đồng bộ thông tin và tổng hợp chữ ký giảm đáng kể. Do đó, chi phí phần cứng và vận hành giảm, yêu cầu về sức mạnh tính toán giảm, chi phí thấp hơn. Cuối cùng đạt được phí giao dịch người dùng thấp hơn.
An toàn cao: Cơ chế đặt cọc 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, hiệu quả trong việc kiềm chế hành vi xấu.
Trong khi đó, trong cơ chế đồng thuận của SUI, một thuật toán dựa trên BFT (toleran lỗi 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 làm hại, mạng vẫn có thể duy trì hoạt động an toàn và hiệu quả. Để thực hiện bất kỳ nâng cấp hoặc quyết định quan trọng nào, cũng cần phải có hơn hai phần ba số phiếu.
Về bản chất, DPoS thực sự là một giải pháp thỏa hiệp cho tam giác không thể, thực hiện sự thỏa hiệp giữa phi tập trung và hiệu 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 xuất 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 độ hoàn toàn phi tập trung, nhưng đã nâng cao đáng kể khả năng xử lý mạng và tốc độ giao dịch.
3.2 Trong cuộc tấn công này, SUI đã tăng lên.
Cơ chế đóng băng 3.2.1 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.
Xét từ góc độ mã, điều này khiến 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 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 thi 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 giống như đã 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ó 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 đã tồn tại trong client, 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ó tính năng này, ngay cả khi SUI chỉ có 113 xác thực viên, Cetus sẽ rất khó để phối hợp tất cả các xác thực viên 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 đang 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 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 chiến lược 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 họ) 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 thực viên có thể chọn có áp dụng nó hay không ------ nhưng trên thực tế, hầu hết mọi người sẽ tự động áp dụng nó. Do đó, mặc dù chức năng này bảo vệ tài sản của người dùng, nhưng 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 chất không phải là logic cơ bản của 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 đố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 người nắm giữ lớn, nhà cung cấp tính thanh khoản chính, các 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 do những người nắm giữ 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, những người hỗ trợ mạnh mẽ cho việc xây dựng công nghệ và cộng đồng. Đội ngũ dự án cũng hy vọng có thể