Главная

Neeola25

Aug 26, 2025

Статья

Network outages in blockchain systems like Sui can disrupt transactions, staking, and overall user experience, leading to lost opportunities and frustration. Sui, a Layer-1 blockchain designed for high-speed transactions, has experienced occasional downtime, such as a 2-hour halt in November 2024 due to a bug in transaction scheduling logic. This issue stemmed from software bugs in the consensus or execution layers, common in emerging blockchains pushing for scalability. While Sui boasts 100% uptime in normal operations, these rare events highlight the need for robust monitoring and redundancy. Outages can result from validator coordination failures, software updates, or external attacks, affecting DeFi protocols, NFTs, and dApps. Understanding the root causes—such as Mysticeti consensus glitches or execution bottlenecks—is key to prevention. For users, this means delayed transactions or failed wallet syncs; for developers, it can halt deployments. Step-by-step solution to mitigate and recover from network outages: Monitor Network Status Proactively: Start by subscribing to official Sui channels like the Sui Foundation’s Twitter or Discord for real-time alerts. Use tools like Sui Explorer or third-party monitors (e.g., from Shinami or BlockVision) to check block production rates. If downtime is detected (e.g., no new blocks for >5 minutes), avoid initiating transactions to prevent failures. Diversify Wallet and Node Usage: If you’re a user, switch to multiple wallets like Sui Wallet or Ethos, which often have built-in failover. For developers running nodes, set up a multi-region validator setup using AWS or Google Cloud, ensuring geographic diversity to bypass localized issues. Configure auto-failover scripts in your node software to reroute to healthy validators. Implement Retry Mechanisms in dApps: Developers should build exponential backoff retries in SDK integrations. For example, using the Sui TypeScript SDK, wrap transaction submissions in a try-catch loop with delays (e.g., 1s, 2s, 4s retries). Test this on Testnet to simulate outages. Engage Community and Validators: During an outage, join Sui’s forums or Telegram for community-driven fixes. If staking, redelegate to validators with high uptime (check Nakamoto coefficient, currently 18 for Sui). Post-outage, review validator reports to vote on governance proposals for protocol upgrades. Post-Outage Recovery: Once resolved (Sui outages typically fix in hours, as in the 2024 incident), resubmit failed transactions via wallet resend features. Audit your smart contracts for any state inconsistencies using Sui’s object-centric model to verify ownership. Prevent Future Issues: Contribute to Sui’s open-source repo on GitHub by reporting bugs. Adopt best practices like using Mysticeti’s fast consensus for non-shared objects to reduce execution delays. For long-term, integrate SCION security protocol (live on Testnet since 2024) to guard against routing attacks causing downtime. By following these steps, users can minimize impact, turning outages from crises into manageable events. Sui’s focus on parallel execution and object model reduces outage frequency compared to chains like Solana, but vigilance remains essential.

Neeola25

Aug 26, 2025

Статья

Wallet sync errors, like “Sync error (data might be outdated)” or RPC method not found, plague Sui users, especially during high activity or updates. These stem from mismatched chain states, outdated software, or node connection issues, as reported in early 2023. They prevent viewing balances, NFTs, or executing tx, frustrating new adopters. Sui’s object model requires accurate syncing for ownership verification. Step-by-step solution: Update Wallet Software: Enable Developer Mode in Sui Wallet and check for updates. Restart app post-update. Clear Cache and Resync: In wallet settings, clear cache or force resync. Switch RPC endpoints if default fails (use custom like Shinami). Check Network Connection: Ensure stable internet; use VPN if regional blocks. Test on Testnet first. Merge Objects if Needed: Fragmented coins cause sync lags—merge via wallet UI. Switch Wallets: Try alternatives like Ethos or Ledger for comparison. Report and Monitor: If persistent, report on Sui forums. Use explorers for manual checks. Wallet sync errors, like “Sync error (data might be outdated)” or RPC method not found, plague Sui users, especially during high activity or updates. These stem from mismatched chain states, outdated software, or node connection issues, as reported in early 2023. They prevent viewing balances, NFTs, or executing tx, frustrating new adopters. Sui’s object model requires accurate syncing for ownership verification. Step-by-step solution: Update Wallet Software: Enable Developer Mode in Sui Wallet and check for updates. Restart app post-update. Clear Cache and Resync: In wallet settings, clear cache or force resync. Switch RPC endpoints if default fails (use custom like Shinami). Check Network Connection: Ensure stable internet; use VPN if regional blocks. Test on Testnet first. Merge Objects if Needed: Fragmented coins cause sync lags—merge via wallet UI. Switch Wallets: Try alternatives like Ethos or Ledger for comparison. Report and Monitor: If persistent, report on Sui forums. Use explorers for manual checks.

