Kể từ tháng 8, sự phát triển của hệ sinh thái Sui đã rất nhanh chóng. Theo DefiLlama, Sui TVL đã vượt qua 1 tỷ đô la, tăng 200% trong hai tháng qua, và hiện nay khối lượng giao dịch của Cetus, một Dex được xây dựng trên Sui, vượt quá 160 triệu đô la mỗi ngày.

Vào ngày 9 tháng 10, USDC bản địa của Sui đã đi vào mainnet, điều này sẽ tiếp tục thu hút nhiều quỹ vào hệ sinh thái Sui. Là một thành viên quan trọng của Hệ sinh thái Move, Sui cam kết cung cấp dịch vụ giao dịch nhanh và an toàn cho nhiều kịch bản ứng dụng blockchain khác nhau.

Trong bài viết này, Beosin sẽ giúp bạn hiểu về những thách thức về bảo mật mà người dùng và nhà phát triển hệ sinh thái SUI đang đối mặt với nhiều năm kinh nghiệm kiểm tra bảo mật.

Bảo mật Hợp đồng

SUI sử dụng Move làm ngôn ngữ lập trình cho hợp đồng thông minh. Move được thiết kế để là một ngôn ngữ mã bytecode có thể thực thi với các thuật toán bảo mật tích hợp và trình xác minh mã bytecode, và sử dụng cuộc gọi tĩnh khi gọi các hợp đồng.

Thiết kế này cho phép Move giải quyết các lỗ hổng phổ biến trong hợp đồng thông minh, như tấn công reentrancy, tràn số nguyên, chi tiêu kép và các vấn đề tiềm năng của trình biên dịch, nhưng vẫn có thể xảy ra trường hợp nhà phát triển vô tình giới thiệu các lỗ hổng trong quá trình phát triển hợp đồng. Nhằm đáp ứng nhu cầu này, Beosin đã giới thiệu Move Lint vào năm 2023, một công cụ phát hiện tĩnh tự động hóa việc phát hiện các rủi ro bảo mật tiềm ẩn trong hợp đồng và xác định các lỗ hổng.

Ngoài các công cụ phát hiện, dưới đây là những vấn đề về bảo mật mà các nhà phát triển cần chú ý thêm trong quá trình phát triển hợp đồng Move để nâng cao bảo mật:

1) Tràn số nguyên

So với các ngôn ngữ hợp đồng thông minh khác, Move tự động kiểm tra vấn đề tràn bộ nhớ mặc định khi thực hiện các phép toán số nguyên, điều này có thể ngăn chặn một số lượng lớn vấn đề tràn bộ nhớ, nhưng vẫn có hai điểm cần chú ý:

Các phép toán bit trong ngôn ngữ Move không tự động thực hiện kiểm tra tràn số vì các phép toán bit về cơ bản là các phép toán cấp bit trên dữ liệu, hoạt động khác biệt so với các phép toán số nguyên.

Khi kiểm tra tràn tự động của Move có hiệu lực, việc thực thi hàm sẽ ném ra một ngoại lệ, nếu thiết kế không đúng cách, có thể làm cho dự án kinh doanh không thực hiện như mong đợi, gây ra các cuộc tấn công DoS.

2) Quyền hạn và kiểm soát truy cập

Việc truyền các đối tượng đặc quyền và các cuộc gọi chức năng đặc quyền cần được xác thực cẩn thận, vì những chức năng và đối tượng này liên quan đến bảo mật tài chính. Ngoài ra, cần kiểm tra loại đối tượng để xác định xem chúng có phải là đối tượng riêng tư hay chia sẻ. Nếu một đối tượng bị chuyển đổi sai từ đối tượng riêng tư sang đối tượng chia sẻ, người dùng không được ủy quyền có thể truy cập vào đối tượng, gây nguy cơ bảo mật tiềm tàng.

Nhà phát triển có thể sử dụng Move Prover để xác minh rằng chương trình đang thực thi một chính sách kiểm soát truy cập rõ ràng. Ví dụ, trong std::offer, chúng ta có thể thấy rằng hàm được chấm dứt khi người nhận không nằm trong danh sách trắng:

