Sui.

Khám phá

Kết nối với cộng đồng và khám phá ý tưởng mới.

Sui.X.Peera.

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.

Cộng Đồng

Bộ lọc:Tất cả các blockchain

Tiền thưởng

  • Xavier.eth.Peera.
    Xavier.eth313
    Dành choSuiJun 27, 2025
    +15

    Giao 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!

    2
    4
  • Xavier.eth.Peera.
    Xavier.eth313
    Dành choSuiJun 17, 2025
    +15

    Là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.

    0
    4
  • Peera Admin.Peera.
    Peera Admin37
    Dành choSuiMay 29, 2025
    +10

    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 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?

    5
    3

Mới nhất

  • CarlkawIy.Peera.
    CarlkawIy259
    Dành choSuiJul 01, 2025

    Làm thế nào để thu hồi tiền SUI từ ví cũ?

    Tôi đã cố gắng xác định vị đồng xu SUI của mình khi thiết lập tài khoản Slush mới, nhưng tôi không thấy chúng. Làm cách nào để xác minh xem tôi có sử dụng cụm từ chính xác để nhập ví cũ hay không?

    0
    2
  • MiniBob.Peera.
    MiniBob701
    Dành choSuiJul 01, 2025

    Nắm vững các khái niệm ngôn ngữ Move - Khóa học #2

    Trong khiKhóa học #1 tôi đã thực hiện trước đây đã giới thiệu cho bạn những điều cơ bản về việc viết hợp đồng thông minh trong Move và xây dựng DApps đơn giản trên blockchain Sui, khóa học này tập trung vào việc đào sâu hiểu biết của bạn về chính ngôn ngữ Move**- từ hệ thống loại mạnh mẽ của nó đến các mẫu nâng cao như generic, sự kiện, mô-đun và cơ chế kiểm soát truy cập. Vào cuối khóa học này, bạn sẽ có thể: Viết mã Move mô-đun, có thể tái sử dụng và an toàn Sử dụng thuốc generic, khả năng và loại tài nguyên một cách hiệu quả Thực hiện kiểm soát truy cập chi tiết bằng cách sử dụng các khả năng Phát ra và nghe các sự kiện để tích hợp ngoài chuỗi Làm việc với các cấu trúc dữ liệu phức tạp như bảng và vectơ Hiểu cách Move khác với các ngôn ngữ hợp đồng thông minh khác như Solidity Hãy đi sâu vào trung tâm của ngôn ngữ Move! Bước 1: Hiểu các tính năng ngôn ngữ cốt lõi của Move Move được thiết kế với sự an toàn và rõ ràng trong tâm trí. Hãy khám phá một số tính năng quan trọng nhất làm cho Move trở nên độc đáo như một ngôn ngữ hợp đồng thông minh. 1.1 Lập trình định hướng tài nguyên (Đã xem xét lại) Cốt lõi của Move là khái niệmtài liệu, là những loại đặc biệt không thể sao chép hoặc xóa trừ khi được phép rõ ràng. Điều này thực thi việc xử lý an toàn các tài sản kỹ thuật số như mã thông báo hoặc NFT. module examples::token { use sui::object::{Self, UID}; struct MyToken has key, store { id: UID, value: u64, } public fun mint(ctx: &mut TxContext): MyToken { MyToken { id: object::new(ctx), value: 100, } } } Trong ví dụ này: MyToken- keylà mộttài lượngvì nó có khả năng. Nó có thể được lưu trữ (store) và được xác định duy nhất bởi nóid. Nó không thể được sao chép hoặc loại bỏ trừ khi được chỉ định. Điều này đảm bảo rằng mỗi phiên MyTokenbản được sở hữu và quản lý duy nhất, ngăn chặn sự sao chép hoặc xóa vô tình. 1.2 Hệ thống khả năng Mỗi loại trong Move đều có một tập hợp cáckínhxác định những thao tác mà nó hỗ trợ: | Khả năng | Ý nghĩa | | ---------| | copy| Có thể được nhân đôi | | drop| Có thể bị loại bỏ mà không bị phá hủy | store| Có thể được lưu trữ trong kho lưu trữ toàn cầu | | key| Có thể được sử dụng như một cấu trúc với một trường ID (tức là một đối tượng) | Ví dụ: struct Example has copy, drop { value: u64 } Hiểu được những khả năng này là điều cần thiết để thiết kế các hợp đồng thông minh an toàn và có thể dự đoán được. Tại sao khả năng quan trọng Khả năng thực thi các quy tắc nghiêm ngặt tại thời điểm biên dịch. Ví dụ: Một cấu trúc chỉ có keyvà storekhông thể sao chép hoặc bỏ đi. Bạn không thể trả về một cấu trúc không thể thả từ một hàm trừ khi nó được lưu trữ hoặc chuyển. Điều này ngăn chặn các lỗi như chi tiêu gấp đôi hoặc mất token vô tình. 1.3 Thông số chung và loại Move hỗ trợ các loại chung, cho phép các nhà phát triển viết mã linh hoạt và có thể tái sử dụng. module examples::storage { use sui::object::{Self, UID}; struct Box has key { id: UID, content: T, } public fun new_box(ctx: &mut TxContext, content: T): Box { Box { id: object::new(ctx), content, } } } Đây `là mộttham số kiểu, giúp làm Box`việc với bất kỳ loại nào trong khi vẫn an toàn và hiệu quả. Lưu ý: Từ phantomkhóa chỉ ra rằng điều đó Tkhông ảnh hưởng đến biểu diễn thời gian chạy của cấu trúc - hữu ích cho mô hình hóa trừu tượng. Bước 2: Phát triển mô-đun và quản lý gói Khi các dự án Move của bạn ngày càng phức tạp, việc tổ chức mã của bạn trở nên quan trọng. 2.1 Tạo và xuất bản gói di chuyển Gói di chuyểnchứa một hoặc nhiều mô-đun và xác định các phụ thuộc. Đó là đơn vị triển khai và quản lý phiên bản trong Move. Cấu trúc thư mục: sources/ place.move user.move Move.toml Move.tomlXác định các phụ thuộc trong: [dependencies] Sui = { git = "https://github.com/MystenLabs/sui.git", subdir = "crates/sui-framework" } MyLibrary = { local = "../my-library" } Bạn có thể xuất bản các gói lên mạng Sui và sử dụng lại chúng trên nhiều DApp. 2.2 Tái sử dụng các mô-đun hiện có cointransfertx_contextSui Frameworkcung cấp các mô-đun đã được thử nghiệm trong trận chiến như,, và. Luôn luôn kiểm tra những gì có sẵn trước khi viết logic tùy chỉnh. Ví dụ: để chuyển một đối tượng: use sui::transfer; public entry fun send_place(place: Place, recipient: address) { transfer::public_transfer(place, recipient); } Sử dụng các thư viện tiêu chuẩn đảm bảo an toàn hơn, phát triển nhanh hơn và khả năng tương tác tốt hơn. Bước 3: Sự kiện và giao tiếp ngoài chuỗi Để xây dựng các ứng dụng trong thế giới thực, hợp đồng Move của bạn cần giao tiếp với các hệ thống ngoài chuỗi như frontend hoặc trình lập chỉ mục. 3.1 Sự kiện phát ra Move cho phép phát rasự kiệncó thể được lập chỉ mục bởi các dịch vụ bên ngoài. use sui::event; struct PlaceCreated has drop { name: String, } public fun emit_place_created(name: String) { event::emit(PlaceCreated { name }); } Sự kiện này sẽ xuất hiện trên blockchain và có thể được chọn bởi các nhà thám hiểm hoặc các công cụ lập chỉ mục. 3.2 Lắng nghe sự kiện Sử dụng các công cụ nhưSuiet Explorer,Subsquidhoặc API Sui JSON-RPC để lắng nghe các sự kiện phát ra và phản ứng tương ứng trong ứng dụng của bạn. Trong JavaScript/TypeScript: import { JsonRpcProvider } from '@mysten/sui.js'; const provider = new JsonRpcProvider('https://fullnode.devnet.sui.io'); const events = await provider.getEvents({ MoveEventType: '0x...::example::PlaceCreated' }); Bước 4: Kiểm soát truy cập và các mẫu bảo mật Bảo mật là tối quan trọng khi xử lý các hợp đồng thông minh. Move cung cấp một số công cụ để thực hiện kiểm soát truy cập mạnh mẽ. 4.1 Mô hình sở hữu đối tượng Sui thực thi quyền sở hữu ở cấp giao thức. Chỉ chủ sở hữu của một đối tượng mới có thể đột biến hoặc chuyển nó. public entry fun update_name(sweet_place: &mut SweetPlace, new_name: String) { sweet_place.name = new_name; } Chỉ chủ sở hữu hiện tại mới có thể gọi hàm này. 4.2 Mẫu khả năng Để có quyền chi tiết hơn, hãy sử dụngmẫu khả năng- tạo các đối tượng đặc biệt cấp quyền truy cập hạn chế vào một số chức năng nhất định. struct AdminCap has key { id: UID } public entry fun grant_admin_cap(ctx: &mut TxContext) { let cap = AdminCap { id: object::new(ctx) }; transfer::public_transfer(cap, tx_context::sender(ctx)); } public entry fun restricted_action(_: &AdminCap) { // perform admin action } Bây giờ chỉ những người dùng nắm giữ mới AdminCapcó thể thực thirestricted_action. Mô hình này được sử dụng rộng rãi trong DeFi và DAO để ủy quyền một cách an toàn. Bước 5: Làm việc với cấu trúc dữ liệu phức tạp Move hỗ trợ các kiểu dữ liệu có cấu trúc cho phép các nhà phát triển mô hình hóa logic và các mối quan hệ phức tạp. 5.1 Vectơ Vectơ được sử dụng để lưu trữ các bộ sưu tập có thứ tự của các mặt hàng cùng loại. let names = vector[String::utf8(b"Alice"), String::utf8(b"Bob")]; Chúng hữu ích để lưu trữ danh sách NFT, vai trò người dùng hoặc siêu dữ liệu động. Ví dụ sử dụng: vector::push_back(&mut names, String::utf8(b"Charlie")); 5.2 Bảng (thông qua Thư viện Tiêu chuẩn Sui) Mặc dù Move không hỗ trợ bản đồ hoặc bảng băm, Sui cung cấp Tableloại trong thư viện tiêu chuẩn của nó. use sui::table::{Self, Table}; struct Registry has key { id: UID, entries: Table, } public fun add_entry(registry: &mut Registry, key: u64, value: String) { table::add(&mut registry.entries, key, value); } Sử dụng các bảng để quản lý các bộ dữ liệu lớn một cách hiệu quả. Bước 6: Kiểm tra và gỡ lỗi hợp đồng của bạn Kiểm tra đảm bảo mã Move của bạn hoạt động như mong đợi trong các điều kiện khác nhau. 6.1 Kiểm tra đơn vị khi di chuyển Viết các bài kiểm tra đơn vị trực tiếp trong các mô-đun Move của bạn bằng cách sử dụng khung thử nghiệm. #[test] public fun test_create_sweet_place() { let ctx = tx_context::dummy(); create_sweet_place(&mut ctx, String::utf8(b"My House")); } Chạy thử nghiệm với: sui move test 6.2 Sử dụng Sui Explorer Sau khi triển khai hợp đồng của bạn, hãy sử dụng Sui Explorer để kiểm tra giao dịch, xem trạng thái đối tượng và gỡ lỗi các vấn đề. Bước 7: Các ứng dụng trong thế giới thực của các khái niệm di chuyển nâng cao Bây giờ bạn đã hiểu các tính năng ngôn ngữ cốt lõi, hãy khám phá cách chúng áp dụng cho các kịch bản trong thế giới thực. 7.1 Nền tảng đúc NFT Tạo một nền tảng cho phép người dùng đúc các NFT được hỗ trợ bởi tài nguyên Move, tận dụng các mô hình quyền sở hữu và tài nguyên. 7.2 Hệ thống bỏ phiếu DAO Triển khai một tổ chức tự trị phi tập trung (DAO) sử dụng Move để bỏ phiếu, đề xuất và quản trị, sử dụng các sự kiện và khả năng cho các hành động an toàn. 7.3 Hoán đổi mã thông báo và AMM Xây dựng một sàn giao dịch phi tập trung (DEX) bằng cách sử dụng các mô-đun Move để đại diện cho các nhóm thanh khoản và hoán đổi mã thông báo, sử dụng chung và bảng để quản lý trạng thái hiệu quả.

    2
  • Evgeniy CRYPTOCOIN.Peera.
    Evgeniy CRYPTOCOIN196
    Dành choSuiJun 30, 2025

    NFT động là gì và tại sao Sui lại xuất sắc ở chúng?

    Không gian NFT đang phát triển vượt ra ngoài hình ảnh tĩnh và ảnh hồ sơ (PFP). Biên giới tiếp theo? NFT động (DNFT) — các mã thông báo có thể thay đổi dựa trên dữ liệu trong thế giới thực, tương tác của người dùng hoặc các sự kiện trên chuỗi. Trong khi nhiều blockchain hỗ trợ NFT, Sui Network có vị trí độc đáo để cung cấp năng lượng cho tương lai của DNFT nhờ kiến trúc sáng tạo của nó. Bài viết này khám phá: Điều gì làm cho NFT trở nên “năng động”? Tại sao công nghệ của Sui lại hoàn hảo cho DNFT Các trường hợp sử dụng trong thế giới thực hiện nay Tương lai của tài sản kỹ thuật số tương tác 1. NFT động là gì? Không giống như các NFT truyền thống (tĩnh và bất biến), NFT động có thể cập nhật: Siêu dữ liệu (ví dụ: NFT thể thao thay đổi dựa trên số liệu thống kê trò chơi) Ngoại hình (ví dụ: một tác phẩm nghệ thuật phát triển theo thời gian) Tiện ích (ví dụ: NFT khách hàng thân thiết mở khóa các đặc quyền mới) Chúng hoạt động như thế nào? DNFT sử dụng logic hợp đồng thông minh+đầu vào dữ liệu bên ngoài (oracles, hành động của người dùng, v.v.) để kích hoạt các thay đổi. Ví dụ: Một tác phẩm nghệ thuật NFT nhạy cảm với thời tiết thay đổi màu sắc dựa trên dữ liệu khí hậu thời gian thực. Một nhân vật trò chơi NFT tăng cấp khi bạn chơi. 2. Tại sao Sui là Blockchain tốt nhất cho NFT động Trong khi Ethereum và Solana cũng hỗ trợ DNFT, thiết kế của Sui mang lại những lợi thế chính: Lưu trữ trên chuỗi (Không phụ thuộc bên ngoài) Hầu hết các blockchain lưu trữ siêu dữ liệu NFT ngoài chuỗi (ví dụ: IPFS), làm cho các bản cập nhật động trở nên vụng về. Sui lưu trữ mọi thứ trên chuỗi, cho phép sửa đổi tức thì, không đáng tin cậy. Ngôn ngữ di chuyển: Nâng cấp an toàn và linh hoạt Solidity của Ethereum yêu cầu các hợp đồng proxy phức tạp cho các NFT có thể nâng cấp. Ngôn ngữ Move của Sui cho phép tính đột biến bản địa — không có cách giải quyết vụng về. Xử lý song song (Khả năng mở rộng lớn) Cập nhật hàng nghìn DNFT cùng một lúc? Ethereum phải vật lộn với tắc nghẽn. Việc thực thi song song của Sui xử lý hàng triệu bản cập nhật mà không bị chậm lại. Mô hình lấy đối tượng làm trung tâm (Điều khiển dạng hạt) Mỗi NFT là một đối tượng độc lập với logic tùy chỉnh. Cho phép tính tương tác tinh chỉnh (ví dụ: chỉ chủ sở hữu mới có thể kích hoạt thay đổi). 3. Các trường hợp sử dụng DNFT trong thế giới thực trên Sui Trò chơi & Metaverse Các vật phẩm trong trò chơi phát triển (ví dụ: một thanh kiếm NFT có khả năng khi sử dụng). Khả năng tương tác giữa các trò chơi (đối tượng của Sui có thể di chuyển giữa các DApps). Ví dụ: * Các trò chơi dựa trên SUI như Panzerdogs sử dụng DNFT cho các avatar có thể tùy chỉnh. * Nghệ thuật tạo ra & phản ứng NFT hỗ trợ AI thay đổi phong cách dựa trên xu hướng thị trường. Nghệ thuật hợp tác nơi các nhà sưu tập ảnh hưởng đến tác phẩm cuối cùng. Ví dụ: *Các phòng thí nghiệm nghệ thuật như Sui Gallery tổ chức các cuộc triển lãm dNFT. * Theo dõi tài sản thế giới thực (RWA) Chứng thư NFT cập nhật với hồ sơ tài sản. Huy hiệu chứng nhận hết hạn hoặc gia hạn tự động. Chương trình thành viên & khách hàng thân thiết NFT giảm giá năng động cải thiện theo chi tiêu của khách hàng. Thẻ truy cập VIP mở khóa các cấp mới theo thời gian. Ví dụ: *Các đối tác bán lẻ của Sui đang thử nghiệm các chương trình khách hàng thân thiết của DnFT. * 4. Tương lai của DNFTs trên Sui Mong đợi xem: DNFT tích hợp AI (ví dụ: chatbot sống trong hình đại diện NFT). DNFT thế chấp DEFI (giá trị điều chỉnh dựa trên điều kiện thị trường). Trò chơi hoàn toàn trên chuỗi trong đó mọi tài sản là một dNFT có thể thay đổi. Kết luận: Sui đang xây dựng tương lai của NFT Trong khi NFT tĩnh chiếm ưu thế trong giai đoạn 2021-2023, NFT động sẽ thống trị đợt tăng giá tiếp theo — và công nghệ của Sui khiến nó trở thành nền tảng lý tưởng. Với bộ lưu trữ trên chuỗi, bảo mật của Move và khả năng mở rộng chưa từng có, Sui đã sẵn sàng trở thành ngôi nhà của các DNFT tiên tiến.

    5

