Tiền thưởng
Kiếm token cho những đóng góp của bạn.
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.
Bài viết
5+15
Hỏi đáp Chuyên GiaXavier.eth313Dành choSuiJun 27, 2025Giao dịch Sui thất bại: Đối tượng được dành riêng cho giao dịch khác
Tôi gặp phải một sự kiên trì JsonRpcErrorkhi cố gắng thực hiện giao dịch trên Sui. Lỗi chỉ ra rằng các đối tượng được dành riêng cho một giao dịch khác, mặc dù tôi đã thực hiện xử lý giao dịch tuần tự với độ trễ. JsonRpcError: Failed to sign transaction by a quorum of validators because one or more of its objects is reserved for another transaction. Other transactions locking these objects: AV7coSQHWg5vN3S47xada6UiZGW54xxUNhRv1QUPqWK (stake 33.83) 0x1c20f15cbe780ee7586a2df90c1ab70861ca77a15970bea8702a8cf97bd3eed9 0x1c20f15cbe780ee7586a2df90c1ab70861ca77a15970bea8702a8cf97bd3eed9 0x1c20f15cbe780ee7586a2df90c1ab70861ca77a15970bea8702a8cf97bd3eed9 Tôi đã thử: Thực hiện giao dịch tuần tự (chờ giao dịch trước hoàn thành) Thêm độ trễ 3 giây giữa các giao dịch Và vẫn gặp phải lỗi tương tự một cách nhất quán. Sử dụng Sui RPC để gửi giao dịch. Cùng một ID đối tượng xuất hiện nhiều lần trong danh sách khóa. Lỗi xảy ra ngay cả với trình tự giao dịch cẩn thận. Điều gì khiến các đối tượng bị “dành riêng” cho các giao dịch khác? Làm thế nào tôi có thể kiểm tra chính xác xem một đối tượng có sẵn hay không trước khi sử dụng nó trong một giao dịch? Có những phương pháp hay nhất để xử lý khóa đối tượng ở Sui không? Điều này có liên quan đến thời điểm cuối cùng của giao dịch không? Có ai gặp phải vấn đề này trước đây không? Bất kỳ thông tin chi tiết nào về quản lý đối tượng phù hợp trong giao dịch Sui sẽ được đánh giá cao!
- Sui
- Transaction Processing
- Move
25+15
Hỏi đáp Chuyên GiaXavier.eth313Dành choSuiJun 17, 2025Làm thế nào để các ràng buộc về khả năng tương tác với các trường động trong các bộ sưu tập không đồng nhất?
Tôi đang xây dựng một thị trường cần xử lý nhiều loại tài sản với các yêu cầu về khả năng khác nhau và tôi đã gặp một số câu hỏi cơ bản về hệ thống loại hình của Move. Tôi muốn lưu trữ các loại tài sản khác nhau trong cùng một bộ sưu tập, nhưng chúng có khả năng khác nhau: NFT thông thường: key + store(có thể chuyển nhượng) Mã thông báo Soulbound: key chỉ (không thể chuyển nhượng) Tài sản tùy chỉnh với các hạn chế chuyển nhượng public struct Marketplace has key { id: UID, listings: Bag, // Want to store different asset types here } // This works for transferable assets public fun list_transferable( marketplace: &mut Marketplace, asset: T, price: u64 ) { /* ... */ } // But how to handle soulbound assets? public fun list_soulbound( // No store ability marketplace: &mut Marketplace, asset_ref: &T, // Can only take reference price: u64 ) { /* How do I store metadata about this? */ } Các câu hỏi chính: Yêu cầu về khả năng: Khi sử dụngdynamic_field::add(), Vcó luôn cần store lúc biên dịch không? Các loại bao bọc có thể giải quyết được điều này không? Lưu trữ không đồng nhất: Một Túi duy nhất có thể lưu trữ các đối tượng với các bộ khả năng khác nhau (key + store + copyvskey + store) và xử lý chúng khác nhau khi chạy không? An toàn kiểu: Vì trường động thực hiện xóa kiểu, làm thế nào để duy trì độ an toàn kiểu khi truy xuất giá trị? Mẫu để lưu trữ siêu dữ liệu loại là gì? Mẫu nhân chứng: Các ràng buộc về khả năng hoạt động như thế nào với các loại bóng ma? Tôi có thể lưu trữ Assetvà Assettrong cùng một bộ sưu tập và trích xuất thông tin loại sau này không? Xây dựng một hệ thống mà NFT, token soulbound và tài sản bị hạn chế đều cần chức năng thị trường nhưng với ngữ nghĩa chuyển khác nhau. Tôi đã thử các loại bao bọc, nhiều bộ sưu tập cho mỗi bộ khả năng, lưu trữ siêu dữ liệu loại riêng biệt. Mỗi loại đều có sự đánh đổi giữa an toàn loại, chi phí khí đốt và độ phức tạp.
- Sui
- Architecture
05Câu trả lời hay nhất+10
Hỏi đáp Chuyên GiaDành choSuiMay 29, 2025Tại sao BCS yêu cầu thứ tự trường chính xác để khử chuỗi khi cấu trúc Move có các trường được đặt tên?
Tại sao BCS yêu cầu thứ tự trường chính xác để khử chuỗi khi cấu trúc Move có các trường được đặt tên? Tôi đã đi sâu vào mã hóa/giải mã BCS trong Move, đặc biệt là cho giao tiếp chuỗi chằng và xử lý dữ liệu ngoài chuỗi. Trong khi xem xét các ví dụ trong tài liệu Sui Move, tôi đã gặp một số hành vi có vẻ phản trực giác và tôi đang cố gắng hiểu các quyết định thiết kế cơ bản. Theo đặc tả của BCS, “không có cấu trúc trong BCS (vì không có kiểu); cấu trúc chỉ đơn giản xác định thứ tự mà các trường được nối tiếp.” Điều này có nghĩa là khi giải mã, chúng ta phải sử dụng peel_*các hàm theo thứ tự chính xác với định nghĩa trường struct. Câu hỏi cụ thể của tôi: Lý do thiết kế: Tại sao BCS yêu cầu khớp thứ tự trường chính xác khi cấu trúc Move có các trường được đặt tên? Sẽ không mạnh mẽ hơn nếu sắp xếp các tên trường cùng với các giá trị, tương tự như JSON hoặc các định dạng tự mô tả khác? Tương tác kiểu chung: Các tài liệu đề cập rằng “các loại chứa các trường kiểu chung có thể được phân tích thành trường kiểu chung đầu tiên.” Hãy xem xét cấu trúc này: struct ComplexObject has drop, copy { id: ID, owner: address, metadata: Metadata, generic_data: T, more_metadata: String, another_generic: U } Chính xác thì quá trình khử phân loại một phần hoạt động như thế nào ở đây? Tôi có thể giải chuỗi tối đa more_metadata và bỏ qua cả hai trường chung hay trường chung đầu tiên (generic_data) có chặn hoàn toàn quá trình giải mã hóa tiếp theo không? Tính nhất quán giữa các ngôn ngữ: Khi sử dụng thư viện JavaScript @mysten /bcs để nối tiếp dữ liệu sẽ được sử dụng bởi hợp đồng Move, điều gì sẽ xảy ra nếu: Tôi vô tình sắp xếp lại các trường trong đối tượng JavaScript? Định nghĩa cấu trúc Move thay đổi thứ tự trường trong nâng cấp hợp đồng? Tôi có cấu trúc lồng nhau với các tham số chung của riêng chúng? Ý nghĩa thực tế: Trong các hệ thống sản xuất, các nhóm xử lý sự tiến hóa lược đồ BCS như thế nào? Bạn có phiên bản lược đồ BCS của mình hay kỳ vọng rằng thứ tự trường cấu trúc là bất biến sau khi được triển khai?
- Sui
- Move
53Câu trả lời hay nhất+10
Hỏi đáp Chuyên GiaDành choMoveMar 11, 2025Sui Move vs Aptos Move - What is the difference?
Sui Move and Aptos Move - two prominent implementations of the Move programming language. While both are rooted in the same foundational principles, they have diverged significantly in design, execution, and ecosystem development. To better understand their differences, we need to uncover some of their key aspects: How do their runtimes differ? Both Sui and Aptos implement their own custom Move virtual machines (VMs). How does this impact performance, scalability, and developer experience? For instance: Does Sui's runtime optimize for parallel execution differently than Aptos'? Are there notable differences in transaction lifecycle management or gas models? What are the differences between their standard libraries? The Move standard library is a critical component for building smart contracts. However, Sui and Aptos have forked their implementations, leading to divergence: Are there modules or functions unique to one implementation but absent in the other? How do these differences affect common use cases like token creation, NFTs, or decentralized finance (DeFi)? How does data storage differ between them? One of the most significant distinctions lies in how Sui and Aptos handle data storage: Sui uses an object-centric model, where each object has its own ownership and permissions. Aptos, on the other hand, retains a more traditional account-based model similar to Ethereum. How does this impact state management, composability, and gas efficiency? Is it fair to say that Aptos is closer to EVM while Sui is closer to SVM? Some developers argue that Aptos' account-based architecture resembles Ethereum's EVM, while Sui's object-centric approach aligns more closely with Solana's SVM. Do you agree with this analogy? Why or why not? How does this architectural choice influence developer ergonomics and application design? Are there universal packages working for both Sui Move and Aptos Move? Given their shared origins, it would be ideal if some libraries or tools were interoperable across both ecosystems. Are there any existing universal packages or frameworks that work seamlessly on both platforms? If not, what are the main barriers to achieving compatibility? Can one of them be transpiled into another? If a project is built on Sui Move, could it theoretically be transpiled to run on Aptos Move, or vice versa? What are the technical challenges involved in such a process? Are there tools or compilers currently available to facilitate this kind of migration?
- Move
21Câu trả lời hay nhất+10
Hỏi đáp Chuyên GiaDành choSuiMar 05, 2025Nhiều lỗi xác minh nguồn” trong các ấn phẩm về mô-đun Sui Move - Giải quyết lỗi tự động
Các nhà phát triển làm việc với Sui Move thường gặp phải các vấn đề liên quan đến “Tìm thấy nhiều lỗi xác minh nguồn” khi cố gắng xuất bản hoặc nâng cấp các mô-đun. Những lỗi này xảy ra do sự không phù hợp giữa các phụ thuộc cục bộ và các đối tác trên chuỗi của chúng, dẫn đến các ấn phẩm không thành công và các thách thức triển khai. Dưới đây là một ví dụ tổng hợp về các lỗi mà các nhà phát triển phải đối mặt: Failed to publish the Move module(s), reason: [warning] Multiple source verification errors found: Local dependency did not match its on-chain version at 0000000000000000000000000000000000000000000000000000000000000002::Sui::vec_set Local dependency did not match its on-chain version at 0000000000000000000000000000000000000000000000000000000000000002::Sui::vec_map Local dependency did not match its on-chain version at 0000000000000000000000000000000000000000000000000000000000000001::MoveStdlib::bit_vector Local dependency did not match its on-chain version at 0000000000000000000000000000000000000000000000000000000000000001::MoveStdlib::ascii Local dependency did not match its on-chain version at 0000000000000000000000000000000000000000000000000000000000000002::Sui::hex Local dependency did not match its on-chain version at 0000000000000000000000000000000000000000000000000000000000000002::Sui::zklogin_verified_id Local dependency did not match its on-chain version at 0000000000000000000000000000000000000000000000000000000000000002::Sui::prover Local dependency did not match its on-chain version at 0000000000000000000000000000000000000000000000000000000000000002::Sui::coin Local dependency did not match its on-chain version at 0000000000000000000000000000000000000000000000000000000000000002::Sui::dynamic_field Local dependency did not match its on-chain version at 0000000000000000000000000000000000000000000000000000000000000002::Sui::transfer On-chain version of dependency Sui::zklogin_verified_id was not found. On-chain version of dependency Sui::zklogin_verified_issuer was not found. Local dependency did not match its on-chain version at 0000000000000000000000000000000000000000000000000000000000000002::Sui::tx_context Local dependency did not match its on-chain version at 0000000000000000000000000000000000000000000000000000000000000002::Sui::transfer_policy Local dependency did not match its on-chain version at 0000000000000000000000000000000000000000000000000000000000000002::Sui::kiosk Vấn đề này thường phát sinh do: Các phiên bản không phù hợp giữa môi trường phát triển địa phương (ví dụ: Sui CLI) và trạng thái trên chuỗi. Sự khác biệt trong cấu hình gói trên các mạng (ví dụ: Mainnet so với Testnet). Thiếu hoặc lỗi thời các phụ thuộc trong môi trường trên chuỗi. Các câu hỏi chính Làm thế nào chúng ta có thể tự động hóa việc phát hiện và giải quyết các sự không phù hợp phụ thuộc này trong quá trình xuất bản? Những công cụ hoặc tập lệnh nào có thể được phát triển để đảm bảo rằng các phụ thuộc cục bộ luôn phù hợp với các đối tác trên chuỗi của chúng? Có cách nào để hợp lý hóa quy trình này bằng cách tích hợp kiểm tra phụ thuộc vào các đường ống CI/CD hiện có hoặc tăng cường Sui SDK không? Nhiệm vụ của bạn là đề xuất một giải pháp giải quyết những thách thức này, đảm bảo triển khai mượt mà và đáng tin cậy hơn cho các nhà phát triển Sui Move. Đảm bảo đăng giải pháp của bạn bên dưới.
- Sui
- SDKs and Developer Tools
43Câu trả lời hay nhất
- 2565
- 1780
- 1096
- 919
- 711
- 626
- 605
- 562
- 554
- 537