3) Vấn đề phụ thuộc thứ tự giao dịch

Sự phụ thuộc vào thứ tự giao dịch (TOD) đề cập đến việc hành vi của một hợp đồng có thể có kết quả khác nhau tùy thuộc vào thứ tự mà các giao dịch được thực hiện, đặc biệt là trong môi trường phi tập trung khi người đào hoặc người xác minh có thể chọn cách thức sắp xếp các giao dịch. Điều này có thể mang lại các rủi ro như tấn công front-running.

Ở SUI, vẫn là trách nhiệm của nhà sản xuất khối để thực hiện lệnh giao dịch, vì vậy hợp đồng MOVE vẫn có thể bị ảnh hưởng bởi vấn đề này nếu chúng được thiết kế để phụ thuộc vào thứ tự giao dịch để thay đổi trạng thái.

4) Vấn đề tiêu thụ gas

Trên chuỗi Sui, vấn đề Gas của các hợp đồng thông minh Move chủ yếu được phản ánh trong chi phí tính toán và lưu trữ cần thiết cho việc thực hiện hợp đồng. Với sự tăng của sự phức tạp và thay đổi trạng thái của hợp đồng, việc tiêu thụ Gas cũng tăng theo. Nhà phát triển cần tập trung vào việc tối ưu hóa logic hợp đồng, giảm các phép tính không cần thiết và cập nhật trạng thái để giảm chi phí giao dịch cho người dùng, và đặc biệt là tránh tình huống vòng lặp không kiểm soát trong hợp đồng, có thể do gas không đủ và không thể thực hiện kinh doanh một cách đúng đắn.

5) Độ chính xác của phép tính

Hiện tại, loại số học được hỗ trợ bởi Move là số nguyên không dấu, không hỗ trợ số thập phân, vì vậy phần thập phân sẽ bị cắt bỏ và làm tròn xuống trong quá trình phép chia, điều này sẽ dẫn đến kết quả tính toán không chính xác, có thể ảnh hưởng đến một số chính sách quan trọng, dẫn đến mất doanh thu, và thậm chí trở thành một lỗ hổng bảo mật.

Đối với vấn đề này, biện pháp giảm nhẹ thông thường là mở rộng độ chính xác, nhưng cần lưu ý rằng độ chính xác cần được khôi phục khi kết quả cuối cùng được đạt được.

6) Quản lý đối tượng

Trong các hợp đồng thông minh trên chuỗi khối Sui, quản lý đối tượng là một thách thức quan trọng, bao gồm nhiều khía cạnh của vòng đời của đối tượng, quyền sở hữu, truy cập đồng thời, chuỗi hóa và chi phí lưu trữ. Nhà phát triển cần quản lý chính xác việc tạo, cập nhật và phá hủy các đối tượng để ngăn lãng phí tài nguyên và không nhất quán về trạng thái. Đồng thời, thiết kế hợp lý của logic hợp đồng để kiểm soát quyền sở hữu và quyền truy cập của các đối tượng, cũng như xử lý nhiều người dùng truy cập cùng một đối tượng đồng thời, là những yếu tố quan trọng để đảm bảo hoạt động an toàn và hiệu quả của các hợp đồng thông minh.

7) Vấn đề thiết kế và triển khai logic kinh doanh

Ví dụ, với việc triển khai vay sét trong dự án Sui DeFi, kẻ tấn công có thể sử dụng vay flash để thực hiện các cuộc tấn công quỹ lớn như làm thay đổi giá.

Trong tính năng trao đổi token AMM phổ biến, nhà phát triển có thể sử dụng Move Prover để xác minh rằng số lượng token đã thay đổi đúng cách:

Ví dụ, các giao thức cho vay luôn phải được đảm bảo đầy đủ sau một chuỗi các khoản tiền gửi, vay và rút tiền. Trong trường hợp sổ sách đặt hàng của thỏa thuận giao dịch hợp đồng vĩnh viễn trên chuỗi bị hủy sau khi đặt hàng, không được có bất kỳ thay đổi nào trên sổ cái, v.v., điều này cần được kiểm tra và xác minh bởi nhà phát triển.

Thách thức trong Hệ sinh thái Sui

