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 gây ra bởi một cuộc tấn công
Vào ngày 22 tháng 5 năm 2023, giao thức AMM hàng đầu triển khai trên mạng SUI là Cetus đã bị tấn công bởi hacker. Kẻ tấn công đã lợi dụng một lỗ hổng logic liên quan đến "vấn đề tràn số nguyên" để thực hiện các thao tác chính xác, dẫn đến thiệt hại vượt quá 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 của hacker tàn phá nhất kể từ khi mạng chính SUI ra mắt.
Theo dữ liệu từ DefiLlama, TVL toàn chuỗi SUI đã giảm mạnh hơn 330 triệu đô la 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%, giảm xuống còn 38 triệu đô la. Do ảnh hưởng liên quan, 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 làn sóng chấn động 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 những biến độ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 gặp phải sự suy giảm kéo dài, trái lại, đã thúc đẩy toàn bộ hệ sinh thái chú ý đáng kể đến an toàn, xây dựng cơ sở hạ tầng và chất lượng dự án.
Chúng tôi sẽ tập trung vào nguyên nhân của sự cố tấn công lần này, cơ chế đồng thuận của nút SUI, tính bảo mật của ngôn ngữ MOVE và sự phát triển của hệ sinh thái SUI, để tổng hợp cấu trúc sinh thái hiện tại của chuỗi công khai này, vẫn đ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 nhóm Slow Mist về sự kiện 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, bằng cách sử dụng vay chớp nhoáng, 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 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 sử dụng trượt giá tối đa để hoán đổi 100 tỷ haSUI thông qua vay chớp nhoáng, vay ra một lượng lớn tiề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ả vốn trong cùng một giao dịch, chỉ cần trả phí dịch vụ, có đặc điểm đò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á thị trường xuố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 phạm vi 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%.
Thông qua 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 điều khiển 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 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ỗi trong hàm checked_shlw, cuối cùng chỉ thu về 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 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 hình thức. Tin tặc 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 đó, do đó đã vượt qua kiểm tra tràn.
Dữ liệu tràn bị cắt: Khi thực hiện thao tác dịch chuyển n << 64 trên giá trị n, do sự dịch chuyển vượt quá độ rộng bit hiệu quả của kiểu dữ liệu uint256 (256 bit), đã xảy ra cắt dữ liệu. Phần tràn bít 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, làm cho hệ thống đánh giá thấp số lượng haSUI cần thiết để đổi. Kết quả tính toán cuối cùng khoảng nhỏ hơn 1, nhưng do làm tròn lên, cuối cùng được tính là 1, tức là hacker chỉ cần thêm 1 token, có thể đổi ra 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 pool thanh khoản.
Tình hình mất mát tài chính nghiêm trọng, cuộc tấn công đã dẫn đến việ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 Mỹ USDC
490 triệu USD Haedal Staked SUI
1950 triệu đô la TOILET
Các token khác như HIPPO và LOFI giảm 75--80%, thanh khoản cạn kiệt
2.2 Nguyên nhân và đặc điểm của lỗ hổng lần này
Lỗi của Cetus lần này có ba đặc điểm:
Chi phí sửa chữa rất thấp: Một mặt, nguyên nhân cơ bản của sự cố Cetus là một sơ suấ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ã 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 đổi hai dòng mã là có thể loại bỏ hoàn toàn rủi ro; sau khi sửa chữa xong có thể ngay lập tức triển khai lên mạng chính, đảm bảo logic hợp đồng sau này đầy đủ, ngăn chặn lỗ hổng đó.
Tính ẩn giấu cao: Hợp đồng đã hoạt động ổn định không có lỗi trong hai năm, Cetus Protocol đã thực hiện nhiều lần kiểm toán, nhưng không phát hiện ra lỗ hổng, lý do chủ yếu là do thư viện Integer_Mate dùng cho tính toán toán học không được bao gồm trong phạm vi kiểm toán.
Tin tặc sử dụng giá trị cực đoan để chính xác xây dựng khoảng giao dịch, tạo ra những tình huống rất hiếm hoi với tính thanh khoản cực cao, mới kích hoạt logic bất thường, cho thấy những vấn đề như vậy khó có thể được phát hiện thông qua 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 rất lâu mới đượ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 khác về an toàn 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. Sự 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, đã sử dụng sai giá trị để kiểm tra giới hạn tối đa, và đã thay thế phép toán nhân thông thường bằng phép toán 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, không xảy ra vấn đề cắt bớt bit cao như vậy.
Lỗi tương tự cũng đã xuất hiện trong các ngôn ngữ khác (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 quá khứ đã xảy ra tràn số khi cộng, tràn số khi trừ, tràn số khi nhân, nguyên nhân trực tiếp đều là do kết quả tính toán vượt quá giới hạn. Ví dụ, lỗi trong 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 sử dụng các tham số được cấu trúc cẩn thận, thực hiện tấn công chuyển tiền vượt mức.
3. Cơ chế đồng thuận của SUI
3.1 Giới thiệu về cơ chế đồng thuận SUI
Tổng quan:
SUI áp dụng khuôn khổ ủy thác chứng minh quyền lợi (DeleGated Proof of Stake, viết tắt là DPoS), mặc dù cơ chế DPoS có thể tăng lên khả năng 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 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, giúp họ có thể tham gia đồ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 quay 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, nâng cao tốc độ xác nhận và tăng lên TPS.
Bầu cử động: Sau mỗi chu kỳ kiểm phiếu, dựa trên trọng số phiếu bầu, thực hiện luân phiên động, tái bầu tập hợp Validator, đảm bảo sức sống của các nút, tính nhất quán lợi ích và 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ố 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 mứ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 tăng đồng thời chi phí và rủi ro của cuộc tấn công; 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 (tolerance Byzantine), yêu cầu hơn hai phần ba số phiếu của các xác thực viên phải đạt được sự đồng thuận để xác nhận giao dịch. Cơ chế này đảm bảo rằng ngay cả khi một số nút làm xấu, 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 sự phi tập trung và hiệu suất. DPoS trong "tam giác không thể" giữa an toàn - phi tập trung - khả năng mở rộng, chọn giảm số lượng nút tạo khối hoạt động để đổi lấy hiệu suất cao hơn, so với PoS thuần túy hoặc PoW đã từ bỏ một mức độ phi tập trung hoàn toàn nhưng nâng cao đáng kể khả năng thông qua mạng và tốc độ giao dịch.
3.2 SUI trong cuộc tấn công lần 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 các địa chỉ liên quan đến kẻ tấn công.
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, có trách nhiệm xác thực các giao dịch và thực hiện các quy tắc giao thức. Bằng cách đồng loạt bỏ qua 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 ở mức đồ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 đã tồn tại 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 rất khó để phối hợp tất cả các người xác thực phản hồi từng người một trong thời gian ngắn.
3.2.2 Ai có quyền thay đổi danh sách đen?
TransactionDenyConfig là tệp cấu hình YAML/TOML được tải cục bộ bởi mỗi trình xác thực. Bất kỳ ai chạy nút đều có thể chỉnh sửa tệp này, tải lại nóng hoặc khởi động lại nút và cập nhật danh sách. Nhìn bề ngoài, mỗi trình xác thực dường như đang tự do thể hiện 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ó phối hợp. 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 phát hành danh sách đen, lý thuyết thì các xác thực viên có thể lựa chọn có áp dụng nó hay không ------ nhưng thực tế thì 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 của giao thức tầng底, mà giống như một lớp bảo vệ an toàn bổ sung để đối 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. Giống như một "chuỗi chống trộm" buộc vào cửa, chỉ được kích hoạt đối với những người muốn xâm nhập vào nhà, tức là những người có ý định xấu đối với giao thức. Đối với người dùng:
Đối với 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à điều mà họ muốn đảm bảo tính an toàn cho vốn, bởi vì thực tế dữ liệu trên chuỗi tvl hoàn toàn là do các nhà đầu tư lớn đóng góp, để giao thức 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 ủng hộ mạnh mẽ trong việc xây dựng công nghệ và cộng đồng. Phía dự án cũng hy vọng có thể thu hút nhà đầu tư nhỏ lẻ tham gia xây dựng.
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.
13 thích
Phần thưởng
13
5
Chia sẻ
Bình luận
0/400
MEVHunterNoLoss
· 14giờ trước
Đợt hack này tôi không sợ cắt lỗ.
Xem bản gốcTrả lời0
gas_fee_trauma
· 14giờ trước
炒币亏完了就全在这
Trả lời0
faded_wojak.eth
· 14giờ trước
Thật không ngờ bạn còn dám nói về sự kiên cường, bị lột sạch luôn rồi.
Xem bản gốcTrả lời0
LiquidationKing
· 14giờ trước
sui không nhất định lạnh, nhưng thép thì cần phải cẩn thận một chút
SUI sinh thái độ bền vững thể hiện tiềm năng tăng lên lâu dài sau sự kiện an toàn
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 gây ra bởi một cuộc tấn công
Vào ngày 22 tháng 5 năm 2023, giao thức AMM hàng đầu triển khai trên mạng SUI là Cetus đã bị tấn công bởi hacker. Kẻ tấn công đã lợi dụng một lỗ hổng logic liên quan đến "vấn đề tràn số nguyên" để thực hiện các thao tác chính xác, dẫn đến thiệt hại vượt quá 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 của hacker tàn phá nhất kể từ khi mạng chính SUI ra mắt.
Theo dữ liệu từ DefiLlama, TVL toàn chuỗi SUI đã giảm mạnh hơn 330 triệu đô la 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%, giảm xuống còn 38 triệu đô la. Do ảnh hưởng liên quan, 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 làn sóng chấn động 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 những biến độ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 gặp phải sự suy giảm kéo dài, trái lại, đã thúc đẩy toàn bộ hệ sinh thái chú ý đáng kể đến an toàn, xây dựng cơ sở hạ tầng và chất lượng dự án.
Chúng tôi sẽ tập trung vào nguyên nhân của sự cố tấn công lần này, cơ chế đồng thuận của nút SUI, tính bảo mật của ngôn ngữ MOVE và sự phát triển của hệ sinh thái SUI, để tổng hợp cấu trúc sinh thái hiện tại của chuỗi công khai này, vẫn đ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 nhóm Slow Mist về sự kiện 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, bằng cách sử dụng vay chớp nhoáng, 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 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 sử dụng trượt giá tối đa để hoán đổi 100 tỷ haSUI thông qua vay chớp nhoáng, vay ra một lượng lớn tiề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ả vốn trong cùng một giao dịch, chỉ cần trả phí dịch vụ, có đặc điểm đò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á thị trường xuố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 phạm vi 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%.
Thông qua 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 điều khiển 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 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ỗi trong hàm checked_shlw, cuối cùng chỉ thu về 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 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 hình thức. Tin tặc 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 đó, do đó đã vượt qua kiểm tra tràn.
Dữ liệu tràn bị cắt: Khi thực hiện thao tác dịch chuyển n << 64 trên giá trị n, do sự dịch chuyển vượt quá độ rộng bit hiệu quả của kiểu dữ liệu uint256 (256 bit), đã xảy ra cắt dữ liệu. Phần tràn bít 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, làm cho hệ thống đánh giá thấp số lượng haSUI cần thiết để đổi. Kết quả tính toán cuối cùng khoảng nhỏ hơn 1, nhưng do làm tròn lên, cuối cùng được tính là 1, tức là hacker chỉ cần thêm 1 token, có thể đổi ra 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 pool thanh khoản.
Tình hình mất mát tài chính nghiêm trọng, cuộc tấn công đã dẫn đến việ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 Mỹ USDC
490 triệu USD Haedal Staked SUI
1950 triệu đô la TOILET
Các token khác như HIPPO và LOFI giảm 75--80%, thanh khoản cạn kiệt
2.2 Nguyên nhân và đặc điểm của lỗ hổng lần này
Lỗi của Cetus lần này có ba đặc điểm:
Chi phí sửa chữa rất thấp: Một mặt, nguyên nhân cơ bản của sự cố Cetus là một sơ suấ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ã 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 đổi hai dòng mã là có thể loại bỏ hoàn toàn rủi ro; sau khi sửa chữa xong có thể ngay lập tức triển khai lên mạng chính, đảm bảo logic hợp đồng sau này đầy đủ, ngăn chặn lỗ hổng đó.
Tính ẩn giấu cao: Hợp đồng đã hoạt động ổn định không có lỗi trong hai năm, Cetus Protocol đã thực hiện nhiều lần kiểm toán, nhưng không phát hiện ra lỗ hổng, lý do chủ yếu là do thư viện Integer_Mate dùng cho tính toán toán học không được bao gồm trong phạm vi kiểm toán.
Tin tặc sử dụng giá trị cực đoan để chính xác xây dựng khoảng giao dịch, tạo ra những tình huống rất hiếm hoi với tính thanh khoản cực cao, mới kích hoạt logic bất thường, cho thấy những vấn đề như vậy khó có thể được phát hiện thông qua 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 rất lâu 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 khác về an toàn 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. Sự 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, đã sử dụng sai giá trị để kiểm tra giới hạn tối đa, và đã thay thế phép toán nhân thông thường bằng phép toán 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, không xảy ra vấn đề cắt bớt bit cao như vậy.
Lỗi tương tự cũng đã xuất hiện trong các ngôn ngữ khác (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 quá khứ đã xảy ra tràn số khi cộng, tràn số khi trừ, tràn số khi nhân, nguyên nhân trực tiếp đều là do kết quả tính toán vượt quá giới hạn. Ví dụ, lỗi trong 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 sử dụng các tham số được cấu trúc cẩn thận, thực hiện tấn công chuyển tiền vượt mức.
3. Cơ chế đồng thuận của SUI
3.1 Giới thiệu về cơ chế đồng thuận SUI
Tổng quan:
SUI áp dụng khuôn khổ ủy thác chứng minh quyền lợi (DeleGated Proof of Stake, viết tắt là DPoS), mặc dù cơ chế DPoS có thể tăng lên khả năng 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 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, giúp họ có thể tham gia đồ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 quay 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, nâng cao tốc độ xác nhận và tăng lên TPS.
Bầu cử động: Sau mỗi chu kỳ kiểm phiếu, dựa trên trọng số phiếu bầu, thực hiện luân phiên động, tái bầu tập hợp Validator, đảm bảo sức sống của các nút, tính nhất quán lợi ích và 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ố 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 mứ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 tăng đồng thời chi phí và rủi ro của cuộc tấn công; 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 (tolerance Byzantine), yêu cầu hơn hai phần ba số phiếu của các xác thực viên phải đạt được sự đồng thuận để xác nhận giao dịch. Cơ chế này đảm bảo rằng ngay cả khi một số nút làm xấu, 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 sự phi tập trung và hiệu suất. DPoS trong "tam giác không thể" giữa an toàn - phi tập trung - khả năng mở rộng, chọn giảm số lượng nút tạo khối hoạt động để đổi lấy hiệu suất cao hơn, so với PoS thuần túy hoặc PoW đã từ bỏ một mức độ phi tập trung hoàn toàn nhưng nâng cao đáng kể khả năng thông qua mạng và tốc độ giao dịch.
3.2 SUI trong cuộc tấn công lần 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 các địa chỉ liên quan đến kẻ tấn công.
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, có trách nhiệm xác thực các giao dịch và thực hiện các quy tắc giao thức. Bằng cách đồng loạt bỏ qua 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 ở mức đồ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 đã tồn tại 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 rất khó để phối hợp tất cả các người xác thực phản hồi từng người một trong thời gian ngắn.
3.2.2 Ai có quyền thay đổi danh sách đen?
TransactionDenyConfig là tệp cấu hình YAML/TOML được tải cục bộ bởi mỗi trình xác thực. Bất kỳ ai chạy nút đều có thể chỉnh sửa tệp này, tải lại nóng hoặc khởi động lại nút và cập nhật danh sách. Nhìn bề ngoài, mỗi trình xác thực dường như đang tự do thể hiện 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ó phối hợp. 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 phát hành danh sách đen, lý thuyết thì các xác thực viên có thể lựa chọn có áp dụng nó hay không ------ nhưng thực tế thì 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 của giao thức tầng底, mà giống như một lớp bảo vệ an toàn bổ sung để đối 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. Giống như một "chuỗi chống trộm" buộc vào cửa, chỉ được kích hoạt đối với những người muốn xâm nhập vào nhà, tức là những người có ý định xấu đối với giao thức. Đối với người dùng:
Đối với 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à điều mà họ muốn đảm bảo tính an toàn cho vốn, bởi vì thực tế dữ liệu trên chuỗi tvl hoàn toàn là do các nhà đầu tư lớn đóng góp, để giao thức 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 ủng hộ mạnh mẽ trong việc xây dựng công nghệ và cộng đồng. Phía dự án cũng hy vọng có thể thu hút nhà đầu tư nhỏ lẻ tham gia xây dựng.