D’versacy 54

Aug 26, 2025

Статья

Are you tired of dealing with errors when constructing transactions manually? 🤔 Do you want to learn how to build safe, composable transactions that can be executed reliably from your frontend or backend? 💻 Look no further! In this article, we'll dive into the world of transaction building with the SDK and provide you with step-by-step best practices and examples. Understanding Transaction Primitives 📚 Before we begin, let's cover the basics: Single-call transactions: Simple transactions that perform a single operation. Transaction blocks: Composed multiple operations that can be executed together. The Building Pattern 🔨 Here's a step-by-step guide to building transactions: Fetch necessary objects 📦 (e.g., coin, target object). Create transaction block 📝 (use SDK helper or raw payload). Set gas object and budget ⛽️ explicitly. Add signer(s) 👥 and required signatures (for multi-sig scenarios). Simulate locally 🤖 if SDK supports dry-run (to estimate gas). Submit and watch effects 📊. Example Skeleton 💻 Here's a TypeScript pseudo example: const tx = new TransactionBlock(); tx.moveCall({ target: "0x...::module::function", typeArgs: [], arguments: [arg1, arg2] }); tx.setGasBudget(1000); const signed = await wallet.signTransactionBlock({ transactionBlock: tx }); const resp = await provider.executeTransactionBlock({ transactionBlock: signed }); Error Patterns & Fixes 🚨 Don't get caught off guard by these common errors: Object not found: Fetch latest object refs, ensure object hasn’t been moved. Insufficient gas: Bump budget; estimate beforehand. Signature mismatch: Ensure signer account exactly matches object owner. Best Practices 💡 To ensure safe and reliable transactions: Use atomic transaction blocks for multi-step operations to avoid partial states. Always validate returned effects (success/failure, mutated objects). Keep transactions small: Cheaper, easier to reason about. By following these best practices and understanding transaction primitives, you'll be well on your way to building safe, composable transactions with the SDK. Happy building! 🚀 Summary 📝 Understand transaction primitives (single-call transactions and transaction blocks) Follow the building pattern (fetch objects, create transaction block, set gas, add signers, simulate locally, submit and watch effects) Use best practices (atomic transaction blocks, validate returned effects, keep transactions small) With these tips and tricks, you'll be a pro at transaction construction and signing with the SDK in no time!

OYETUNJI HELEN 25

Aug 26, 2025

Статья

