Niềm tin kiên định sau khủng hoảng an ninh: Tại sao SUI vẫn có tiềm năng tăng lên lâu dài?
1. Phản ứng dây chuyền gây ra bởi một cuộc tấn công
Ngày 22 tháng 5 năm 2023, 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 các thao tác chính xác, dẫn đến thiệt hại tài sản trên 200 triệu USD. Sự kiện này không chỉ là một trong những vụ tai nạn bảo mật lớn nhất trong lĩnh vực DeFi cho đến nay trong năm nay, mà còn là cuộc tấn công hacker có sức tàn phá 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 của 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 làn sóng chấn động này, hệ sinh thái SUI đã thể hiện sự bền bỉ 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 ngắn hạ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 chú ý rõ rệt hơn đến an toàn, xây dựng hạ tầng và chất lượng dự án.
Chúng tôi sẽ xem xét nguyên nhân của sự kiện tấn công này, cơ chế đồng thuận nút của 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, phân tích cấu trúc hệ 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à 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ũ an ninh về sự cố tấn công Cetus, hacker đã thành công trong việc khai thác một lỗ hổng tràn số học quan trọng trong giao thức, nhờ vào vay chớp nhoáng, thao túng giá chính xác và khuyết điểm hợp đồng, đã đánh cắp hơn 200 triệu đô la tài sản số trong thời gian ngắn. Đường 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 để trao đổi 100 tỷ haSUI qua vay chớp nhoáng, cho vay một lượng lớn vốn để thao túng giá.
Cho 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í giao dịch, có đặc điểm đòn bẩy cao, rủi ro thấp và chi phí thấp. Hacker đã lợi dụng cơ chế này để kéo 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ị trí 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 đã sử dụng số lượng token đủ lớn và tính thanh khoản khổng lồ để thành công thao túng giá haSUI. Sau đó, họ lại tiến hành 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 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:
Thiết lập 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 xác minh đầ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, xây dựng đầ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 ngắn: Khi thực hiện thao tác dịch n << 64 trên giá trị số n, do dịch vượt quá bề rộng bit hợp lệ của kiểu dữ liệu uint256 (256 bit), đã xảy ra việc cắt ngắn dữ liệu. Phần tràn cao bị tự động bỏ qua, dẫn đến kết quả toán học thấp hơn nhiều so với mong đợi, từ đó khiến hệ thống đánh giá thấp số lượng haSUI cần thiết để đổi. Cuối cùng, kết quả tính toán khoảng nhỏ hơn 1, nhưng do 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 mã thông báo, thì có thể đổi ra lượng thanh khoản khổng lồ.
③ Rút thanh khoản
Thực hiện hoàn trả vay nhanh, giữ lại lợi nhuận khổng lồ. Cuối cùng rút tổng giá trị lên tới hàng trăm triệu đô la từ nhiều bể thanh khoản.
Tình trạng mất mát tài chính nghiêm trọng, cuộc tấn công đã dẫn đến việc các tài sản sau đây bị đánh cắp:
12,9 triệu SUI (khoảng 54 triệu USD)
6000 triệu đô la 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 của Cetus lần này 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 lỗi trong thư viện toán học Cetus, không phải là sai sót trong cơ chế giá của giao thức hay lỗi trong 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 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 hoàn tất sửa chữa, 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 đủ và loại trừ 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, Cetus Protocol đã thực hiện nhiều đợt kiểm toán, nhưng không phát hiện 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 đưa vào phạm vi kiểm toán.
Các hacker sử dụng giá trị cực đoan để xác định chính xác khoảng giao dịch, tạo ra các tình huống 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 những vấn đề như vậy khó có thể được 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 đã ẩn nấp 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, được 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 vì khi thêm tính thanh khoản, trong quá trình tính toán số lượng token cần thiết, trước tiên đã sử dụng giá trị sai để kiểm tra giới hạn, và đã thay thế phép nhân thông thường bằng phép dịch bit. 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, 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í còn 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 phép cộng, tràn phép trừ, tràn 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 của ngôn ngữ Solidity có lỗ hổng, đều đã vượt qua các câu lệnh kiểm tra trong hợp đồng bằng các tham số được xây dựng tinh vi, thực hiện chuyển khoản vượt mức để thực hiện 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 thác bằng chứng 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 cao như PoW (bằng chứng 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 Epoch: 24 giờ
Cơ chế quy trình:
Ủy thác quyền lợi: Người dùng thông thường không cần tự vận hành nút, chỉ cần đặt cược SUI và ủy thác cho các ứng cử viên xác thự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 vào đồ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 quay xuất khối: Một số ít các 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ỳ bỏ phiếu, dựa trên trọng số bỏ phiếu, tiến hành luân chuyể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à phân quyền.
Ư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 của người dùng thấp hơn.
Độ an toàn cao: Cơ chế staking và ủy thác làm cho chi phí và rủi ro tấn công đồng bộ tăng lên; kết hợp với cơ chế tịch thu trên chuỗi, hiệu quả kìm hãm 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 trong số các xác thực viên phải đồng thuận để xác nhận giao dịch. Cơ chế này đảm bảo rằng ngay cả khi số lượng nút nhỏ 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 đồng thuậ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 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 tính phi tập trung hoàn toàn, nhưng đã nâng cao đáng kể 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.
Xét về mặt mã, điều này làm cho các giao dịch chuyển khoản không thể được đóng gói và đưa 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 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ó chức năng này, ngay cả khi SUI chỉ có 113 người xác thực, Cetus sẽ rất khó khăn để 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 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 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", nên 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 thì các validator 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 đều mặc định 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 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 tế không phải là logic ở tầng giao thức, mà giống như một lớp bảo mật bổ sung để ứng phó với các tình huống khẩn cấp, đảm bảo an toàn cho tài sản 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 trên 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ững người cung cấp thanh khoản chính, giao thức là thứ mà họ muốn đảm bảo an toàn cho vốn nhất, vì thực tế dữ liệu chuỗi trên tvl đều là 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 an toàn.
Đối với nhà đầu tư nhỏ lẻ, những người đóng góp vào sự phát triển của hệ sinh thái, những người ủng hộ mạnh mẽ trong việc xây dựng công nghệ và cộng đồng. Dự án
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
10 thích
Phần thưởng
10
6
Chia sẻ
Bình luận
0/400
GhostInTheChain
· 07-07 02:54
Hacker cũng quá ác liệt rồi, thế giới tiền điện tử vẫn phải chơi một cách ổn định.
Xem bản gốcTrả lời0
MevHunter
· 07-07 02:54
Vẫn thú vị khi mua đáy trong Thị trường Bear
Xem bản gốcTrả lời0
FlashLoanKing
· 07-07 02:36
Bạo kích là bạo kích, mua đáy hăng hái!
Xem bản gốcTrả lời0
GweiTooHigh
· 07-07 02:35
Ai chịu trách nhiệm cho lỗ hổng này?
Xem bản gốcTrả lời0
MEVHunter
· 07-07 02:29
Lỗ hổng tràn p2=p1 vẫn có thể bị hack, mã rác tràn lan, Kinh doanh chênh lệch giá khiến những kẻ đầu cơ vui mừng.
Xem bản gốcTrả lời0
MaticHoleFiller
· 07-07 02:25
chơi đùa với mọi người một chút rồi Rug Pull. Nạn nhân tiếp theo ở đâu?
Độ bền sau cuộc khủng hoảng an toàn sinh thái SUI: Vượt qua sự kiện Cetus để nhìn nhận tiềm năng tăng lên dài hạn
Niềm tin kiên định sau khủng hoảng an ninh: Tại sao SUI vẫn có tiềm năng tăng lên lâu dài?
1. Phản ứng dây chuyền gây ra bởi một cuộc tấn công
Ngày 22 tháng 5 năm 2023, 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 các thao tác chính xác, dẫn đến thiệt hại tài sản trên 200 triệu USD. Sự kiện này không chỉ là một trong những vụ tai nạn bảo mật lớn nhất trong lĩnh vực DeFi cho đến nay trong năm nay, mà còn là cuộc tấn công hacker có sức tàn phá 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 của 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 làn sóng chấn động này, hệ sinh thái SUI đã thể hiện sự bền bỉ 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 ngắn hạ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 chú ý rõ rệt hơn đến an toàn, xây dựng hạ tầng và chất lượng dự án.
Chúng tôi sẽ xem xét nguyên nhân của sự kiện tấn công này, cơ chế đồng thuận nút của 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, phân tích cấu trúc hệ 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à 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ũ an ninh về sự cố tấn công Cetus, hacker đã thành công trong việc khai thác một lỗ hổng tràn số học quan trọng trong giao thức, nhờ vào vay chớp nhoáng, thao túng giá chính xác và khuyết điểm hợp đồng, đã đánh cắp hơn 200 triệu đô la tài sản số trong thời gian ngắn. Đường 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 để trao đổi 100 tỷ haSUI qua vay chớp nhoáng, cho vay một lượng lớn vốn để thao túng giá.
Cho 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í giao dịch, có đặc điểm đòn bẩy cao, rủi ro thấp và chi phí thấp. Hacker đã lợi dụng cơ chế này để kéo 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ị trí 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 đã sử dụng số lượng token đủ lớn và tính thanh khoản khổng lồ để thành công thao túng giá haSUI. Sau đó, họ lại tiến hành 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 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:
Thiết lập 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 xác minh đầ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, xây dựng đầ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 ngắn: Khi thực hiện thao tác dịch n << 64 trên giá trị số n, do dịch vượt quá bề rộng bit hợp lệ của kiểu dữ liệu uint256 (256 bit), đã xảy ra việc cắt ngắn dữ liệu. Phần tràn cao bị tự động bỏ qua, dẫn đến kết quả toán học thấp hơn nhiều so với mong đợi, từ đó khiến hệ thống đánh giá thấp số lượng haSUI cần thiết để đổi. Cuối cùng, kết quả tính toán khoảng nhỏ hơn 1, nhưng do 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 mã thông báo, thì có thể đổi ra lượng thanh khoản khổng lồ.
③ Rút thanh khoản
Thực hiện hoàn trả vay nhanh, giữ lại lợi nhuận khổng lồ. Cuối cùng rút tổng giá trị lên tới hàng trăm triệu đô la từ nhiều bể thanh khoản.
Tình trạng mất mát tài chính nghiêm trọng, cuộc tấn công đã dẫn đến việc các tài sản sau đây bị đánh cắp:
12,9 triệu SUI (khoảng 54 triệu USD)
6000 triệu đô la 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 của Cetus lần này 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 lỗi trong thư viện toán học Cetus, không phải là sai sót trong cơ chế giá của giao thức hay lỗi trong 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 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 hoàn tất sửa chữa, 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 đủ và loại trừ 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, Cetus Protocol đã thực hiện nhiều đợt kiểm toán, nhưng không phát hiện 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 đưa vào phạm vi kiểm toán.
Các hacker sử dụng giá trị cực đoan để xác định chính xác khoảng giao dịch, tạo ra các tình huống 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 những vấn đề như vậy khó có thể được 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 đã ẩ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 toàn tài nguyên và kiểm tra kiểu, được 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 vì khi thêm tính thanh khoản, trong quá trình tính toán số lượng token cần thiết, trước tiên đã sử dụng giá trị sai để kiểm tra giới hạn, và đã thay thế phép nhân thông thường bằng phép dịch bit. 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, 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í còn 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 phép cộng, tràn phép trừ, tràn 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 của ngôn ngữ Solidity có lỗ hổng, đều đã vượt qua các câu lệnh kiểm tra trong hợp đồng bằng các tham số được xây dựng tinh vi, thực hiện chuyển khoản vượt mức để thực hiện 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 thác bằng chứng 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 cao như PoW (bằng chứng 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 Epoch: 24 giờ
Cơ chế quy trình:
Ủy thác quyền lợi: Người dùng thông thường không cần tự vận hành nút, chỉ cần đặt cược SUI và ủy thác cho các ứng cử viên xác thự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 vào đồ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 quay xuất khối: Một số ít các 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ỳ bỏ phiếu, dựa trên trọng số bỏ phiếu, tiến hành luân chuyể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à phân quyền.
Ư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 của người dùng thấp hơn.
Độ an toàn cao: Cơ chế staking và ủy thác làm cho chi phí và rủi ro tấn công đồng bộ tăng lên; kết hợp với cơ chế tịch thu trên chuỗi, hiệu quả kìm hãm 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 trong số các xác thực viên phải đồng thuận để xác nhận giao dịch. Cơ chế này đảm bảo rằng ngay cả khi số lượng nút nhỏ 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 đồng thuậ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 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 tính phi tập trung hoàn toàn, nhưng đã nâng cao đáng kể 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.
Xét về mặt mã, điều này làm cho các giao dịch chuyển khoản không thể được đóng gói và đưa 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 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ó chức năng này, ngay cả khi SUI chỉ có 113 người xác thực, Cetus sẽ rất khó khăn để 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 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 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", nên 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 thì các validator 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 đều mặc định 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 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 tế không phải là logic ở tầng giao thức, mà giống như một lớp bảo mật bổ sung để ứng phó với các tình huống khẩn cấp, đảm bảo an toàn cho tài sản 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 trên 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ững người cung cấp thanh khoản chính, giao thức là thứ mà họ muốn đảm bảo an toàn cho vốn nhất, vì thực tế dữ liệu chuỗi trên tvl đều là 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 an toàn.
Đối với nhà đầu tư nhỏ lẻ, những người đóng góp vào sự phát triển của hệ sinh thái, những người ủng hộ mạnh mẽ trong việc xây dựng công nghệ và cộng đồng. Dự án