Xu hướng
Khám phá các bài đăng thịnh hành nhất.
Bài viết
679AMM Bot trong hệ sinh thái Sui
Các tính năng và chức năng chính của bot AMM trong hệ sinh thái Sui là gì? Làm thế nào để họ cải thiện các cơ chế giao dịch truyền thống và chúng mang lại những lợi thế nào cho người dùng tham gia với các giao thức DeFi trên mạng Sui? Tôi có cần xây dựng một cái hay tôi có thể sử dụng Turbos Finance chẳng hạn
- Sui
82Câu trả lời hay nhất- Bài Viết0xduckmove618Dành choSuiApr 08, 2025
👀 SEAL- Tôi nghĩ quyền riêng tư dữ liệu Web3 sắp thay đổi
👀 SEAL đang phát trực tiếp trên Sui Testnet - Tôi nghĩ quyền riêng tư dữ liệu Web3 sắp thay đổi Trong Web3, người ta thường nghe các cụm từ như* “người dùng sở hữu dữ liệu của họ”* hoặc* “phi tập trung theo thiết kế”*. Nhưng khi bạn nhìn kỹ, nhiều ứng dụng vẫn dựa vào cơ sở hạ tầng tập trung để xử lý dữ liệu nhạy cảm - sử dụng các dịch vụ như AWS hoặc Google Cloud để quản lý khóa. Điều này dẫn đến một mâu thuẫn: phân cấp trên bề mặt, tập trung hóa bên dưới. Nhưng điều gì sẽ xảy ra nếu có một cách để quản lý bí mật một cách an toàn, mà không từ bỏ sự phân cấp? Giới thiệu SEAL — Quản lý bí mật phi tập trung (DSM), hiện đang hoạt động trên Sui Testnet. SEAL nhằm mục đích khắc phục một trong những đạo đức giả lớn nhất của Web3: hét lên phân quyền trong khi bí mật sử dụng AWS Bạn có thể hỏi tôi: SEAL là gì? SEAL là một giao thức cho phép bạn quản lý dữ liệu nhạy cảm một cách an toàn và** phi tập trung - được xây dựng đặc biệt cho thế giới Web3. Hãy nghĩ về nó như một lớp kiểm soát truy cập đầu tiên về quyền riêng tư được cắm vào DApp của bạn. Bạn có thể nghĩ về SEAL như một loại khóa lập trình cho dữ liệu của bạn. Bạn không chỉ khóa và mở khóa mọi thứ theo cách thủ công - bạnviết chính sách trực tiếp vào hợp đồng thông minhcủa mình**, sử dụng Move on Sui. Giả sử bạn đang xây dựng một DApp trong đó: Chỉ những người nắm giữ NFT mới có thể mở khóa hướng dẫn cao cấp Hoặc có thể DAO phải bỏ phiếu trước khi các tệp nhạy cảm được tiết lộ Hoặc bạn muốn siêu dữ liệu bị khóa thời gian và chỉ có thể truy cập sau một ngày cụ thể SEAL làm cho tất cả điều đó trở nên khả thi. Kiểm soát truy cập hoạt động * onchain*, hoàn toàn tự động, không cần quản trị viên để quản lý nó. Chỉ là logic, được nung ngay vào blockchain. SEAL làm cho tất cả điều đó trở nên khả thi. Kiểm soát truy cập hoạt động * onchain*, hoàn toàn tự động, không cần quản trị viên để quản lý nó. Chỉ là logic, được nung ngay vào blockchain. Một phần thú vị khác là cách SEAL xử lý* mã hóa. Nó sử dụng một cái gì đó được gọi là* mã hóa ngưỡng**, có nghĩa là: không một nút nào có thể giải mã dữ liệu. Cần một nhóm các máy chủ để làm việc cùng nhau - giống như multi-sig, nhưng để mở khóa bí mật. Điều này phân phối niềm tin và tránh được vấn đề một điểm thất bại thông thường. Và để giữ mọi thứ thực sự riêng tư, SEAL mã hóa và giải mã mọi thứ* ở phía máy khác*. Dữ liệu của bạn không bao giờ hiển thị cho bất kỳ phụ trợ nào. Nó nằm trong tay bạn - theo nghĩa đen - trên thiết bị của bạn. và SEAL không quan tâm bạn lưu trữ dữ liệu của mình ở đâu. Cho dù đó là IPFS, Arweave, Walrus hay một số nền tảng khác, SEAL không cố gắng kiểm soát phần đó. Nó chỉ tập trung vàoai được phép xem cái gì, chứ không phải * ở đây* mọi thứ được lưu trữ. Vì vậy, vâng, nó không chỉ là một thư viện hoặc API - nó là một lớponchain-first, được kiểm soát truy cập, bảo mật theo mặc địnhcho DApp của bạn. SEAL lấp đầy một khoảng trống khá quan trọng. Hãy chia nhỏ nó hơn một chút. Nếu bạn đang xây dựng DApp xử lý**bất kỳ dạng dữ liệu nhạy cảm nào - nội dung được kiểm soát, tài liệu người dùng, tin nhắn được mã hóa, thậm chí cả siêu dữ liệu NFT bị khóa theo thời gian - bạn sẽ gặp phải vấn đề tương tự: ➡️ Làm thế nào để bạn quản lý quyền truy cập một cách an toàn mà không cần dựa vào dịch vụ tập trung? Nếu không có một cái gì đó như SEAL, hầu hết các đội đều: Sử dụng các công cụ tập trung như AWS KMS hoặc Firebase, điều này rõ ràng đi ngược lại sự phân quyền Hoặc cố gắng tự vá các logic mã hóa nửa chừng lại với nhau, điều này thường trở nên dễ vỡ và khó kiểm tra https://x.com/EmanAbio/status/1908240279720841425?ref_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E1908240279720841425%7Ctwgr%5E697f93dc65359d0c8c7d64ddede66c0c4adeadf1%7Ctwcon%5Es1_&ref_url=https%3A%2F%2Fwww.notion.so%2Fharryph%2FSEAL-Launches-on-Sui-Testnet-1cc4f8e09bb380969c0dcc627b96cc22 Cả hai đều không cân bằng tốt. Đặc biệt là không phải khi bạn đang cố gắng xây dựng các ứng dụng không đáng tin cậy trên nhiều chuỗi hoặc cộng đồng. SEAL làm cho toàn bộ quá trình đó trở nên mô-đun và có thể lập trình được. Bạn xác định quy tắc truy cập của mình trong hợp đồng thông minh Move và SEAL xử lý phần còn lại - tạo khóa, phê duyệt giải mã và thực thi truy cập - tất cả mà không cần bất kỳ ai cấp khóa theo cách thủ công hoặc chạy kiểm tra phụ trợ. Thậm chí tốt hơn, những quy tắc đó có thể kiểm tra và không thể thay đổi**- một khi chúng được kết nối, họ tuân theo hợp đồng, không phải là quản trị viên con người. Vì vậy, thay vì hỏi “ai nên quản lý quyền truy cập vào dữ liệu này?” bạn chỉ cần hỏi: “Logic nào nên xác định quyền truy cập?” > ... và để dây xích xử lý nó. Sạch sẽ và có thể mở rộng. Đó là những gì làm cho SEAL phù hợp với nhiều hơn là “công cụ bảo mật” - nó là lớp cơ sở cho bất kỳ DApp nào quan tâm đến quyền riêng tư, tuân thủ hoặc logic truy cập động.** Đó là một sự thay đổi nhỏ - nhưng nó thay đổi rất nhiều về cách chúng ta nghĩ về dữ liệu trong Web3. Thay vì mã hóasau triển khai hoặc dựa vào các dịch vụ bên ngoài,* bạn bắt đầu với quyền riêng tư tích hợp sẵn - và quyền truy cập được xử lý hoàn toàn bằng logic hợp đồng thông minh.* Và đó chính xác là những gì Web3 cần ngay bây giờ. SEAL thực sự hoạt động như thế nào? Chúng tôi đã đề cập đếnSEAL là gìvà* tại sao Web3 cần nó*, hãy xem nó thực sự được xây dựng như thế nào dưới mui xe. Phần này là nơi mọi thứ trở nên kỹ thuật hơn - nhưng theo một cách tốt. Kiến trúc thanh lịch khi bạn thấy tất cả các mảnh khớp với nhau như thế nào. Ở cấp độ cao, SEAL hoạt động bằng cách kết hợplogic truy cập onchainvớiquản lý khóa offchain, sử dụng một kỹ thuật gọi làMã hóa dựa trên danh tính (IBE). Điều này cho phép các nhà phát triển mã hóa dữ liệu * thành một danh tính, và sau đó dựa vào hợp đồng thông minh để xác định *ai được phép giải mã dữ liệu đó. Bước 1: Quy tắc truy cập trong Hợp đồng thông minh (trên Sui) Mọi thứ bắt đầu với hợp đồng thông minh. Khi bạn đang sử dụng SEAL, bạn xác định một hàm gọi là seal_trong hợp đồng Move của bạn - đây là nơi bạn viết các điều kiện để giải mã. Ví dụ: đây là một quy tắc khóa thời gian đơn giản được viết trong Move: entry fun seal_approve(id: vector, c: &clock::Clock) { let mut prepared: BCS = bcs::new(id); let t = prepared.peel_u64(); let leftovers = prepared.into_remainder_bytes(); assert!((leftovers.length() == 0) && (c.timestamp_ms() >= t), ENoAccess); } Sau khi được triển khai, hợp đồng này hoạt động như người gác cổng. Bất cứ khi nào ai đó muốn giải mã dữ liệu, yêu cầu của họ sẽ được kiểm tra dựa trên logic này. Nếu nó đi qua, chìa khóa sẽ được giải phóng. Nếu không, chúng bị chặn. Không ai phải can thiệp. ##Bước 2: Mã hóa dựa trên danh tính (IBE) Đây là nơi phép thuật xảy ra. Thay vì mã hóa dữ liệu cho một địa chỉ ví cụ thể (như với PGP hoặc RSA), SEAL sử dụng* chuỗi danh tính*- nghĩa là bạn mã hóa thành một cái gì đó như: Địa chỉ 0xwalletaddress dao_bỏ phiếu: proposal_xyz PKGID_2025_05_01 (quy tắc dựa trên dấu thời gian) hoặc thậm chí game_user_nft_holder Khi dữ liệu được mã hóa, nó trông như thế này: Encrypt(mpk, identity, message) mpk = khóa công khai chính (mọi người đều biết đến) danh tính = người nhận được xác định logic tin nhắn = dữ liệu thực tế Sau đó, nếu ai đó muốn giải mã, máy chủ khóa sẽ kiểm tra xem họ có khớp với chính sách hay không (thông qua cuộc gọi seal_approbe onchain). Nếu nó được chấp thuận, nó sẽ trả về khóa riêng có nguồn gốc cho danh tính đó. Derive(msk, identity) → sk Decrypt(sk, encrypted_data) Người dùng sau đó có thể giải mã nội dung cục bộ. Vì vậy, mã hóa được thực hiện mà không cần phải biết ai sẽ giải mã trước thời hạn. Bạn chỉ cần xác định các điều kiện* và SEAL sẽ tìm ra phần còn lại sau. Nó năng động. ##Bước 3: Máy chủ chìa khóa - Offchain, nhưng không tập trung hóa Bạn có thể tự hỏi: ai đang giữ các phím chính này? Đây là nơi* Máy chủ chínhcủa SEAL*xuất hiện. Hãy nghĩ về nó như một backend mà: Giữ khóa bí mật chính (msk) Xem các hợp đồng trên chuỗi (như logic seal_approbe của bạn) Chỉ phát hành các khóa có nguồn gốc nếu các điều kiện được thỏa mãn Nhưng - và đây là chìa khóa - SEAL không chỉ dựa vào * một* máy chủ chìa khóa. Bạn có thể chạy nó ở chế độ người**, trong đó nhiều máy chủ độc lập cần phải đồng ý trước khi khóa giải mã được phát hành. Ví dụ: 3 trong 5 máy chủ chìa khóa phải chấp thuận yêu cầu. Điều này tránh các điểm thất bại trung tâm và cho phép phân cấp ở tầng quản lý chính. Thậm chí tốt hơn, trong tương lai SEAL sẽ hỗ trợMPC (tính toán đa bên) vàthiết lập dựa trên enclave(như TEE) - vì vậy bạn có thể nhận được sự đảm bảo mạnh mẽ hơn mà không ảnh hưởng đến khả năng sử dụng. ##Bước 4: Giải mã phía máy khác Khi khóa được trả lại cho người dùng, quá trình giải mã thực tế sẽ xảy ratrên thiết bị của họ. Điều này có nghĩa là: Máy chủ không bao giờ nhìn thấy dữ liệu của bạn Phần phụ trợ không bao giờ lưu trữ nội dung được giải mã Chỉ người dùng mới có thể truy cập tin nhắn cuối cùng Đó là một mô hình riêng tư vững chắc. Ngay cả khi ai đó xâm phạm lớp lưu trữ (IPFS, Arweave, v.v.), họ vẫn không thể đọc dữ liệu mà không truyền logic truy cập. Đây là mô hình tinh thần nhanh chóng: Cấu trúc này giúp dễ dàng xây dựng DApps nơi các quy tắc truy cập không được mã hóa cứng - chúng động, có thể kiểm tra và được tích hợp đầy đủ vào logic chuỗi của bạn. ##* Đội ngũ đằng sau SEAL* SEAL được dẫn dắt bởi* Samczsun*, một nhân vật nổi tiếng trong cộng đồng bảo mật blockchain. Trước đây là Đối tác Nghiên cứu tại Paradigm, ông đã kiểm toán và cứu nhiều hệ sinh thái khỏi những khai thác lớn. Giờ đây, anh ấy tập trung toàn thời gian vào việc xây dựng SEAL thành một phần cốt lõi của cơ sở hạ tầng quyền riêng tư của Web3. Với nền tảng và uy tín của mình, SEAL không chỉ là một công cụ thử nghiệm khác - đó là một nỗ lực nghiêm túc trong việc làm cho quyền riêng tư dữ liệu phi tập trung trở nên thiết thực và có thể mở rộng. Khi SEAL được phát hành trên Sui Testnet, nó mang đến một tiêu chuẩn mới về cách các ứng dụng Web3 có thể quản lý bí mật. Bằng cách kết hợp kiểm soát truy cập onchain, mã hóa ngưỡng và quyền riêng tư phía máy khách, SEAL cung cấp một nền tảng đáng tin cậy hơn cho việc xử lý dữ liệu phi tập trung. Cho dù bạn đang xây dựng DApps, DAO hay trò chơi phi tập trung - SEAL cung cấp một bộ công cụ mạnh mẽ để thực thi kiểm soát truy cập và bảo vệ dữ liệu người dùng mà không ảnh hưởng đến phân quyền. Nếu Web3 sẽ tiến về phía trước, cơ sở hạ tầng an toàn như SEAL không phải là tùy chọn - đó là điều cần thiết
- Sui
- Architecture
- SDKs and Developer Tools
8 Có phải cách duy nhất để xuất bản gói Move thông qua EOA không?
Tôi cho rằng không có cách nào trên chuỗi Sui vì không có mô-đun nào trên chuỗi xuất bản các gói.
- Sui
- SDKs and Developer Tools
- Move
73Câu trả lời hay nhất
Làm thế nào để Sui ngăn chặn các vụ hack hợp đồng thông minh?
Các vụ hack hợp đồng thông minh đã gây khó khăn cho ngành công nghiệp blockchain, với hơn 3 tỷ đô la bị mất chỉ trong năm 2023 do khai thác trên các nền tảng như Ethereum. Sui Network, được thiết kế với bảo mật là ưu tiên, giới thiệu một số cải tiến quan trọng để giảm thiểu những rủi ro này. Bài viết này khám phá: 🔒 Các tính năng bảo mật tích hợp của Sui 💡 Ngôn ngữ Move ngăn chặn các khai thác phổ biến như thế nào 🛡️ So sánh với các lỗ hổng của Ethereum 🚀 Tại sao Sui có thể trở thành nền tảng hợp đồng thông minh an toàn nhất 1. Ngôn ngữ lập trình Move: Cách tiếp cận bảo mật ưu tiên Sui sử dụng Move, một ngôn ngữ ban đầu được phát triển cho blockchain Diem của Facebook, được thiết kế đặc biệt để quản lý tài sản an toàn. Lợi ích bảo mật chính của Move: Không có cuộc gọi bên ngoài chưa được kiểm tra - Ngăn chặn các cuộc tấn công tái nhập (như hack DAO trị giá 60 triệu đô la trên Ethereum). Quy tắc đánh máy & sở hữu mạnh mẽ - Loại bỏ tình trạng mất tiền do lỗi mã hóa. Hỗ trợ xác minh chính thức - Cho phép chứng minh toán học về tính chính xác của hợp đồng. Ví dụ: Trong Ethereum, một lỗi đánh máy đơn giản có thể làm cạn kiệt tiền. Trong Move, trình biên dịch từ chối mã không an toàn trước khi triển khai. 2. Mô hình lấy đối tượng làm trung tâm: Cách ly lỗ hổng Không giống như mô hình trạng thái chia sẻ của Ethereum (trong đó một lỗi có thể ảnh hưởng đến nhiều hợp đồng), lưu trữ dựa trên đối tượng của Sui giới hạn việc lan truyền khai thác: Mỗi tài sản (coin, NFT, v.v.) là một đối tượng riêng biệt với các quy tắc sở hữu nghiêm ngặt. Hợp đồng không thể tùy ý sửa đổi dữ liệu không liên quan. Tác động: Ngay cả khi một hợp đồng bị xâm phạm, thiệt hại vẫn được kiềm chế, không giống như rủi ro về khả năng cấu thành của Ethereum (ví dụ: vụ hack cầu Wormhole trị giá 325 triệu đô la). 3. Không có cuộc tấn công “Gas Griefing” Trên Ethereum, kẻ tấn công có thể spam các hợp đồng với các giao dịch gas cao để chặn người dùng hợp pháp (ví dụ: tấn công từ chối dịch vụ). Giải pháp của Sui: Các giao dịch chi phí thấp cố định (không đấu giá gas). Thực thi song song ngăn chặn tắc nghẽn trên toàn mạng. 4. Giám sát bảo mật trên chuỗi Người xác nhận của Sui chủ động theo dõi các hoạt động đáng ngờ: Kiểm tra trước giao dịch - Từ chối các yêu cầu rõ ràng là độc hại. Phân tích thời gian thực - Đánh dấu hành vi bất thường (ví dụ: rút tiền lớn đột ngột). 5. Hồ sơ an toàn trong thế giới thực (Cho đến nay) Sui đã không có vụ hack lớn kể từ khi ra mắt mainnet (2023). Ethereum trung bình 2-3 lần khai thác DeFi lớn hàng tháng. Nghiên cứu điển hình: Một DEX dựa trên SUI (Cetus) đã xử lý các giao dịch trị giá hơn 1 tỷ đô la mà không có sự cố bảo mật - không giống như Ethereum DEX, thường bị khai thác. 6. Bảo vệ tương lai: Xác minh và kiểm toán chính thức Sui khuyến khích: Xác minh chính thức - Chứng minh toán học các hợp đồng không có lỗi. Yêu cầu đa kiểm toán - Các dự án lớn phải vượt qua 3+ cuộc kiểm toán. Kết luận: Sui có phải là nền tảng hợp đồng thông minh an toàn nhất không? Mặc dù không có hệ thống nào có khả năng chống hack 100%, ngôn ngữ Move + mô hình đối tượng + thực thi song song của Sui khiến nó ít dễ bị tổn thương hơn nhiều so với Ethereum ngày nay. Điểm mấu chốt: Đối với các nhà phát triển - Move giảm rủi ro lỗi của con người. Dành cho người dùng - Giảm khả năng mất tiền do khai thác. Đối với các tổ chức - Bảo mật cấp doanh nghiệp xây dựng lòng tin. **Tiếp theo là gì? Liệu Ethereum có áp dụng các tính năng giống như Move-like không? Liệu Sui có thể duy trì hồ sơ an ninh sạch sẽ của mình khi việc nhận con nuôi ngày càng tăng?** Chia sẻ suy nghĩ của bạn bên đây
- Sui
6- Bài Viếtharry phan595Dành choSuiApr 24, 2025
Quản lý con đa mô-đun với public_receiver
Đây là phần 3 của loạt phim “Đối tượng cha mẹ-con trong Sui Move”. Đôi khi loại cha mẹ và con của bạn được xác định trong các mô-đun khác nhau hoặc thậm chí các gói khác nhau. Ví dụ: bạn có thể có một đối tượng Warehouse chung có thể lưu trữ bất kỳ loại đối tượng Parcel nào. Mô-đun Warehouse muốn rút ra một con Parcel, nhưng loại Parcel được định nghĩa ở nơi khác. Trong những trường hợp như vậy, chúng tôi sử dụng transfer: :public_receiver, là người anh em họ chênh lệch mô-đun của receiver. ###* nhận so với public_receive* Như chúng ta đã thấy, transfer:: receiver chỉ có thể được gọi trong mô-đun định nghĩa T (hoặc một người bạn) vì nó không yêu cầu T: store. Trình xác minh Move bytecode thực sự đảm bảo rằng trong bất kỳ cuộc gọi nào để nhận, loại T là từ mô-đun hiện tại. Đây là một hạn chế an toàn đối với các đối tượng chỉ có khóa. transfer: :public_receiver là một biến thể mà yêu cầu T: key + lưu trữ nhưng cho phép nhận bên ngoài mô-đun của T. Nói cách khác, nếu kiểu đối tượng có khả năng lưu trữ (nghĩa là nó được phép tồn tại trong bộ lưu trữ toàn cầu một cách tự do), thì bất kỳ mô-đun nào (được cho UID & mut của cha mẹ) đều có thể nhận nó bằng cách sử dụng public_receiver. Điều này hoàn hảo cho các trường hợp mô-đun của phụ huynh khác với mô-đun của trẻ em. Tại sao yêu cầu cửa hàng? Bởi vì cửa hàng đánh dấu rằng đối tượng có thể được duy trì một cách an toàn và chuyển xung quanh bên ngoài mô-đun xác định của nó. Các đối tượng chỉ có khóa có thể có bất biến tùy chỉnh mà mô-đun ban đầu muốn thực thi khi chuyển nhận/nhận; bằng cách loại trừ những đối tượng đó khỏi public_receiver, Sui buộc các nhà phát triển xử lý chúng trong mô-đun (như chúng ta sẽ thấy với các đối tượng bị ràng buộc linh hồn). Nếu một đối tượng có kho, nó dễ cho phép hơn và Sui cho phép logic chuyển nhận/nhận chung để quản lý nó bên ngoài. ###Ví dụ: Các mô-đun phụ huynh và con riêng biệt Hãy minh họa bằng một kịch bản đơn giản: Kho lưu trữ các đối tượng Parcel. Loại Bưu kiện được xác định trong mô-đun riêng của nó và Kho trong một mô-đun khác. Chúng tôi sẽ chỉ ra cách Warehouse có thể nhận được một Parcel con bằng cách sử dụng public_receiver. module demo::parcel { // Child module use sui::object::{Self, UID}; use sui::tx_context::{Self, TxContext}; /// A parcel object that can be stored in a Warehouse. /// It has both key and store, so it can be transferred across modules. struct Parcel has key, store { id: UID, contents: vector } public entry fun create_parcel(contents: vector, ctx: &mut TxContext): Parcel { Parcel { id: object::new(ctx), contents } } } module demo::warehouse { // Parent module use sui::transfer::{Self, Receiving, public_receive}; use demo::parcel::{Self, Parcel}; use sui::object::{UID}; use sui::tx_context::{Self, TxContext}; struct Warehouse has key { id: UID, location: address } public entry fun create_warehouse(location: address, ctx: &mut TxContext): Warehouse { Warehouse { id: object::new(ctx), location } } /// Receive a Parcel that was sent to this Warehouse. /// Returns the Parcel to the caller (transferred to caller's address). public entry fun withdraw_parcel( warehouse: &mut Warehouse, parcel_ticket: Receiving, ctx: &mut TxContext ): Parcel { // Using public_receive because Parcel is defined in another module and has store let parcel = public_receive(&mut warehouse.id, parcel_ticket) oai_citation_attribution:27‡docs.sui.io oai_citation_attribution:28‡github.com; // Transfer the parcel to the transaction sender (so the caller gets ownership) transfer::transfer(parcel, tx_context::sender(ctx)); // We return nothing because we've transferred the Parcel out to the caller. } } Hãy chia nhỏ những gì đang xảy ra trong _parcel: Chúng tôi gọi public_receiver (& mut warehouse.id, parcel_ticket). Bởi vì Parcel có khả năng lưu trữ, cuộc gọi này được cho phép mặc dù chúng tôi không ở trong mô-đun bưu kiện. Dưới mui xe, tính năng này thực hiện kiểm tra và trích xuất tương tự như nhận, nhưng nó được phép chênh lệch mô-đun vì cửa hàng cho biết nó an toàn để làm như vậy. https://github.com/MystenLabs/sui/blob/main/crates/sui-framework/packages/sui-framework/sources/transfer.move#:~:text=public%20fun%20public_receive,T%3E%29%3A%20T Sau đó chúng tôi ngay lập tức chuyển Bưu kiện nhận được đến địa chỉ của người gọi (tx_context: :send (ctx)). Bước này đảm bảo bưu kiện rời khỏi kho và chuyển đến người dùng đã bắt đầu rút tiền. Chúng ta cũng có thể vừa trả lại Parcel từ hàm và Sui sẽ coi nó như một đầu ra thuộc sở hữu của địa chỉ người gọi (vì đó là đầu ra của hàm nhập). Thực hiện chuyển giao rõ ràng sẽ nhiều chi tiết hơn, nhưng làm rõ điều gì đang xảy ra (và cho phép chúng tôi thực hiện bất kỳ kiểm tra nào trước khi giải phóng đối tượng). Tại sao phải bao gồm cửa hàng trong Bưu kiện? Nếu Parcel thiếu khả năng lưu trữ (tức là chỉ có khóa), lệnh gọi public_receiver trong demo: :warehouse sẽ không biên dịch - Sui thực thi rằng T có kho lưu trữ cho public_receiver. Trong trường hợp đó, chúng tôi sẽ buộc phải lấy bưu kiện bằng cách sử dụng nhận trong chính mô-đun bưu kiện (hoặc sử dụng một số mối quan hệ bạn bè), điều này làm phức tạp thiết kế đa mô-đun. Bằng cách thêm cửa hàng vào Parcel, chúng tôi nói một cách hiệu quả “đối tượng này có thể được di chuyển và nhận tự do bởi các mô-đun bên ngoài”, đó là những gì chúng tôi muốn cho một mẫu container chung. Mẫu gọi hàm: Để sử dụng những thứ này trong giao dịch, luồng sẽ là: 1.Đặt cọc (chuyển sang đối tượng) :Gọi chuyển: :public_transfer (parcel_obj, @warehouse_id) để gửi Bưu kiện vào Kho. Điều này đánh dấu chủ sở hữu của bưu kiện là nhà kho. (Chúng tôi sử dụng public_transfer ở đây vì nó nằm bên ngoài mô-đun Parcel và Parcel có cửa hàng. Bên trong mô-đun của bưu kiện, việc chuyển tiền đơn giản cũng sẽ hoạt động.) Rút tiền (nhận lại) :Sau đó, gọi _parcel (warehouse_obj, Receiving (parcel_id,...)). Bộ nhận có thể được SDK lấy bằng cách tham khảo ID của bưu kiện và phiên bản mới nhất. Hàm sẽ gọi public_receiver và sau đó chuyển bưu kiện cho bạn. Sau cuộc gọi _parcel, chủ sở hữu của bưu kiện quay trở lại một địa chỉ (của bạn), vì vậy nó lại là một đối tượng thuộc sở hữu địa chỉ bình thường. Nhà kho không còn sở hữu nó nữa. Cân nhắc giữa các mô-đun: Lưu ý rằng mô-đun Warehouse cần biết về loại Bưu kiện (chúng tôi sử dụng demo: :parcel: :Parcel). Điều này là do chúng tôi gõ rõ ràng Nhận là Nhận. Nếu bạn muốn một vùng chứa thực sự chung chung có thể nhận bất kỳ loại đối tượng nào, bạn sẽ phải sử dụng generics hoặc một cách tiếp cận khác (có thể là trường động với kiểu xóa). Nhưng đối với hầu hết các trường hợp sử dụng, bạn sẽ biết những loại trẻ em mà bạn mong đợi. Tại sao public_receiver thay vì chỉ gọi Receive? Nếu chúng ta thử transfer: :receiver (&mut warehouse.id, parcel_ticket) trong mô-đun warehouse, trình xác minh Move sẽ từ chối vì Parcel không được định nghĩa trong demo: :warehouse. Sui cung cấp public_receiver như một cách may mắn để thực hiện việc này với một kiểm tra khả năng bổ sung (yêu cầu cửa hàng). Tương tự, Sui có transfer vs public_transfer, freeze object vs public_freeze object, v.v., theo cùng một mẫu: các phiên bản public_ được sử dụng bên ngoài mô-đun xác định và yêu cầu lưu trữ. Đừng quên sự cho phép của phụ huynh: Ngay cả với public_receiver, bạn vẫn cần &mut warehouse.id đó. Chúng tôi nhận được nó vì _parcel nằm trong mô-đun của Warehouse và chấp nhận &mut Warehouse. Do đó, chỉ ai đó có thể gọi cho người đó (chủ kho) mới có thể rút bưu kiện. Nếu mô-đun kho không cung cấp một hàm như vậy một cách công khai, thì cũng không ai có thể gọi public_receiver bên ngoài trên con của nó. Vì vậy, cross-module không bỏ qua sự kiểm soát của cha mẹ; nó chỉ cho phép mã của cha mẹ hoạt động với các kiểu con mà nó không xác định. Lưu ý về khả năng lưu trữ: Việc cung cấp một kho đối tượng làm cho nó linh hoạt hơn nhưng ít bị hạn chế hơn một chút - bất kỳ mô-đun nào có tham chiếu gốc đều có thể kéo nó ra bằng cách sử dụng public_receiver. Nếu bạn muốnhạn hạncách truy xuất một đối tượng (ví dụ: thực thi logic tùy chỉnh hoặc ngăn chặn việc trích xuất dễ dàng), bạn có thể cố tình biến nó thành chỉ có khóa. Chúng ta sẽ thấy một ví dụ về điều đó với các đối tượng bị ràng buộc với linh hồn. Trong những trường hợp đó, bạn có thể triển khai một hàm nhận tùy chỉnh thay vì dựa vào public_receiver. Tóm lại phần này: public_receiver là bạn của bạn để quản lý các đối tượng con được xác định trong các mô-đun khác, miễn là các đối tượng đó có khả năng lưu trữ. Nó cho phép bạn xây dựng các hệ thống đa mô-đun (như Kho khó/Bưu kiện của chúng tôi) trong khi vẫn tôn trọng quyền sở hữu và kiểm soát truy cập. Chỉ cần nhớ bao gồm store trên các loại con và sử dụng public_transfer khi gửi chúng cho cha mẹ từ bên ngoài mô-đun của họ.
- Sui
- Architecture
6 - Hỏi đáp Chuyên GiaDành choSuiJun 30, 2025
Why can’t I connect my wallet to a Sui dApp?
I’m trying to use a Sui dApp (like Tradeport, SuiSwap, or a custom platform), but my wallet won’t connect properly. Sometimes, I get no error at all—just nothing happens when I click "Connect Wallet." Other times, I see errors like: "Wallet not detected" (even though I have Sui Wallet or another wallet installed) "Connection failed: Invalid account" "Transaction rejected" before I even approve anything What I’ve tried: Refreshing the page Switching browsers (Chrome, Firefox, Brave) Checking wallet extension permissions Trying different networks (Devnet, Testnet, Mainnet) Reinstalling the wallet extension Questions: Why does this happen, and how can I fix it? Are there common mistakes users make when connecting wallets to Sui dApps? If my wallet was working before but suddenly stopped, what could be the cause?
- Sui
- Transaction Processing
61Câu trả lời hay nhất 
Làm thế nào để xây dựng một DApp phức tạp trên Sui Move?
Khóa học #2: Đi sâu vào lập trình di chuyển - Xây dựng DApps phức tạp trên Sui Bây giờ bạn đã nắm bắt những điều cơ bản của lập trình Move và triển khai hợp đồng thông minh đầu tiên của mình, đã đến lúc nâng kỹ năng của bạn lên một tầm cao mới. Trong bài viết này, chúng ta sẽ khám phá cách xây dựng các ứng dụng phi tập trung (DApps) phức tạp hơn bằng cách sử dụng Move on the Sui blockchain. Bước 1: Nắm vững các khái niệm Sui Move nâng cao Trước khi đi sâu vào mã hóa, hãy xem lại một số tính năng nâng cao của Move khiến nó phù hợp nhất để xây dựng DApps an toàn và có thể mở rộng: ####**1. Lập trình định hướng tài nguyên Move coi tài sản kỹ thuật số là** tài nguyên, đảm bảo chúng không thể bị sao chép, vô tình xóa hoặc lạm dụng (https://docs.sui.io/learn/resource-oriented-programming). Điều này đạt được thông qua các quy tắc sở hữu nghiêm ngặt và an toàn loại hình. Ví dụ: module examples::token { use sui::object::{Self, UID}; use sui::transfer; struct Token has key, store { id: UID, value: u64, } public fun mint(ctx: &mut TxContext, value: u64): Token { Token { id: object::new(ctx), value, } } public fun transfer_token(token: Token, recipient: address) { transfer::public_transfer(token, recipient); } } Trong ví dụ này, Tokentài nguyên được tạo và chuyển giao an toàn. Tài nguyên trong Move không thể thay đổi theo mặc định trừ khi được đánh dấu rõ ràng là có thể thay đổi, thêm một lớp bảo mật bổ sung. ####2. Mô-đun và đóng gói Các mô-đun trong Move hoạt động như các đơn vị chức năng khép kín, cho phép tổ chức và khả năng tái sử dụng tốt hơn. Ví dụ: bạn có thể tách logic tạo mã thông báo khỏi logic chuyển sang các mô-đun riêng biệt (https://examples.sui.io/modules). Tính mô-đun này đảm bảo mã sạch hơn và bảo trì dễ dàng hơn. ####3. Thiết kế lấy đối tượng làm trung tâm UIDSui Move giới thiệu một mô hình lấy đối tượng làm trung tâm**, trong đó mọi tài nguyên đều có một định danh duy nhất toàn cầu (). Điều này cho phép tham chiếu trực tiếp và tương tác với các đối tượng, giúp quản lý quá trình chuyển đổi trạng thái phức tạp dễ dàng hơn (https://docs.sui.io/objects). Bước 2: Viết hợp đồng thông minh mô-đun Hãy tạo ra một hợp đồng thông minh tiên tiến hơn thể hiện các khái niệm này. Chúng tôi sẽ xây dựng một thị trường NFT đơn giản, nơi người dùng có thể đúc và giao dịch NFT. ####Xác định Tài nguyên NFT Bắt đầu bằng cách xác định tài nguyên NFT trong mô-đun Move: module examples::nft_marketplace { use sui::object::{Self, UID}; use sui::transfer; struct NFT has key, store { id: UID, name: String, price: u64, } public fun mint_nft(ctx: &mut TxContext, name: String, price: u64): NFT { NFT { id: object::new(ctx), name, price, } } public fun list_for_sale(nft: NFT, price: u64, ctx: &mut TxContext) { nft.price = price; transfer::public_transfer(nft, tx_context::sender(ctx)); } } Ở đây, NFTtài nguyên bao gồm các thuộc tính như namevàprice. Ch mint_nftức năng này tạo một NFT mới, đồng thời list_for_salecho phép người dùng liệt kê NFT của họ để bán. ####**Biên dịch và triển khai Sử dụng Sui CLI để biên dịch và triển khai hợp đồng của bạn. Viết một tập lệnh triển khai để tự động hóa quá trình này: sui move build sui client publish --gas-budget 10000 Thao tác này sẽ đóng gói và triển khai mô-đun của bạn lên Sui Devnet (https://docs.sui.io/cli). Bước 3: Xây dựng một React Frontend cho Marketplace của bạn Với hợp đồng thông minh của bạn được triển khai, hãy kết nối nó với giao diện người dùng React. ####Thiết lập dự án Khởi tạo một dự án React nếu bạn chưa thực hiện: npx create-react-app nft-marketplace cd nft-marketplace npm install @mysten/sui.js ####Tích hợp với Ví Sui Sử dụng @mysten/sui.jsthư viện để tương tác với blockchain Sui: import { JsonRpcProvider, SuiClient } from '@mysten/sui.js'; const provider = new SuiClient({ url: 'https://fullnode.devnet.sui.io' }); async function fetchNFTs(ownerAddress) { const objects = await provider.getObjectsOwnedByAddress(ownerAddress); console.log('User NFTs:', objects); } ####* Hiển thị dữ liệu NFT* Tìm nạp và hiển thị dữ liệu NFT trong ứng dụng React của bạn: function NFTList({ ownerAddress }) { const [nfts, setNFTs] = useState([]); useEffect(() => { async function loadNFTs() { const response = await provider.getObjectsOwnedByAddress(ownerAddress); setNFTs(response.data); } loadNFTs(); }, [ownerAddress]); return ( {nfts.map((nft) => ( {nft.name} Price: {nft.price} SUI ))} ); } Bước 4: Tăng cường bảo mật và hiệu suất ####1. Giao dịch an toàn Đảm bảo tất cả các giao dịch được xác thực cả trên chuỗi và ngoài chuỗi. Sử dụng thư viện như @mysten/sui.jsđể xác minh biên lai giao dịch: async function verifyTransaction(txDigest) { const result = await provider.getTransaction({ digest: txDigest }); console.log('Transaction Verified:', result); } ####2. Tối ưu hóa phí khas Hợp tác với các dịch vụ như* Trạm xăng Shami* để cung cấp các giao dịch không cần gas, cải thiện trải nghiệm người dùng. Ngoài ra, giao dịch hàng loạt để giảm chi phí (https://docs.sui.io/gas-optimization). ####3. Tận dụng khả năng mở rộng của Sui Kiến trúc của Sui hỗ trợ thông lượng cao và độ trễ thấp, làm cho nó trở nên lý tưởng cho các dApps có mức sử dụng nhiều. Kiểm tra ứng dụng của bạn trong điều kiện tải mô phỏng để đảm bảo hiệu suất vẫn nhất quán (https://performance.sui.io). Bước 5: Kiểm tra và gỡ lỗi Kiểm tra là rất quan trọng để tránh các lỗ hổng. Sử dụng các công cụ như* Sui Explorer* để theo dõi các giao dịch và gỡ lỗi. Ngoài ra, hãy viết bài kiểm tra đơn vị cho các mô-đun Move của bạn: #[test] fun test_mint_nft() { use sui::test_scenario; let ctx = &mut test_scenario::ctx(); let nft = examples::nft_marketplace::mint_nft(ctx, "Test NFT", 100); assert!(nft.price == 100, 0); } Chạy các bài kiểm tra của bạn bằng cách sử dụng Sui CLI: sui move test Bước 6: Tham gia với cộng đồng Xây dựng DApps không chỉ là về lập trình mà còn là về sự hợp tác. Chia sẻ tiến trình của bạn trên các nền tảng như* GitHub,* Discord* hoặc* Twitter**. Tham gia vào các hackathons và các thử thách dành cho nhà phát triển do Sui Foundation tổ chức để tinh chỉnh kỹ năng của bạn và đạt được tiếp xúc. Kết luận Bằng cách nắm vững các khái niệm Move nâng cao, viết hợp đồng thông minh mô-đun và xây dựng giao diện trực quan, bạn đã trên con đường trở thành một nhà phát triển DApp thành thạo trên blockchain Sui. Hãy nhớ ưu tiên bảo mật, tối ưu hóa hiệu suất và tương tác với cộng đồng để tối đa hóa tác động của bạn. Hãy theo dõi* Course #3*, nơi chúng ta sẽ khám phá các trường hợp sử dụng trong thế giới thực và các kỹ thuật nâng cao để mở rộng DApps của bạn trên Sui! Nếu bạn muốn làm rõ thêm hoặc tài nguyên bổ sung, vui lòng hỏi!
- Sui
- Architecture
- Move
6
Bắt đầu với Move Learning - Khóa học #1
Cho dù bạn là người mới bắt đầu hay một nhà phát triển có kinh nghiệm, hướng dẫn từng bước này sẽ giúp bạn hiểu cách Move, một ngôn ngữ lập trình định hướng tài nguyên, có thể được sử dụng để xây dựng DApps trên blockchain Sui. ###Bước 1: Hiểu về Move và các tính năng chính của nó Trước khi đi sâu vào mã hóa, hãy thảo luận ngắn gọn vềMovelà gì và tại sao nó lại độc đáo. Movelà một ngôn ngữ lập trình được thiết kế để viết các hợp đồng thông minh an toàn và hiệu quả. Nó giới thiệulập trình định hướng tài nguyên, trong đó tài sản kỹ thuật số được coi là tài nguyên hạng nhất, đảm bảo chúng không thể bị sao chép hoặc xóa một cách vô ý. Không giống như các ngôn ngữ khác,Movegiảm thiểu lỗ hổng thông qua các tính năng như* đánh máy tĩnh và* quản lý tài nguyên mạnh mẽ**. Nếu bạn chưa quen vớiMove, chúng tôi khuyên bạn nên xemGiới thiệu về Sui Movevideoby Shayan từ Quỹ Sui. Điều này sẽ cung cấp kiến thức cơ bản về mạng Sui và vai trò của Move trong đó. ###Bước 2: Thiết lập môi trường phát triển của bạn Để bắt đầu, bạn sẽ cần cài đặt các công cụ và tệp nhị phân cần thiết. Thực hiện theo các bước sau: 1.* Cài đặt Sui Binaries* Bắt đầu bằng cách cài đặt các nhị phân Sui**để đảm bảo môi trường phát triển của bạn đã sẵn sàng. Sui CLI (Giao diện dòng lệnh) sẽ cho phép bạn tương tác với blockchain Sui. Bạn có thể tìm thấy hướng dẫn chi tiết trong Sui Docs. 2.* Chọn nền tảng của bạn* Tùy thuộc vào việc bạn đang sử dụng Windows, macOS hay Linux, hãy làm theo hướng dẫn thiết lập tương ứng được cung cấp trong loạt video hoặc tài liệu chính thức của Sui. 3.* Thiết lập VPS (Tùy chọn)* Nếu máy tính xách tay của bạn không đủ mạnh, hãy cân nhắc thiết lập Máy chủ riêng ảo (VPS) để xử lý tải tính toán. ###Bước 3: Viết hợp đồng thông minh bước đầu tiên của bạn Bây giờ môi trường của bạn đã sẵn sàng, hãy viết một hợp đồng thông minh* Moveđơn giản. Đối với hướng dẫn này, tôi có thể đề nghị sử dụng ví dụ* Sweet Place, được lấy cảm hứng từ Flash Place**. 1.* Xác định tài lực* Bắt đầu bằng cách xác định một tài nguyên trong mô-đun Move của bạn. Ví dụ: module examples::sweet_place { use sui::object::{Self, UID}; use sui::transfer; struct SweetPlace has key { id: UID, name: String, } public fun create_sweet_place(ctx: &mut TxContext, name: String) { let sweet_place = SweetPlace { id: object::new(ctx), name, }; transfer::public_transfer(sweet_place, tx_context::sender(ctx)); } } 2.** Biên dịch và triển khai Sử dụng Sui CLI để biên dịch và triển khai hợp đồng của bạn. Viết một tập lệnh triển khai để tự động hóa quá trình này, đảm bảo tích hợp trơn tru với giao diện người dùng sau này. ###Bước 4: Xây dựng React Frontend Với hợp đồng thông minh của bạn được triển khai, đã đến lúc kết nối nó vớiReactfrontend. Bước này giả định bạn có một số kinh nghiệm trước đây với React. Nếu không, hãy xemKhóa học React dành cho người mới bắt đầu**của FreeCodeCamp.org. 1.* Thiết lập dự án* Khởi tạo một dự án React bằng cách sử dụng create-react-apphoặc bất kỳ khung nào bạn chọn. 2.* Tích hợp với ví Sui* Sử dụng các thư viện @mysten/sui.jsthích tương tác với blockchain Sui. Ví dụ: import { JsonRpcProvider } from '@mysten/sui.js'; const provider = new JsonRpcProvider('https://fullnode.devnet.sui.io'); 3.* Lấy dữ liệu từ hợp đồng của bạn* Truy vấn dữ liệu từ hợp đồng Move đã triển khai của bạn và hiển thị nó trong ứng dụng React của bạn. Sử dụng bộ chỉ động**để theo dõi các giao dịch và thay đổi trạng thái một cách hiệu quả. ###Bước 5: Nâng cao trải nghiệm người dùng (UX) Một trong những tính năng nổi bật của hướng dẫn này là tập trung vào việc tạo ra trải nghiệm người dùng liền mạch. Đây là cách bạn có thể nâng cao UX: 1.* Tích hợp các giao dịch không khí gas* Hợp tác với các dịch vụ nhưTrạm xăng Shamiđể cho phép giao dịch không cần gas cho người dùng của bạn. Điều này loại bỏ các rào cản đối với những người mới không quen thuộc với phí tiền điện tử. 2.* Tối ưu hóa hiệu suất* Tận dụng thông lượng cao và độ trễ thấp của Sui để đảm bảo DApp của bạn hoạt động trơn tru ngay cả khi chịu tải nặng. ###Bước 6: Kiểm tra và gỡ bỏ Kiểm tra là rất quan trọng để đảm bảo ứng dụng của bạn hoạt động như mong đợi. Sử dụng các công cụ nhưSui Explorerđể xác minh các giao dịch và gỡ lỗi [[Tìm kiếm trên Web]]. Ngoài ra, hãy xem lạiNền tảng học tập điện tử MOVEđể biết thông tin chi tiết về các phương pháp hay nhất để kiểm tra và đo lường. ###Bước 7: Tương tác với cộng đồng Cuối cùng, đừng quên tham gia với cộng đồng Sui**! Chia sẻ sự tiến bộ của bạn, đặt câu hỏi và cộng tác với những người khác. Như đã nhấn mạnh trong bản ghi video, kết nối với các nhà phát triển đồng nghiệp có thể dẫn đến những cơ hội thú vị.
- Sui
- Architecture
- SDKs and Developer Tools
- Move
6- Hỏi đáp Chuyên GiaDành choSuiJun 26, 2025
How to Properly Use the Sui SDK for Frontend Integration?
I'm building a frontend (React/Next.js) for a Sui dApp and need to interact with the blockchain—fetching objects, sending transactions, and listening to events. I’ve tried using the @mysten/sui.js SDK, but I’m running into issues: Wallet Connection: Sometimes, the wallet doesn’t return the user’s address after connecting. Transaction Handling: Transactions fail silently or return vague errors. RPC Limits: I get rate-limited or timeouts when fetching large datasets. Real-Time Updates: How can I listen for on-chain events (e.g., NFT mints, balance changes)? What I’ve tried: ✔ Basic SuiClient setup with mainnet and testnet RPCs. ✔ Using useWallet() from @mysten/dapp-kit for wallet integration. ✔ Manual transaction signing with signAndExecuteTransactionBlock. Questions: What’s the recommended way to initialize the Sui SDK in a frontend app? How do I handle errors gracefully (e.g., RPC failures, wallet rejections)? Are there best practices for optimizing queries (batching, caching, etc.)? How can I subscribe to real-time updates (e.g., new transactions, object changes)?
- Sui
- SDKs and Developer Tools
62Câu trả lời hay nhất Các mô-đun Sui Move nâng cao tính bảo mật của hợp đồng thông minh như thế nào?
Hệ thống mô-đun của Sui Move cho phép các nhà phát triển xác định, tổ chức và tương tác an toàn với các đối tượng trên chuỗi tùy chỉnh như thế nào và các tính năng độc đáo của nhận dạng mô-đun và lưu trữ đối tượng trong hệ sinh thái Sui so với các ngôn ngữ hợp đồng thông minh truyền thống là gì?
- Sui
- Architecture
- Security Protocols
- Move
61Câu trả lời hay nhất
Kiếm phần của bạn từ 1000 Sui
Tích lũy điểm danh tiếng và nhận phần thưởng khi giúp cộng đồng Sui phát triển.
- 701
- 618
- 595
- 496
- 360
- 313
- 304
- 295
- 291
- 271
- Làm cách nào để cập nhật khóa của người bán trong ObjectTable khi nó thay đổi trong cấu trúc?50
- Giao diện dễ nhất để tải lên các đốm hải mã là gì?20
- Điều gì xảy ra nếu tôi không yêu cầu ETH qua Sui bridge?00
- Có dễ học Move after solidity không?00
- Có lợi khi tạo các dịch vụ dapps (như trò chơi) trên sui không?00