1) Concurrency & Throughput The problem: You want high throughput, but your design forces sequential access (everything in one shared object). Why it happens: Sui parallelizes transactions that touch disjoint objects. A single “global counter” or monolithic registry becomes a bottleneck. Step-by-step solution: Prefer owned objects for per-user state. Each user’s actions then parallelize naturally. Sharding pattern for shared state: Create multiple shared “buckets” (e.g., 256 shards by hash of a key). Route writes to the appropriate shard so contention remains low. Use dynamic fields on parent objects to create scalable per-key storage without ballooning a single central structure. Emit events for discovery; avoid centralized indexes inside a single shared object. Quick check: If your hottest function always touches the same object, refactor to spread the load. 2) Gas Strategy & User Experience The problem: Users hit “insufficient gas,” abandoned flows, or churn because they don’t understand coin objects. Step-by-step solution: Proactively merge dust: Offer a one-click “Consolidate SUI” in your UI (call merge-coin under the hood). Set predictable gas budgets: Benchmark your calls on testnet; choose a budget that covers p95 costs with headroom. Sponsored transactions (pattern): For onboarding or promos, sponsor gas server-side so users can try the app without pre-funding. Implement rate limits and abuse checks. Batch where possible: If users perform repeated micro-updates, consider a single “commit” call that processes many changes inside the Move entry function. Common gotcha: A wallet may pick a tiny coin as gas, causing failure. Let users select the gas coin or auto-choose the largest one. 3) Storage Costs, Rebates, and Object Lifecycle The problem: Storage bloat increases costs; you’re not reclaiming value from deleted data. Sui concept: When you store data on-chain, you pay; when you delete it, Sui’s economics can return a storage rebate. Step-by-step solution: Design with deletion in mind: Provide admin/user functions to reclaim obsolete objects (receipts, expired orders, draft states). Use compact data formats: Favor IDs and indices over large blobs inside objects; store bigger assets off-chain + on-chain references/hashes. Batch cleanup: Periodically run maintenance transactions that delete or compress inactive data and claim rebates. Track storage over time: Monitor object counts and average sizes; set alerts when growth deviates from plan. 4) Safe Access Control with Capabilities The problem: “Who is allowed to call this mutation?” Without strict access control, your app can be griefed. Step-by-step solution: Mint a capability object at initialization (e.g., AdminCap). Require &AdminCap (or ownership of it) in entry points that change critical state (fees, parameters, emergency pause). For per-user rights, encode capabilities tied to the user’s address or object so they can’t be misused by others. Avoid reliance on msg.sender-style checks: Move’s type system and capabilities are safer and more explicit. Bonus: Log every privileged change with events for transparency. 5) Data Modeling with Dynamic Fields The problem: You need a map (key → value) attached to some parent (like a marketplace, inventory, or profile) that can grow without locking a giant object. Step-by-step solution: Create a parent object (owned or shared) that will hold your dynamic fields. Use dynamic fields to store key-value pairs under that parent. Access by key in your entry functions; emit events so your indexer/front end can find additions/updates quickly. Garbage-collect old entries to control storage. Result: Massive scalability without contention on a single oversized object. 6) Shared Objects Without the Pain The problem: You must coordinate global state (auctions, order books, on-chain games) but shared objects introduce contention and complexity. Step-by-step solution: Minimize shared state: Keep only what truly needs to be global (e.g., root registry, epoch parameters). Layer your design: Global shared registry → points to many child owned objects or sharded shared objects. Make writes small: Avoid heavy computation or large writes on shared objects; push per-user data to owned objects. Use events as append-only logs for activity feeds instead of mutating large arrays on a shared object. 7) Testing, Fuzzing, and Failure Paths The problem: Code works in happy-path tests but fails in production edge cases. Step-by-step solution: Unit tests with sui move test: Cover not only success but expected failures (bad caller, missing capability, zero amounts, overflow). Property testing/fuzzing (where available): Assert invariants: balances never go negative, counts don’t overflow, capabilities aren’t leaked. Simulate high contention: Run parallel calls against your shared objects to observe conflicts and tune the design. Production tip: Add telemetry to record failed error codes and parameters. That’s your roadmap to hardening. 8) Upgrades, Versioning, and Migrations The problem: You need to upgrade logic without breaking data. Step-by-step solution: Keep the upgrade capability safe after your first publish. Design for migration: Versioned structs (e.g., V1, V2) and explicit migration functions. Emit an event when migration completes. Dry-run on testnet/devnet: Publish the upgrade, run migrations on sample data, measure gas/time. Announce a maintenance window (even though chain is live) so users expect temporary quirks. Common pitfall: Changing a struct layout without providing a way to transform old objects. Always ship migration entry points with the upgrade. 9) Indexing for Real-World Frontends The problem: Your UI needs fast queries (“show my positions”, “my NFTs”, “order history”) but raw node APIs can be slow/awkward for complex filters. Step-by-step solution: Design event schemas first (think: what will the UI need to filter by?). Run or use an indexer to ingest events and object changes into a queryable store (SQL/GraphQL). Keep deterministic IDs and include them in events so frontends can deep-link into any object. Backfill and reorg handling: Make your indexer idempotent; store last processed checkpoint; be able to rebuild from genesis if needed. 10) NFT & Game Patterns (high-churn objects) The problem: Many mint/burn/transfer operations lead to fragmentation and gas surprises. Step-by-step solution: Lazy metadata: Keep heavy assets off-chain with content hashes on-chain. Batch minting: Group operations under a single entry call when possible. Ownership first: Favor owned NFTs; only share when game rules need global coordination. Inventory using dynamic fields: Parent “Account” object → entries for each NFT/item for scalable lookups. 11) Incident Response & Kill Switches The problem: A bug or exploit requires immediate action. Step-by-step solution: Admin capability must allow: Pausing sensitive entry points, Freezing minting or withdrawals, Rotating authorities. Emergency playbook: Prewrite a runbook (who does what, where the keys are, how to communicate). Post-mortem discipline: Publish timelines, fixes, and compensations if applicable. Add tests preventing the same class of bug. 12) Developer Quality of Life The problem: Friction slows teams. Step-by-step solution: Makefiles or npm scripts to wrap common CLI actions (build, test, publish, call). Templates for new modules and events so patterns stay consistent. Pre-commit hooks to format Move code, lint, and run unit tests. Environments as code: Store RPCs, package IDs, and object IDs per-env in a small config file the app can read. 13) Launch Checklist (copy/paste) All critical functions require the correct capability. Shared objects are minimal; hot paths avoid contention. Gas budgets tested at p95/p99; UX merges dust automatically. Events cover every important state transition. Indexer tested from clean slate and resilient to retries. Upgrade capability secured; migration plan rehearsed. Storage cleanup tools exist; rebates recoverable. Runbooks for incidents and communications prepared.