Hiện tại, DeFi và Memecoins của SUI đang nở rộ, và khối lượng giao dịch và TVL đã thu hút sự tăng trưởng nổ. Sau đó, có ngày càng nhiều loại lừa đảo và giao dịch rác mà người dùng cần tránh.

Phishings

Năm nay, một loại lừa đảo airdrop có tên Suisses xuất hiện trên Sui Eco, cho phép nhiều người dùng bị đánh cắp tài sản của họ. Khi người dùng kết nối với ví trên trang web Suisses và nhấp vào Claim, một yêu cầu giao dịch để chuyển tài sản của người dùng xuất hiện. Nếu người dùng ký kết giao dịch, họ sẽ phát hiện rằng toàn bộ tài sản trong ví của họ đã được chuyển đi.

Do vì các đặc tính của SUI: mọi thứ đều là đối tượng, không chỉ là token trong ví người dùng, NFT cũng là đối tượng, cũng như việc người dùng tham gia đào DeFi, cam kết thanh khoản và các chứng chỉ khác. Nếu xảy ra cuộc tấn công lừa đảo, tất cả tài sản của người dùng trong hệ sinh thái SUI có thể bị hacker chuyển giao ngay lập tức.

Lừa đảo Token

Có nhiều token giả mạo và honeypot trong hệ sinh thái Sui. Đặc biệt, khi người dùng giao dịch memecoins trong Hệ sinh thái Sui, họ có thể bị bắt lừa một cách tình cờ.

Trong việc tạo token tại Sui, như được hiển thị dưới đây, hacker có thể xác định cùng các biểu tượng và tên giống như các token phổ biến hoặc chính thức, khiến chúng trở nên không thể phân biệt được đối với người dùng thông thường. Do đó, người dùng cần kiểm tra xem định dạng dữ liệu của token có đúng khi mua token.

Ngoài ra, hacker có thể thêm chức năng Danh sách Tủy chỉnh vào hợp đồng token, để người dùng mua token không thể bán, gây thiếu lớt cho người dùng.

Thách thức MEV

MEV là viết tắt của giá trị có thể tối đa khai thác. MEV ban đầu được đề cập đến Giá trị Có Thể Khai Thác bởi các máy đào, trong đó các máy đào trên mạng BTC kiếm phần thưởng vượt ra ngoài phí giao dịch và mạng bằng cách sắp xếp lại các giao dịch trong các khối. MEV không liên quan gì đến loại mạng blockchain. MEV tồn tại trong tất cả các blockchain, và Sui cũng không phải là ngoại lệ.

Sui sử dụng Narwhal như một bể nhớ để gán các giao dịch chưa hoàn thành cho các nút, và sử dụng thuật toán Bullshark như một động cơ đồng thuận để sắp xếp các giao dịch.

Quy tắc đặt hàng của Sui cho giao dịch dựa trên phí gas. Ngoài ra, vì Sui áp dụng một mô hình thực hiện giao dịch kết hợp song song và tuần tự, các giao dịch chia sẻ trạng thái hồ bơi giao dịch AMM cùng có thể chỉ được thực hiện theo thứ tự. Do đó, cuộc tấn công sandwich / giao dịch frontrunning là khả thi. Kẻ tấn công có thể tiến hành cuộc tấn công sandwich thông qua phí gas cao hơn, để người dùng tham gia giao dịch DeFi phải chịu thiệt hại.

Miễn trừ trách nhiệm:

1. Bài viết này được sao chép từ [ beosin]. Tất cả bản quyền thuộc về tác giả gốc [beosin]. Nếu có ý kiến ​​phản đối về việc tái bản này, vui lòng liên hệ Cổng Họcđội, và họ sẽ xử lý nhanh chóng.
2. Miễn trách nhiệm về trách nhiệm: Quan điểm và ý kiến được thể hiện trong bài viết này chỉ là của tác giả và không tạo thành bất kỳ lời khuyên đầu tư nào.
3. Các bản dịch của bài viết sang các ngôn ngữ khác được thực hiện bởi nhóm học viên của gate. Trừ khi được đề cập, việc sao chép, phân phối hoặc đạo văn bản dịch là không được phép.