Chưa có câu trả lời

  • Owen.Peera.
    Owen496
    Dành choSuiJun 11, 2025

    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?

    Xin chào mọi người, tôi mới bắt đầu viết hợp đồng thông minh và tôi đang thực hiện dự án đầu tiên của mình. Tôi rất muốn được giúp đỡ với một vấn đề mà tôi gặp khó khăn. Cho đến nay, tôi đã tạo một Merchantstruct trông như thế này: -id: một định danh duy nhất (UID) -owner: địa chỉ của người bán -key: Chuỗi được sử dụng như một khóa duy nhất -balance: một u64 đại diện cho số dư của họ Tôi cũng đã tạo một MerchantRegistrycấu trúc để quản lý tất cả các thương nhân: -id: UID khác -merchant_to_address: ObjectTablelập bản đồ địa chỉ cho thương nhân -merchant_to_key: một ObjectTablebản đồ chìa khóa cho thương nhân Tôi muốn có thể tìm kiếm một thương nhân bằngđịa chỉcủa họ hoặc bằng* khóa*của họ. Khi người dùng cập nhật khóa của họ bên Merchanttrong cấu trúc, thay đổi sẽ không tự động cập nhật khóa trong merchant_to_keybảng. Điều đó có nghĩa là chìa khóa cũ vẫn chỉ vào thương gia, làm hỏng mọi thứ. Tôi đã thử xóa mục nhập khỏi bảng và chèn nó trở lại bằng khóa mới, nhưng tôi tiếp tục gặp lỗi như: “Không thể bỏ qua các giá trị mà không có khả năng giảm” Tôi khá chắc chắn đây là một sai lầm của người mới bắt đầu, nhưng tôi không thể tìm thấy lời giải thích hoặc giải pháp rõ ràng ở bất cứ đâu. Có cách nào thích hợp để xử lý việc cập nhật khóa trong cả cấu trúc và bảng tra cứu không?

    5
    0
  • 0xduckmove.Peera.
    0xduckmove618
    Dành choSuiJun 06, 2025

    Giao diện dễ nhất để tải lên các đốm hải mã là gì?

    chỉ là một giao diện người dùng đơn giản để tải lên hải mã? (ngoài Tusky)

    2
    0
  • 1 Luca.Peera.
    1 Luca199
    Dành choSuiApr 09, 2025

    Điều gì xảy ra nếu tôi không yêu cầu ETH qua Sui bridge?

    Tôi đã sử dụng cầu Sui để chuyển một số ETH nhưng chưa xác nhận nó vì phí khá cao. Điều gì sẽ xảy ra nếu tôi để nó không được xác nhận?

    0
    0

Xu hướng

  • Vens.sui.Peera.
    Vens.sui211
    Dành choSuiApr 29, 2025

    AMM 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

    8
    2
  • 0xduckmove.Peera.
    0xduckmove618
    Dà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

    8
  • MarlKey.Peera.
    MarlKey61
    Dành choSuiApr 30, 2025

    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.

    7
    3