OYETUNJI HELEN 25

Aug 26, 2025

Статья

Sui is a high-performance Layer-1 blockchain designed around objects instead of plain account balances. That design unlocks fast, parallel transaction execution, low latency, and developer-friendly patterns using Sui Move, a safety-focused smart-contract language. This article walks you through Sui from zero to a deployed contract, while solving common problems you’ll hit along the way. 1) What Makes Sui Different (and why you should care) The challenge: Many new builders arrive with an “account + balances” mental model (like UTXOs or EVM) and get confused by Sui’s object approach. The fix learn the three pillars: Objects: Everything is an object with an ID and version: coins, NFTs, game characters, vaults, etc. Ownership: Objects are either owned (by an address), shared (globally accessible), or immutable. Move: Sui Move defines and enforces how objects can be created, mutated, transferred, or shared. Result: Clearer state transitions, safer code, and parallel execution when transactions touch independent objects. 2) Set Up Your Environment The challenge: Environment setup can block newcomers (wrong binaries, PATH issues, RPC config). Step-by-step solution: Install the Sui CLI Download a prebuilt binary for your OS or build from source. Verify: sui --version If the shell can’t find sui, add its folder to your PATH. Pick a network Sui provides devnet/testnet (for practice) and mainnet (for production). Configure your client: sui client Follow prompts to set an RPC and create or import keys Create or import a wallet You can use the CLI keypair or a browser wallet (e.g., Sui Wallet). On testnet/devnet, request faucet tokens (SUI coins for gas). Common problem & fix: “RPC not reachable.” Ensure you copied the RPC URL correctly, your internet is up, or try a different public RPC. 3) Understand Sui Coins & Gas (and avoid fee headaches) The challenge: On Sui, gas is a coin object, not just a number. You might have many small coins after transactions. Step-by-step solution: Check coins: sui client gas Merge tiny coins into one big gas coin (to avoid “insufficient gas” or “too many coins” issues): sui client merge-coin \ --primary-coin \ --coin-to-merge Split a coin (handy for payments or funding multiple calls): sui client split-coin \ --coin-id \ --amounts 100000000,200000000 Common problem & fix: “Insufficient gas budget.” Increase --gas-budget on your command, merge coins, or request more faucet SUI on testnet/devnet. 4) Scaffold Your First Sui Move Package The challenge: Structuring a project and compiling Move modules. Step-by-step solution: Create a new package: sui move new hello_sui cd hello_sui Explore the layout: Move.toml — package metadata and dependencies. sources/ — your .move modules. Write a simple module (conceptual example): module {{addr}}::counter { use sui::object::{Self, UID}; use sui::tx_context::{Self, TxContext}; use sui::transfer; public struct Counter has key { id: UID, value: u64, } /// Create a new counter owned by the signer public entry fun create(ctx: &mut TxContext) { let c = Counter { id: object::new(ctx), value: 0 }; transfer::transfer(c, tx_context::sender(ctx)); } /// Increment an owned counter public entry fun inc(c: &mut Counter) { c.value = c.value + 1; } /// Share it so anyone can increment (global state) public entry fun share(c: Counter) { transfer::share_object(c); } } Note: This is a simplified example to illustrate patterns: creating an object, mutating it, and sharing it. Build & test locally: sui move build sui move test Common problem & fix: “Unresolved address or dependency.” Add needed dependencies to Move.toml and check versions. Re-run sui move build. 5) Publish Your Package The challenge: First-time publishers hit gas or path issues. Step-by-step solution: Publish to the selected network: sui client publish --path . --gas-budget 100000000 Record the output: Package ID (where your modules live). Upgrade capability (keep it safe if you plan upgrades). Common problem & fix: “Object not found/version mismatch.” Fetch the latest state before calling functions: sui client object 6) Call Functions & Interact The challenge: Knowing how to pass object IDs and arguments. Step-by-step solution: Create your object: sui client call \ --package \ --module counter \ --function create \ --gas-budget 10000000 Save the new Counter object ID from the output. Increment (owned object): sui client call \ --package \ --module counter \ --function inc \ --args \ --gas-budget 10000000 Share it (turn into globally accessible state): sui client call \ --package \ --module counter \ --function share \ --args \ --gas-budget 10000000 Common problem & fix: “Mutable reference required.” Ensure your function signature expects &mut for mutation and you’re passing an owned object, not an immutable/shared one. 7) Events & Indexing (so your UI can find data) The challenge: Frontends need reliable ways to find on-chain state and history. Step-by-step solution: Emit events in your Move code (e.g., event::emit(...)) for state changes you want to observe. Query events from your backend or indexer to build feeds, histories, or analytics. Use dynamic fields when you need scalable per-object maps (e.g., inventories, registries) without bloating a single big object. Common problem & fix: “Can’t find my object via simple queries.” Rely on events and dynamic fields to create predictable discovery paths. 8) Upgrades & Migrations The challenge: Evolving your app without bricking state. Step-by-step solution: Keep the upgrade capability from initial publish. Design for upgrades: separate logic/storage modules and keep a migration plan (events help you coordinate off-chain). Test upgrades on testnet/devnet before mainnet. Run migration calls to adjust objects to the new schema. Common problem & fix: “Missing upgrade authority.” Only the holder of the upgrade capability object can upgrade. Store it securely. 9) Security Checklist (baseline) Use capabilities for admin or privileged flows. Minimize shared object usage unless you need global coordination. Prefer owned objects for user-specific state. Validate inputs, bounds-check numbers, and think carefully about who can mutate what. Add tests for failure paths (sui move test). 10) Shipping to Production The challenge: Going live safely. Step-by-step solution: Audit your modules (peer review + formal tools if possible). Pin exact dependency versions in Move.toml. Set monitoring: track events, gas usage, and error rates. Document object lifecycles and provide user-visible error messages in your UI. You made it! You now understand the object model, created a package, published it, interacted with objects, and learned the key patterns (gas, events, upgrades). That’s the foundation for every Sui app you’ll build next.

Neeola25

Aug 26, 2025

Статья

Sui was developed by Mysten Labs and launched with a focus on scalability, low latency, and programmability. Unlike traditional blockchains that rely on global ordering of all transactions, Sui introduces a novel object-centric data model. This model allows parallel execution of transactions, making it suitable for web3 gaming, decentralized finance (DeFi), NFTs, and other high-performance dApps. Key Highlights: Layer-1 Blockchain: Built from the ground up with horizontal scalability in mind. Move Programming Language: A secure and expressive language for writing smart contracts. Fast Finality: Transactions can finalize in sub-second times when consensus is not required. Ownership-Centric Model: Each piece of data is an object, enabling a simpler mental model for asset tracking.

D’versacy 54

Aug 25, 2025

Статья

Compiling, Testing, and Continuous Integration for Sui Developers Problem: You can write Move smart contracts and a TypeScript frontend, but getting them to work together in a clean, automated workflow is messy. You probably juggle between CLI commands, manual builds, and fragile test setups — which makes bugs slip into production. 😩 Goal: Build a deterministic pipeline where everything flows: ➡️ Compile Move packages → ✅ Run Move unit tests → 🔗 Run TypeScript integration tests → 🤖 Automate in CI/CD. This guide shows you how to set up a bulletproof workflow for Move + TypeScript projects on Sui. 1) Local build and test flow ⚡ Before you even think about CI, you need a reliable local loop: Move compilation sui move build --path ./move Compiles your Move modules. Produces bytecode + ABI → which your frontend/SDK consumes. Run Move unit tests sui move test --path ./move Executes #[test] functions in your Move modules. Great for logic validation without deploying. Export artifacts for frontend Keep outputs in build/ or artifacts/. Your TypeScript SDK should always reference ABI from this build (not a stale copy). 👉 Local rule of thumb: Never commit frontend code pointing at an old ABI. Always recompile after Move changes. 2) TypeScript integration testing 🧑‍💻 Once Move logic compiles, test it end-to-end with your frontend: Add a testing framework: npm i --save-dev jest ts-jest @types/jest (or use Mocha if you prefer). Connect to local devnet or a dockerized testnet: CI can spin this up. Local devnet ensures deterministic state. Example test (Jest): import { JsonRpcProvider, devnetConnection } from "@mysten/sui.js"; const provider = new JsonRpcProvider(devnetConnection); test("fetch coin objects", async () => { const objects = await provider.getOwnedObjects({ owner: "0x123..." }); expect(objects.length).toBeGreaterThanOrEqual(0); }); Use fixture accounts: Pre-fund them with devnet faucet or seed via CLI. Keeps tests reproducible. 💡 Tip: Write tests for both happy paths and error paths. Don’t just test “success” — test insufficient gas, invalid ownership, etc. 3) CI Setup (GitHub Actions Example) 🤖 Now let’s automate it! A minimal GitHub Actions pipeline: name: CI on: [push, pull_request] jobs: build-and-test: runs-on: ubuntu-latest steps: uses: actions/checkout@v3 name: Set up Node.js uses: actions/setup-node@v3 with: node-version: 18 name: Set up Rust uses: actions-rs/toolchain@v1 with: toolchain: stable name: Install dependencies run: npm ci name: Start Sui Devnet run: sui start --background name: Build Move run: sui move build --path ./move name: Run Move tests run: sui move test --path ./move name: Run TS tests run: npm test ✅ Steps: Install Node.js + Rust. Start local devnet. Build & test Move. Run TypeScript integration tests. 4) Determinism & caching ⚡🚀 CI should be fast and reliable. Speed it up with caching: Cache node_modules and Rust Cargo build artifacts. Persist Move build artifacts between steps. Use GitHub’s built-in actions/cache for smarter caching. 👉 This avoids re-downloading and rebuilding everything on each push. 5) Troubleshooting tips 🛠️ Even with CI, things can break. Here’s a quick guide: Node failing to start in CI** → Bump resources, ensure ports aren’t already used. ABI mismatch** → Always generate frontend ABI from exact sui move build used in deploy. Don’t copy-paste. Flaky tests** → Seed deterministic accounts, mock randomness where possible, isolate external dependencies. Slow pipeline** → Add caching layers, avoid reinstalling dependencies unnecessarily. Final Thoughts 🌟 By following this flow, you get: Move logic tested in isolation** ✅ Frontend verified against real contracts** 🔗 Automated CI/CD** that ensures every push is safe 🚦 The result? Confidence. Your contracts and dApps won’t break silently, and your team spends less time debugging “it works on my machine” problems. 🎯

