Startseite

Gon40

Aug 23, 2025

Artikel

Sui Introduces Passkey: Seamless Web3 Onboarding and Developer Integration The Sui ecosystem has unveiled passkey support on Mainnet, a breakthrough designed to make Web3 access as simple as logging into your favorite mobile app. With passkey, users can sign in using familiar methods like Face ID, fingerprint recognition, or a device passcode, eliminating the need for browser extensions, seed phrases, or complicated setup flows. This isn’t just a quality-of-life upgrade. It represents a paradigm shift in blockchain usability, aligning the Sui experience with the same authentication standards that already power billions of daily logins across the internet. What is a Passkey? A passkey is a cryptographic credential that leverages device-native authentication. Instead of managing private keys or recovery phrases, users access applications with biometrics or passwords already supported by their phones, laptops, or hardware devices. Built on open standards:* Passkey follows the *FIDO Alliance* and *W3C WebAuthn** specifications. Widely supported:** Apple, Google, and Microsoft all support passkeys across their platforms. Secure and recoverable:* Because credentials can be *cloud-synced**, users can restore access when switching devices—without awkward recovery phrases. By integrating this model, Sui makes blockchain access feel familiar, intuitive, and as frictionless as signing into a banking or email app. Why Passkey Matters For Users Passkey removes many of the biggest barriers to blockchain adoption: No more seed phrases to memorize. No browser extensions to install. Authentication flows that feel just like Web2 apps. Enhanced recovery thanks to cross-device syncing. Support for advanced setups like multisig wallets or pairing passkeys with zkLogin for layered security. The experience is especially powerful on mobile, where the complexity of traditional wallets has long been a blocker to mainstream adoption. For Developers Passkey also reshapes the developer landscape: Direct integration:** Apps no longer need to depend on third-party wallets for onboarding. Lightweight setup:** Passkey support is built into the Sui TypeScript SDK. Advanced capabilities:** Developers can enable QR-based cross-device login, multisig authentication, and native biometric login. Better retention:** Reducing setup friction lowers user drop-off rates during onboarding. Building with Passkey on Sui The Sui TypeScript SDK introduces the PasskeyKeypair class to make integration straightforward. Developers can create, recover, and use passkeys with just a few lines of code. Importing the PasskeyKeypair import { BrowserPasskeyProvider, BrowserPasswordProviderOptions, PasskeyKeypair, } from '@mysten/sui/keypairs/passkey'; Creating a New Passkey To initialize a passkey wallet tied to your app’s domain: const keypair = await PasskeyKeypair.getPasskeyInstance( new BrowserPasskeyProvider('Sui Passkey Example', { rpName: 'Sui Passkey Example', rpId: window.location.hostname, authenticatorSelection: { authenticatorAttachment: 'cross-platform', // or "platform" }, } as BrowserPasswordProviderOptions), ); cross-platform**: Works with hardware keys and mobile devices. platform**: Uses device-bound authenticators like Touch ID, Face ID, or Windows Hello. It’s recommended to cache the PasskeyKeypair in your frontend so the public key is always available when signing transactions. Recovering a Passkey If the cached keypair is lost or the user switches devices, recovery is possible: let provider = new BrowserPasskeyProvider('Sui Passkey Example', { rpName: 'Sui Passkey Example', rpId: window.location.hostname, } as BrowserPasswordProviderOptions); const testMessage = new TextEncoder().encode('Hello world!'); const possiblePks = await PasskeyKeypair.signAndRecover(provider, testMessage); const testMessage2 = new TextEncoder().encode('Hello world 2!'); const possiblePks2 = await PasskeyKeypair.signAndRecover(provider, testMessage2); const commonPk = findCommonPublicKey(possiblePks, possiblePks2); const keypair = new PasskeyKeypair(commonPk.toRawBytes(), provider); With two signed messages, a unique public key can be reconstructed. Alternatively, apps can prompt users to sign one message and resolve the correct public key by checking on-chain activity. Using PasskeyKeypair Once initialized, usage mirrors any other keypair in the SDK: const publicKey = keypair.getPublicKey(); const address = publicKey.toSuiAddress(); const message = new TextEncoder().encode('hello world'); const { signature } = await keypair.signPersonalMessage(message); const txSignature = await passkey.signTransaction(txBytes); Full implementation examples are available in the MystenLabs passkey repo. Supported Platforms Sui’s passkey implementation works with any device that complies with WebAuthn. That includes most modern browsers and operating systems on both desktop and mobile. Developers and users can reference the Passkeys.dev device support list for a breakdown of compatible platforms and authenticators. Nimora: The First Passkey Wallet The first real-world wallet to support passkeys on Sui is Nimora. It demonstrates how seamless onboarding and transaction signing can feel when blockchain fades into the background, letting users interact as naturally as they would with any modern app. Looking Ahead The launch of passkey is more than a feature—it’s a glimpse of the future. Just as the web moved from clunky logins to biometric and single sign-on systems, Web3 is undergoing its own transformation. By prioritizing both security and simplicity, Sui is setting a new industry standard. If widely adopted, passkeys could finally relegate seed phrases and confusing onboarding flows to blockchain’s early history. For users, it’s effortless access. For developers, it’s a lighter integration path. For Web3, it’s a necessary evolution toward mass adoption.

Neeola15

Aug 23, 2025

Artikel

Sui’s transparent ledger raises privacy concerns for users and businesses. Step-by-step solution: Use zkLogin: Enable anonymous logins without exposing keys. Implement Private Objects: Devs: Use dynamic fields for hidden data. Mixing Services: Integrate mixers like Tornado (adapted for Sui). Audit for Leaks: Check contracts for address exposures. Layer 2 Solutions: Explore privacy-focused L2 on Sui. Educate Users: Promote best practices like new addresses per tx.

OYETUNJI HELEN 15

Aug 23, 2025

Artikel

1) Why Sui is different (the mental model) Sui is a Layer-1 blockchain built around an object-centric data model and the Move programming language (a resource-oriented language). Instead of thinking in terms of “accounts with balances,” think in terms of objects that have owners, types, fields, and versions. Transactions create, mutate, or transfer objects. This model enables Sui to parallelize many transactions safely: when two transactions touch disjoint sets of objects, they can execute concurrently, yielding high throughput and low latency. Key mental shifts: Objects, not global state. Most data you work with (coins, NFTs, game items, marketplace listings) are objects with an owner. Owned vs. Shared objects. Owned objects are controlled by a single address and can be mutated without global consensus (fast path). Shared objects are visible to many users and require stronger coordination (consensus path). Capabilities (witness pattern). Many privileged operations require a special object (“capability”) that proves the caller is allowed to do the action (e.g., minting, administration). 2) Install and configure your environment Install Sui CLI. Download binaries for your OS or build from source (official docs). Create a keypair & address. sui client new-address ed25519 sui client addresses Set your active network (devnet/testnet/mainnet). sui client switch --env testnet Fund your address (dev/test). Use the official faucet to get test SUI (the coin used for gas and storage). Verify connection. sui client gas You should see one or more gas coins (they are just coin objects) with balances. Common setup problems & step-by-step fixes Problem A: “GasBalanceTooLow” or “Insufficient gas” Cause: Not enough SUI in your gas coin, or your gas budget is too low for the transaction. Fix (step-by-step): Request more test SUI (if on dev/test). Increase gas budget in your command (e.g., --gas-budget 100000000). If you have many small coins, merge them first: sui client merge-coin --primary-coin --coin-to-merge --gas-budget 50000000 Then use the larger coin as your gas coin in subsequent transactions. Problem B: “Object version mismatch” or “Reference input is not the latest” Cause: Another transaction updated the object after you fetched it. Fix (step-by-step): Re-fetch the object to get the latest version: sui client object Re-run your transaction using the updated object reference. If this keeps happening, your workflow is likely racing with others use a fresh read right before submit, or switch to an owned object workflow where possible. Problem C: “Module/Function not found” when calling Move functions Cause: Wrong package ID, wrong module or function name, or the package wasn’t published successfully. Fix (step-by-step): Confirm publish success and copy the package ID from the CLI output. List modules: sui client package --id Double-check your function is public entry and that you’re passing the correct type parameters and arguments. Problem D: “Capability not found” (e.g., TreasuryCap) Cause: You’re calling a privileged function that requires a capability object your signer doesn’t own. Fix (step-by-step): Identify the capability type from the Move code (e.g., TreasuryCap for minting a custom coin). Find the object: sui client objects --address | grep If you don’t have it, get it from the deployer/owner or run the module initializer that issues it to your address. 3) Understanding Sui coins, gas, and storage SUI is a coin object. You can split, merge, and transfer it like any other object. Gas fee is paid in SUI and depends on computation + storage. Storage fund. On Sui, storage is accounted explicitly; deleting data can yield storage rebates. Step-by-step: consolidate tiny coins before heavy ops List your coins: sui client gas Pick a primary coin with the largest balance. Merge smaller coins into it (as shown above). Use that primary coin as the --gas coin for your big transaction. 4) When to use shared objects (and how to avoid pain) Use shared objects only when many users must safely coordinate over the same state (e.g., a global order book). Otherwise, prefer owned objects for speed and simpler conflict management. Typical shared-object problems & solutions High contention / frequent conflicts. Solution: Shard your state into multiple shared objects, or redesign so each user mostly touches owned state. Permission confusion. Solution: Wrap privileged actions behind capabilities that the admin or creator owns. Expose public read-only functions; isolate mutability. 5) Debugging transactions like a pro Inspect effects: After a transaction, review Created, Mutated, Deleted, Events in the CLI output. Query objects: sui client object to verify current owner and version. Query events: Filter by package or sender to trace complex flows. Reproduce locally: Use a stable test script (CLI or SDK) to reproduce before/after states. Checklist before you ask for help Do you have the correct package ID and module/function names? Are you using the latest object version? Is your function marked public entry? Do you own/hold the required capability? Is your gas budget large enough and coin consolidated? Article 2: Build & Ship Your First Sui Move dApp (End-to-End, With Fix-As-You-Go Tips) 1) Create a new Move package sui move new hello_sui cd hello_sui This scaffolds a Move package with a sources/ directory. 2) Write a simple Counter module (owned object) Create sources/counter.move: module ::counter { use std::error; use std::option; use sui::object; use sui::transfer; // A simple counter that is owned by a single address. struct Counter has key { id: UID, value: u64, owner: address, } // Error codes const ENotOwner: u64 = 1; /// Initialize a counter owned by the signer; returns the created object. public entry fun init(signer: &signer): Counter { let id = object::new(); let c = Counter { id, value: 0, owner: signer::address_of(signer) }; c } /// Increment the counter; only the owner may call. public entry fun inc(counter: &mut Counter, signer: &signer) { let caller = signer::address_of(signer); if (counter.owner != caller) { abort ENotOwner }; counter.value = counter.value + 1; } /// Transfer ownership to another address. public entry fun transfer(counter: Counter, to: address) { transfer::transfer(counter, to); } /// Read-only getter (callable by anyone off-chain via RPC simulation or SDK). public fun value(counter: &Counter): u64 { counter.value } } Build & test locally sui move build sui move test If build fails with dependency errors: confirm Move.toml has correct addresses and dependencies; run sui move build again after fixing. If tests fail: ensure test functions use Move test framework patterns (in #[test] functions or similar). 3) Publish your package sui client publish --gas-budget 100000000 Copy the Package ID from the output. Common publish issues & solutions “Unbound address / address mismatch.” Ensure the address in Move.toml matches your active signer address (or use the named address pattern recommended in the docs). “Insufficient gas.” Merge coins, increase --gas-budget, or fund your account again (on testnets). 4) Create & mutate your Counter Init (create the object, returned as an Owned object): sui client call \ --package \ --module counter \ --function init \ --args \ --gas-budget 50000000 The result will show a Created object of type ::counter::Counter. Increment (mutate in place): Fetch the object ID: sui client object Call: sui client call \ --package \ --module counter \ --function inc \ --args \ --gas-budget 50000000 Transfer to another address: sui client call \ --package \ --module counter \ --function transfer \ --args \ --gas-budget 50000000 Troubleshooting the calls (step-by-step) “Non-entry function” error: Ensure your callable functions are marked public entry. “Type argument mismatch.” Some functions require explicit type parameters; check the signature and supply --type-args if needed (not used in this simple example). “Object not found” or “No such ID.” You likely copied the wrong ID or the object was transferred/deleted. Re-query: sui client objects --address sui client object “Sender not owner” (our custom error): You’re not the owner field of the object. Use the correct signer or transfer it to yourself first. 5) Interact using the JavaScript/TypeScript SDK (pattern) Install in your dApp: npm install @mysten/sui.js Example pattern (simplified): import { Ed25519Keypair } from '@mysten/sui.js/keypairs/ed25519'; import { Connection, JsonRpcProvider } from '@mysten/sui.js'; import { TransactionBlock } from '@mysten/sui.js/transactions'; const provider = new JsonRpcProvider(new Connection({ fullnode: 'https://' })); // Load your keypair (NEVER hardcode secrets in production) const keypair = Ed25519Keypair.deriveKeypair("some test mnemonic"); const address = keypair.getPublicKey().toSuiAddress(); async function incCounter(packageId: string, counterId: string) { const tx = new TransactionBlock(); tx.moveCall({ target: ${packageId}::counter::inc, arguments: [tx.object(counterId), tx.pure.address(address)], }); tx.setGasBudget(50_000_000); // sign & execute with your signer (left out here for brevity) } SDK gotchas & solutions Serialization errors (BCS). Make sure argument types and order exactly match your Move function signature (e.g., object references vs. pure values). Gas estimation too low. Explicitly set a larger gas budget during development to avoid surprises; fine-tune later. 6) Evolving your design: when to go shared If many users must update the same counter (e.g., a communal scoreboard), consider a shared object: Create an admin-only initializer that produces a shared counter. Add access control via capabilities to prevent arbitrary mutations. Expect higher contention; design for it (sharding, batched updates, or per-user owned counters aggregated off-chain). Step-by-step migration path Start with owned counters per user (fast, parallel). Emit events on increments. Aggregate events off-chain to compute a global leaderboard. If you truly need on-chain global state, switch to a shared leaderboard object behind capability checks. Article 3: Gas, Storage, Object Design, and Security: A Practical Troubleshooting Playbook 1) Gas & storage deep dive Compute cost + storage cost = total gas burned. Large objects and repeated writes increase storage cost. Deleting data (or using smaller structs) can yield storage rebates. Step-by-step to reduce gas/storage Profile your transaction. Inspect the CLI’s transaction effects; note how many and which objects are mutated/created. Minimize writes. Prefer read-only patterns (return values) when possible. Batch related state inside a single object to avoid touching multiple objects but don’t make one giant hot object. Shrink data structures. Use compact fields and avoid storing redundant data on-chain; emit events instead and index them off-chain. Consolidate coins before heavy ops to reduce input overhead. Avoid unnecessary shared objects. Shared writes are more expensive and more likely to conflict. Common gas errors & fixes “Computation cost exceeded gas budget.” Increase --gas-budget, simplify the Move code path, or split your operation into multiple smaller transactions. “Insufficient gas object balance.” Merge small coins first, then retry with the consolidated coin. 2) Object versioning & concurrency conflicts Sui enforces that you mutate the latest version of an object. If two transactions try to mutate the same object concurrently, one will fail. Step-by-step conflict mitigation Re-read before write. Fetch the latest object version immediately before submitting the transaction. Use per-user owned objects. Design so that typical actions only touch the caller’s objects. Shard shared state. Instead of one global shared object, create multiple (e.g., one per category or per time window). Queue & batch off-chain. For high-contention flows, batch intended updates and submit them in controlled bursts. 3) Collections & dynamic data When you need per-user collections (e.g., many NFTs/items), consider patterns such as: Parent object + dynamic fields to map keys to child objects (lets you grow collections without rewriting the parent). Event-driven indexing off-chain for search, pagination, or analytics. Pitfalls & remedies Huge parent object mutation cost. Switch to dynamic fields so the parent remains mostly static. Complex lookups on-chain. Emit events and build off-chain indexes; keep on-chain lookups minimal. 4) Access control with capabilities (security by construction) Move’s resource model helps you encode permissions: Admin/Owner capability: Only callers with the resource can invoke privileged actions. Mint capability (e.g., TreasuryCap): Required to mint a custom coin. Witness types: Phantom types that prove a condition at compile time. Step-by-step to secure a privileged function Define a capability struct (has key if it must be storable). Issue it in an initializer to the creator/admin. Make privileged functions accept &Capability to prove authorization. Never expose a path for arbitrary users to obtain or forge the capability. 5) Testing, simulation, and safe iteration Unit tests (Move). Put tests in your package to cover error paths (abort codes) and invariants. Local simulation. Use CLI or SDK to dry-run transactions before submitting on a public network. Property tests / fuzzing (advanced). Build scripts that randomize inputs and assert invariants; catch edge cases early. Step-by-step test checklist Test happy path and failure (wrong owner, missing capability). Test edge values (0, max u64). Test idempotency where intended (repeated calls don’t corrupt state). Test access control (only the rightful owner/admin can mutate). Test upgrade path (if your package supports upgrades): ensure storage layout compatibility and proper capability migration. 6) Observability: events and off-chain indexing Emit events on meaningful state changes (created, updated, transferred). Off-chain, subscribe to events via RPC and build a lightweight indexer for search and analytics. Keep on-chain data lean; push aggregation and heavy querying off-chain. Typical indexing problems & solutions Missed events. Implement pagination & checkpointing in your indexer; re-scan ranges on restart. Out-of-order reads. Use transaction timestamps/checkpoints to impose order in your database. 7) Production readiness checklist Access control via capabilities no backdoors. Gas budgets tuned; large writes minimized; coins consolidated. Contention mitigated (owned objects favored; shared sharded). Monitoring: capture transaction results, events, and errors. Rollout plan: publish package, run canary clients, monitor, then scale.

D’versacy 20

Aug 23, 2025

Artikel

❓ The Problem Blockchains are immutable 🪨 …but real-world apps need to evolve: Bug fixes 🐞 UX improvements 🎨 Economic tweaks ⚖️ If you just redeploy a module or mutate live objects without a plan, you risk: 💥 breaking invariants 💥 trapping user assets 💥 mismatching client logic 👉 The solution: safe upgrade & migration strategies. 🚀 Upgrade Approaches — High Level Non-breaking changes ✅ Add new modules/types. Append non-critical fields. Clients that don’t care can ignore them. Breaking changes (with migration) 🔄 Publish new modules. Write explicit migration functions that convert old state into new types. Indirection & upgradeable references 🪞 Use pointers (like ImplPointer) that reference current logic. Upgrade by swapping the pointer to a new implementation. 🏗️ Safe Upgrade Design Patterns A. Indirection (proxy/pointer) pattern Create a small immutable ImplPointer object 🔑. Consumers read logic/data via this pointer. Upgrading = swapping pointer under admin capability (low contention). B. Versioned objects + migration helpers Publish ModuleV2. Add migrate(old_obj) function that consumes V1 objects and returns V2. Users or admins can trigger migration. C. Config & parameter objects Store parameters in isolated config objects ⚙️. Update them with admin capability. Emit events so off-chain indexers stay synced 📡. 🧭 Step-by-Step Migration Recipe Audit invariants 📋 — write down the rules that must always hold (balances, ownership). Design new schema ✏️ — decide what fields to keep, rename, or drop. Write migration function 🛠️ — consume old object → validate → create new one. Test on devnet 🧪 — with realistic data volumes. Provide opt-in path 🚪 — let users self-migrate when possible. Controlled bulk migration ⏳ — batch in steps, monitor, include rollback. Emit audit events 🔍 — every migration logs source/destination IDs + checksums. 🎨 Example: Changing Token Representation Old:** TokenV1 { owner: address, meta_hash: string } New:** TokenV2 { owner: address, meta_pointer: object::ID, issued_at: u64 } Migration function: Consumes TokenV1. Creates new metadata object. Returns TokenV2. Emits TokenMigrated event 📢. 🛡️ Operational Best Practices ✅ Limit admin power in hot paths (keep admin objects separate). ✅ Canary migration 🐤 — test on a small subset first. ✅ Backups & snapshots 💾 — off-chain state snapshots = safety net. ✅ Versioning metadata 🔢 — add version fields to objects for easier debugging. ⚠️ Pitfalls to Avoid ❌ Silent incompatible changes — never repurpose fields secretly. ❌ Single-point admin swap — use multisig for critical upgrades. ❌ Breaking client assumptions — always publish changelogs + SDK shims. ✅ Outcome With careful planning — indirection, versioned migrations, and solid testing — you can: Keep user assets safe 🔒 Evolve your app without breaking trust 🤝 Maintain a clear audit trail of changes 📜 Safe migration isn’t just a dev practice — it’s how you keep your Sui app alive and thriving 🌱.

Neeola15

Aug 23, 2025

Artikel

Transaction failures are a frequent hurdle in Sui, often due to gas shortages, equivocation (using the same coin for multiple tx), or shared-object conflicts. Sui’s parallel processing enables high TPS (up to 300,000 for simple tx), but complex interactions can fail, as seen in user reports of aborted tx from invalid inputs or overflows. These issues arise from Move language’s strict type system or network congestion, impacting DeFi swaps, NFT mints, and staking. Failures waste gas and time, eroding trust. Root causes include insufficient validation in contracts or user errors like reusing gas coins. Step-by-step solution to troubleshoot and prevent transaction failures: Diagnose the Error: Use Sui Explorer to input your tx hash and view details. Common codes: EInsufficientGas (low balance), EObjectLocked (equivocation). Check wallet logs for specifics. Verify Gas and Inputs: Ensure your wallet has >0.001 SUI for gas. In Sui Wallet, merge coins if fragmented. For devs, use SDK’s estimateGas to preview costs before submission. Avoid Equivocation: Select unique gas coins per tx. In code, implement coin selection logic to split/merge coins automatically. Test on Devnet. Handle Shared Objects: For conflicts, use Programmable Transaction Blocks (PTBs) to batch operations, reducing locks. Devs: Design with owned objects over shared for parallelism. Retry and Optimize: Resubmit with higher gas if failed. Optimize contracts by minimizing computations use unchecked math only if safe, as per Move guidelines. Audit and Test: Run unit tests with sui move test. Use linters for warnings on potential aborts. Post-failure, update contracts via upgrades.

Elmicki13

Aug 23, 2025

Artikel

Introduction to the Sui Blockchain – A Beginner’s Step-by-Step Guide Understanding the Problem with Traditional Blockchains Slow transaction speeds (Bitcoin averages 7 TPS, Ethereum 30 TPS). High fees during network congestion. Limited scalability as user adoption grows. Complex programming models for developers. What is Sui? A Layer-1 blockchain developed by Mysten Labs. Built using the Move programming language (originally from Facebook’s Diem project). Designed for speed, scalability, and low latency. Key Features Parallel Execution: Unlike Ethereum’s sequential model, Sui executes independent transactions in parallel. Object-Centric Model: Assets are treated as objects with unique IDs, making NFTs and gaming assets easier to manage. Sub-Second Finality: Transactions confirm in milliseconds, not minutes. Step-by-Step – Why Choose Sui? Step 1: Identify your use case (DeFi, NFT, gaming). Step 2: Compare throughput needs → Sui offers ~297,000 TPS in tests. Step 3: Consider cost efficiency → almost zero gas fees. Step 4: Plan development using Sui SDK and Move language. Real-World Example Imagine building a game where players trade swords, shields, and skins. On Ethereum, each trade costs gas and may take seconds. On Sui, each sword is an object, trading happens instantly, and fees are negligible. Conclusion Sui solves scalability, cost, and latency—making it a foundation for the next generation of blockchain apps.

dhaholar20

Aug 22, 2025

Artikel

Problem this solves: Apps slow down because they lump too much into single large objects. What you’ll learn: How to shard storage Dynamic fields as scalable indexes Trade-offs of fine vs coarse objects Step-by-step: Sharding NFT collections Root Collection object (shared). Dynamic fields for each NFT. Retrieval by ID → no scanning large lists.

dhaholar20

Aug 22, 2025

Artikel

Problem this solves: Developers overuse shared objects, causing consensus slowdowns. What you’ll learn: When shared objects are unavoidable How to design them for minimal contention Sharding patterns 1) Good use cases Orderbooks Auction houses Public registries 2) Bad use cases Per-user data Frequently updated counters 3) Sharding example Instead of one GlobalLeaderboard, create LeaderboardSeason1, LeaderboardSeason2, etc., each as separate shared objects.

dhaholar20

Aug 22, 2025

Artikel

Problem this solves: Teams sometimes don’t know what components a validator runs or how they fit together—leading to misconfigured testnets or wrong performance expectations. What you’ll learn: The internal modules of a Sui validator How networking, consensus, and execution coordinate Monitoring key metrics 1) Core components Narwhal worker: Handles incoming tx batches. Narwhal primary: Builds DAG, coordinates with other validators. Bullshark engine: Orders transactions when required. Execution engine: Runs Move VM on valid transactions. Storage subsystem: Manages persistent data. 2) Key metrics to watch Transaction throughput (TPS) Latency per category (owned vs shared) CPU usage per module Storage I/O 3) Deployment note Separate networking-heavy and execution-heavy workloads onto different hardware if scaling.