Elmicki18

Aug 25, 2025

Статья

Introduction to Sui SDK and Its Role in Developer Productivity The Sui blockchain network is designed with scalability and performance in mind, but what makes it even more appealing to developers is its well-structured Software Development Kit (SDK). An SDK acts as a toolkit containing libraries, frameworks, documentation, and utilities that simplify the process of building decentralized applications (dApps). On Sui, the SDK bridges the gap between the blockchain’s technical complexity and the practical needs of developers. Why SDKs Matter In traditional development, coding directly on-chain requires dealing with complex APIs and raw transactions. This is inefficient and error-prone. The Sui SDK abstracts much of this complexity, allowing developers to focus on their application logic instead of low-level protocol details. Features of the Sui SDK Transaction Builders – Easily create and sign transactions without manually encoding every parameter. Smart Contract Deployment Tools – Deploy Move-based contracts with simplified commands. Event Handling – Subscribe to blockchain events for real-time responsiveness in dApps. Testing Frameworks – Run unit and integration tests before deploying to mainnet. Multi-language Support – While Move is core, SDKs often provide bindings for JavaScript, Rust, or Python. Developer Workflow with Sui SDK Install the SDK using package managers (e.g., npm for JavaScript). Initialize a new dApp project scaffold. Write smart contracts in Move. Use SDK utilities to deploy contracts and interact with them. Integrate with front-end frameworks (React, Next.js, etc.). Conclusion The Sui SDK is a critical enabler for innovation. By reducing technical overhead, it empowers developers to create scalable, user-friendly applications on Sui without needing to master every detail of blockchain internals.

D’versacy 54

Aug 25, 2025

Статья

Problem: You want to start building on Sui quickly but don’t know which SDK to pick, how to set up your environment, or how to create your first Move-backed app with a working local dev loop. Goal: Give a clear, minimal, reproducible local setup, walk through a first TypeScript + Move project, and point out common pitfalls — with fixes — so you can ship confidently. ✨ 1) Choose an SDK & language 🧭 TypeScript / JavaScript** — the go-to for dApp frontends and most tooling (RPC clients, transaction builders, wallet adapters). Rust** — good for native tooling, CLI helpers, or backend components that need low-level control. Move** — the smart-contract language used on Sui; you’ll write packages in Move and deploy them with the CLI. Recommendation: If you’re building a user-facing dApp, start with TypeScript for the frontend and add Move modules for your on-chain logic. Use Rust only if you need native performance or tooling. 2) Pre-requisites (local machine) ✅ Make sure you have: Node.js LTS (≥ 18) and npm or yarn. Rust toolchain (rustup) — if you’ll compile Move packages or use Rust tooling. Sui CLI (optional but recommended) — for local devnet, account management, build & publish of Move packages. A code editor like VS Code with Move & TypeScript extensions for syntax highlighting and linting. Quick tip: keep node, rust, and sui versions reasonably aligned — mismatched versions are a common source of friction. 3) Install Sui CLI (summary) ⚙️ On Unix-like systems (example pattern): sh Use the official Sui repo install instructions when available. If the script doesn’t exist, follow the repo README to build from source. 4) Initialize a TypeScript dApp — minimal reproducible project 🧩 Create project folder: mkdir sui-dapp && cd sui-dapp npm init -y Install the Sui TypeScript SDK: npm i @mysten/sui.js (Package name may vary with official registry — adjust if necessary.) Create index.ts: import { JsonRpcProvider, devnetConnection } from "@mysten/sui.js"; const provider = new JsonRpcProvider(devnetConnection); async function main(){ const version = await provider.getRpcApiVersion(); console.log("RPC version:", version); } main().catch(console.error); Run it with ts-node or compile with tsc then node. 5) Use a local Sui network for fast feedback 🧪 Start a local devnet with the Sui CLI (or use a community devnet). Local networks make iteration fast and deterministic. Create funded dev accounts using CLI commands or faucet scripts so you can sign and submit transactions while developing. Why local devnet? Faster feedback loops, deterministic tests, and safe experimentation without spending real assets. 6) Common pitfalls & fixes — the quick troubleshooting guide 🛠️ | Problem | Symptom | Quick Fix | | ---------------------------------- | ----------------------------------------------: | ------------------------------------------------------------------------------- | | Version mismatch | Transactions fail or RPC calls error | Align SDK & CLI versions; upgrade/downgrade to matching releases | | CORS / wallet connection | Wallet won’t connect in browser | Serve app on http://localhost; confirm wallet supports chosen network | | Gas confusions | Reverts with “insufficient gas” | Include a gas coin object and set a sensible gas budget; simulate when possible | | Object ownership errors | Move reverts, “object not found” or “not owner” | Verify Move function signatures, input object refs, and ownership rules | | Missing artifacts/ABI mismatch | Frontend expects different types | Always use the ABI from the exact sui move build output used in deploy | Extra troubleshooting tips Simulate transactions** before asking users to sign (where SDK supports it). Emit events** in Move to make runtime flows easier to debug from the frontend. Keep a mapping of Move abort codes → user-friendly messages for better UX. 7) Next steps — what to build after this guide 🔭 Create a minimal UI that: Connects to a wallet adapter, Signs a transaction, Displays owned objects and events. Learn Move basics: modules, resources, moveCall semantics, and how to compile & publish with sui move build / sui move publish. Add tests: sui move test for Move unit tests and Jest/Mocha integration tests using a local devnet. Quick checklist before you commit code ✅ [ ] Node, Rust, and Sui CLI installed and versions checked [ ] Local devnet running and seeded with dev accounts [ ] Frontend using the ABI/artifacts from the exact build used in Move deployment [ ] Transaction flows simulate successfully locally [ ] Meaningful error messages mapped to Move aborts