Articles

Educational materials & tutorials about Sui

Earn Your Share of 1000 Sui

Gain Reputation Points & Get Rewards for Helping the Sui Community Grow.

Posts

harry phan421
May 31, 2025
Article
Dissecting the Cetus Protocol Exploit on Sui
On May 22, 2025, a major exploit targeted Cetus Protocol on the Sui blockchain, resulting in an estimated $223 million in damages. This incident drew immediate attention across the ecosystem, especially from technical observers due to the unusual mechanics involved. What follows is a comprehensive analysis of the attack from flash swaps and tick manipulations to a silent vulnerability in overflow detection logic. https://suiscan.xyz/mainnet/tx/DVMG3B2kocLEnVMDuQzTYRgjwuuFSfciawPvXXheB3x The Setup The attacker initiated the exploit by using flash_swap to borrow a large amount of SUI tokens in exchange for haSUI. Unlike traditional flashloans, flash_swap in Cetus allows a user to receive token1 (SUI in this case) upfront and then repay token0 (haSUI) within the same transaction. This mechanism is central to the attacker’s setup. In this particular instance, the attacker successfully acquired 5.76 million SUI and was obligated to repay 10.02 million haSUI. But during this swap, the price of haSUI in the liquidity pool was manipulated drastically. The pool’s price was dropped from a tick representing a ratio of 1.056 to a tick so low that the price reached merely 0.0000009977—an enormous devaluation to 0.00009% of its original price. The price range corresponding to the tick range is: Strategic Liquidity Injection Following this price crash, the attacker used open_position to create a narrow-range liquidity position, choosing a highly specific tick range (tickLower: 300000, tickUpper: 300200). Within this manipulated environment, they injected an astronomical amount of liquidity: more than 10^34 units, all within the ultra-compressed price range created by the tick collapse. This was made possible by a seemingly innocuous function: get_amount_by_liquidity. Under normal conditions, this function calculates how much of token A and token B is needed to match a certain liquidity level. It does this using helper functions like get_delta_a, which relies on get_sqrt_price_at_tick. However, due to the manipulated current tick being -138185, and the chosen tick range being well outside that (starting at 300000), the logic path inside get_amount_by_liquidity ensured that calculations would pass through a vulnerable section of code where a left shift operation (checked_shlw) was involved. Overflow and Truncation: The Core Vulnerability Here’s where the exploit gets truly technical. The function checked_shlw is supposed to handle left-shifting a 256-bit number by 64 bits. In Solidity-like environments, such an operation is risky since it may overflow. This particular implementation attempted to detect overflows by checking whether the input exceeded a predefined threshold: 0xffffffffffffffff << 192. The actual threshold for detecting a safe shift by 64 bits should be 2^(256 - 64) - 1. However, (0xffffffffffffffff << 192) is larger than 2^192. This means that a carefully chosen input could bypass the overflow check by being below the threshold used in the code, but still large enough to cause an overflow during execution. he attacker supplied such an input, where the multiplication of liquidity and price difference overflowed silently, returning a much smaller value than intended—in fact, nearly zero. As a result, the protocol calculated that the attacker only needed to pay a trivial amount of token A—essentially one unit—to add massive liquidity to the pool. This miscalculation enabled the attacker to inject massive liquidity at no real cost. Subsequently, the attacker removed the added liquidity through remove_liquidity and completed the attack by paying the unpaid tokens of flash_swap through repay_flash_swap. The attacker made a profit of 5,765,124 SUI and 10,024,321 haSUI. Finally, the Cetus team fixed the vulnerability through two PRs: https://github.com/CetusProtocol/integer-mate/pull/6/files Cetus quickly released a patch on their integer-mate repository, with the first pull request attempting to refine the overflow detection. However, that initial fix was inadequate. It used a mask of 1 << 192, which still allowed edge-case values to slip through. A second pull request followed with a stricter comparison, checking that the input is greater than or equal to 2^192, ensuring proper bounds for safe left-shifting. Only with this correction was the vulnerability effectively mitigated. https://github.com/CetusProtocol/integer-mate/pull/7/files
- Sui
2
0xduckmove308
May 31, 2025
Article
Turning wallets into programmable, composable smart agents.
Account.tech is an open-source framework on the Sui blockchain that introduces Smart Accounts highly fl exible, secure, and customizable account objects that can execute on-chain actions through a modular, intent-based architecture. Think of it like programmable wallets with native support for multisig, DAO logic, scheduled execution, dynamic access control, and more. Why Smart Accounts? Traditional accounts are just passive containers. They hold assets and sign transactions. Smart Accounts are active, programmable entities that can define ownership logic, automate workflows, and manage assets based on rules. With Account.tech, these rules live on-chain, are customizable through Move modules, and are enforced via Intents. Key Concepts Smart Account Struct public struct Account has key, store { id: UID, metadata: Metadata, deps: Deps, intents: Intents, config: Config, } A Smart Account is a shared object containing: Metadata: descriptive info Deps – dependency packages used Intents – pending or active requests to perform actions Config – the custom ruleset (e.g., multisig, role-based, DAO logic) Each account has a unique Config module that determines how intents are resolved. Intent-Based Execution An Intent is a structured request to perform one or more on-chain actions. It progresses through 3 stages: [ ] Request the user creates the intent with actions [ ] Resolution – the config module checks if conditions are met [ ] Execution – anyone can execute the intent when it’s valid Example: a multisig intent to transfer funds will only execute once enough members have approved it. ⸻ Actions = Modular Execution Units Each action is a standalone Move struct, like: struct WithdrawAction { object_id: ID } struct TransferAction { recipient: address } You can compose multiple actions in one intent. For example: Withdraw → Transfer → Withdraw → Transfer This enables advanced workflows — like atomic swaps, batch transfers, time-based vault releases, etc. Config: Customizable Ownership Logic The Config type defines how intents are resolved. You can plug in logic such as: ✅ Multisig with weighted votes 🔐 Role-based access control 🗳 DAO voting logic ⏳ Time delays or recurring tasks 💾 Recovery flows Each intent tracks an Outcome, which represents resolution status (e.g., votes collected, approvals granted, etc.). Learn More 🔗 Docs: https://account-tech.gitbook.io/docs 🧑‍💻 GitHub: https://github.com/account-tech
- Sui
1
0xduckmove308
May 30, 2025
Article
BCS Encoding in Sui What It Is and Why It Matters
If you’re building on Sui or tinkering with Move, you’ve probably heard the term BCS floating around. That’s short for Binary Canonical Serialization formatting machine originally crafted for the Diem blockchain, and now a cornerstone of Move-based ecosystems like Sui, Aptos, Starcoin, and 0L. So yeah, you better get cozy with it if you’re serious about building in this space. What Is BCS? Binary Canonical Serialization (BCS) is a format used to serialize (encode) and deserialize (decode) structured data into bytes. You’ll see it used when: Encoding transactions before signing. Emitting or parsing events from the blockchain. Interacting with Move smart contracts off-chain via JavaScript. But BCS doesn’t include type information in the bytes. This means you must know the structure ahead of time when decoding unlike formats like JSON or Protocol Buffers, which are more self-describing. Key Features of BCS No Type Metadata The serialized output contains no hints about what types the fields are. You must know what you’re dealing with when you decode. Order-Dependent Serialization Structs are encoded in the exact order of their fields. Change the order, and your deserialization breaks. This is why peel_* functions in Move must match the struct’s layout 1:1. Generic Type In a struct like: struct BCSObject has drop, copy { id: ID, owner: address, meta: Metadata, generic: T } You can only deserialize reliably up to the meta field. Generic types mess with BCS parsing, so always put them last if you want your data to be safely decoded. Using BCS in JavaScript Thanks to the @mysten/bcs library, you can work with BCS in JS like a pro. npm i @mysten/bcs and basic example: import { BCS, getSuiMoveConfig } from "@mysten/bcs"; const bcs = new BCS(getSuiMoveConfig()); const ser = bcs.ser(BCS.U16, 10); console.log(ser.toBytes()); // [0x0a, 0x00] const des = bcs.de(BCS.U16, ser.toBytes()); console.log(des); // 10 You can also serialize vectors and strings: bcs.ser("vector", [1, 2, 3, 4]); // 04 01 02 03 04 bcs.ser(BCS.STRING, "test string"); // 0b7465737420737472696e67 Registering Custom Types Let’s say you have the following Move structs: struct Metadata has drop, copy { name: std::ascii::String } struct BCSObject has drop, copy { id: ID, owner: address, meta: Metadata } You can register them like this in JS: bcs.registerStructType("Metadata", { name: BCS.STRING, }); bcs.registerStructType("BCSObject", { id: BCS.ADDRESS, owner: BCS.ADDRESS, meta: "Metadata", }); Serialization & Deserialization Example JavaScript Serialization: const bytes = bcs .ser("BCSObject", { id: "0x0000000000000000000000000000000000000005", owner: "0x000000000000000000000000000000000000000a", meta: { name: "aaa" } }) .toString("hex"); console.log("Hex:", bytes); The output maybe: 0x0000000000000000000000000000000000000005000000000000000000000000000000000000000a03616161 This can now be passed into a Move contract or even manually tested in Sui CLI. BCS may look low-level and byte-heavy, but once you understand how it encodes data, you’ll unlock a deeper understanding of how Move smart contracts really tick — and how to bridge on-chain ↔ off-chain systems safely. And if you’re debugging BCS bytes on Sui Explorer (like the one below): BCS Encoding Binary Canonical Serialization, or BCS, is a serialization format developed in the context of the Diem blockchain, and is now extensively used in most of the blockchains based on Move (Sui, Starcoin, Aptos, 0L). BCS is not only used in the Move VM, but also used in transaction and event coding, such as serializing transactions before signing, or parsing event data. Knowing how BCS works is crucial if you want to understand how Move works at a deeper level and become a Move expert. Let's dive in. BCS Specification and Properties There are some high-level properties of BCS encoding that are good to keep in mind as we go through the rest of the lesson: BCS is a data-serialization format where the resulting output bytes do not contain any type information; because of this, the side receiving the encoded bytes will need to know how to deserialize the data There are no structs in BCS (since there are no types); the struct simply defines the order in which fields are serialized Wrapper types are ignored, so OuterType and UnnestedType will have the same BCS representation: struct OuterType { owner: InnerType } struct InnerType { address: address } struct UnnestedType { address: address } Types containing the generic type fields can be parsed up to the first generic type field. So it's a good practice to put the generic type field(s) last if it's a custom type that will be ser/de'd. struct BCSObject has drop, copy { id: ID, owner: address, meta: Metadata, generic: T } In this example, we can deserialize everything up to the meta field. Primitive types like unsigned ints are encoded in Little Endian format Vector is serialized as a ULEB128 length (with max length up to u32) followed by the content of the vector. The full BCS specification can be found in the BCS repository. Using the @mysten/bcs JavaScript Library Installation The library you will need to install for this part is the @mysten/bcs library. You can install it by typing in the root directory of a node project: npm i @mysten/bcs Basic Example Let's use the JavaScript library to serialize and de-serialize some simple data types first: import { BCS, getSuiMoveConfig } from "@mysten/bcs"; // initialize the serializer with default Sui Move configurations const bcs = new BCS(getSuiMoveConfig()); // Define some test data types const integer = 10; const array = [1, 2, 3, 4]; const string = "test string" // use bcs.ser() to serialize data const ser_integer = bcs.ser(BCS.U16, integer); const ser_array = bcs.ser("vector", array); const ser_string = bcs.ser(BCS.STRING, string); // use bcs.de() to deserialize data const de_integer = bcs.de(BCS.U16, ser_integer.toBytes()); const de_array = bcs.de("vector", ser_array.toBytes()); const de_string = bcs.de(BCS.STRING, ser_string.toBytes()); We can initialize the serializer instance with the built-in default setting for Sui Move using the above syntax, new BCS(getSuiMoveConfig()). There are built-in ENUMs that can be used for Sui Move types like BCS.U16, BCS.STRING, etc. For generic types, it can be defined using the same syntax as in Sui Move, like vector in the above example. Let's take a close look at the serialized and deserialized fields: ints are little-endian hexadecimals 0a00 10 the first element of a vector indicates the total length, then it's just whatever elements are in the vector 0401020304 1,2,3,4 strings are just vectors of u8's, with the first element equal to the length of the string 0b7465737420737472696e67 test string Type Registration We can register the custom types we will be working with using the following syntax: import { BCS, getSuiMoveConfig } from "@mysten/bcs"; const bcs = new BCS(getSuiMoveConfig()); // Register the Metadata Type bcs.registerStructType("Metadata", { name: BCS.STRING, }); // Same for the main object that we intend to read bcs.registerStructType("BCSObject", { // BCS.ADDRESS is used for ID types as well as address types id: BCS.ADDRESS, owner: BCS.ADDRESS, meta: "Metadata", }); Using bcs in Sui Smart Contracts Let's continue our example from above with the structs. Struct Definition We start with the corresponding struct definitions in the Sui Move contract. { //.. struct Metadata has drop, copy { name: std::ascii::String } struct BCSObject has drop, copy { id: ID, owner: address, meta: Metadata } //.. } Deserialization Now, let's write the function to deserialize an object in a Sui contract. public fun object_from_bytes(bcs_bytes: vector): BCSObject { // Initializes the bcs bytes instance let bcs = bcs::new(bcs_bytes); // Use peel_* functions to peel values from the serialized bytes. // Order has to be the same as we used in serialization! let (id, owner, meta) = ( bcs::peel_address(&mut bcs), bcs::peel_address(&mut bcs), bcs::peel_vec_u8(&mut bcs) ); // Pack a BCSObject struct with the results of serialization BCSObject { id: object::id_from_address(id), owner, meta: Metadata {name: std::ascii::string(meta)} } } The varies peel_* methods in Sui Frame bcs module are used to "peel" each individual field from the BCS serialized bytes. Note that the order we peel the fields must be exactly the same as the order of the fields in the struct definition. Quiz: Why are the results not the same from the first two peel_address calls on the same bcs object? Also note how we convert the types from address to id, and from vector to std::ascii::string with helper functions. Quiz: What would happen if BSCObject had a UID type instead of an ID type? Complete Ser/De Example Find the full JavaScript and Sui Move sample codes in the example_projects folder. First, we serialize a test object using the JavaScript program: // We construct a test object to serialize, note that we can specify the format of the output to hex let _bytes = bcs .ser("BCSObject", { id: "0x0000000000000000000000000000000000000005", owner: "0x000000000000000000000000000000000000000a", meta: {name: "aaa"} }) .toString("hex"); We want the BCS writer's output to be in hexadecimal format this time, which can be specified like above. Affix the serialization result hexstring with 0x prefix and export to an environmental variable: export OBJECT_HEXSTRING=0x0000000000000000000000000000000000000005000000000000000000000000000000000000000a03616161 Now we can either run the associated Move unit tests to check for correctness: sui move test You should see this in the console: BUILDING bcs_move Running Move unit tests [ PASS ] 0x0::bcs_object::test_deserialization Test result: OK. Total tests: 1; passed: 1; failed: 0 Or we can publish the module (and export the PACKAGE_ID) and call the emit_object method using the above BCS serialized hexstring: sui client call --function emit_object --module bcs_object --package $PACKAGE_ID --args $OBJECT_HEXSTRING We can then check the Events tab of the transaction on the Sui Explorer to see that we emitted the correctly deserialized BCSObject:
- Sui
- SDKs and Developer Tools
1
Vens.sui134
May 29, 2025
Article
Cetus Protocol Hack - The Biggest DeFi Exploit on Sui
In May 2025, the DeFi world was rocked by one of the most significant security breaches in recent history. Cetus Protocol, a leading decentralized exchange (DEX) and liquidity protocol on the Sui blockchain, fell victim to a sophisticated hack that resulted in losses exceeding $200 million . This incident not only sent shockwaves through the DeFi community but also raised serious concerns about the security of smart contracts and the robustness of protocols built on emerging blockchains like Sui. Cetus Protocol had established itself as the premier DEX on the Sui Network, offering users a platform for swapping tokens and providing liquidity. As a key infrastructure component within the Sui ecosystem, Cetus played a critical role in facilitating decentralized trading and contributing to the network’s overall liquidity. Its prominence made it an attractive target for malicious actors seeking to exploit vulnerabilities in its codebase. The Cetus Hack Unfolds The breach occurred on May 22, 2025, when attackers identified and exploited a critical flaw in Cetus’ smart contract logic. Specifically, the vulnerability stemmed from a subtle arithmetic overflow bug that allowed the hacker to manipulate the internal accounting mechanisms of the protocol. By deploying spoof tokens and manipulating price curves within liquidity pools, the attacker was able to drain vast amounts of funds without triggering immediate detection systems. At approximately 3:52 AM PT (11:52 UTC), blockchain monitors began detecting irregular transactions across several liquidity pools on Cetus. Within hours, the extent of the damage became clear—over $260 million worth of assets had been siphoned from the protocol. The stolen funds were quickly swapped and bridged to other blockchains, complicating recovery efforts. Impact on the Market and Sui Ecosystem The aftermath of the hack was swift and severe. Trading on Cetus was immediately halted as developers scrambled to assess the situation and mitigate further losses. Meanwhile, the value of native tokens associated with the platform plummeted, with some experiencing drops as high as 80% in a matter of hours. Investors and users faced massive losses, and confidence in the Sui ecosystem was shaken. One particularly alarming development came when the Sui network attempted a controversial countermeasure: voting to freeze the attacker's wallet containing $160 million of the stolen funds. While this move demonstrated a proactive approach to asset recovery, it also sparked debates about decentralization principles and whether such actions undermined trust in the immutability of blockchain transactions. In a momentum, $SUI lost 5% and $CETUS +- 40%, that jump was both incredible and terrifying. Technical Details of the Cetus Protocol Exploit According to analysis provided by cybersecurity firm Halborn, the root cause of the exploit lay in how Cetus validated certain arithmetic operations during token swaps. An oversight in handling large numbers led to an overflow condition, which the attacker cleverly manipulated to create artificial imbalances in liquidity pools. These imbalances were then exploited to extract real assets from the system without proper compensation to liquidity providers. This type of vulnerability is particularly insidious because it does not always manifest under normal operating conditions; instead, it requires specific edge cases involving very large values or unusual transaction sequences to trigger. Such bugs are notoriously difficult to detect during standard audits and testing phases, making them prime candidates for exploitation by well-resourced adversaries. Response and Recovery Efforts from Cetus and Sui Foundation (aka Mysten Labs) During the attack, around $160 million has reportedly been frozen and will be returned to Cetus pools. That's why all Sui foundation initiated a voting to unfreeze this tokens. Following the attack, the Cetus team issued public statements acknowledging the breach and outlining steps toward resolution. They worked closely with blockchain analytics firms like Elliptic and Chainalysis to track movement of stolen funds and identify potential avenues for recovery. Additionally, discussions emerged around implementing emergency upgrades to patch existing vulnerabilities and enhance future resilience against similar attacks. Community members expressed mixed reactions to these developments. While many praised the transparency shown by Cetus’ leadership post-hack, others criticized the lack of preparedness for such scenarios and questioned whether sufficient safeguards had been implemented prior to launch.
- Sui
- Security Protocols
1
HaGiang164
May 25, 2025
Article
My first article zkAt: Privacy-Preserving Authentication for Public Blockchains
Because transparency shouldn’t mean giving up your secrets. On most public blockchains today, every transaction and user identity is publicly visible. While transparency is one of blockchain’s biggest strengths, it comes at the cost of privacy, especially when it comes to authentication. ZkAt short for zero-knowledge authenticators is a novel cryptographic primitive that brings privacy-preserving authentication to the blockchain world. With zkAt, users can prove they’re authorized to perform a transaction without revealing the rules or policies behind that authorization. The Problem with Traditional Approaches Previous attempts at privacy in authentication such as using threshold signatures could only hide limited information. For example, they might obscure which users signed a transaction, but not much else. They also struggled with more complex authentication policies (like combinations of roles, identities, or rules). zkAt changes the game by: Supporting arbitrarily complex policies Allowing flexible structures like multi-scheme signature combinations Keeping the entire policy hidden from the public How zkAt Works To build zkAt, the authors designed a compiler that transforms the widely-used Groth16 zk-SNARK system into a new type of Non-Interactive Zero-Knowledge (NIZK) proof — one that supports equivocable verification keys. What does that mean? It means the verifier can’t tell which policy is being used, but the proof still convinces them that it’s valid. This is a brand-new cryptographic property introduced in the paper, and it’s the foundation for how zkAt ensures policy privacy. But the authors didn’t stop at zkAt. They went one step further with zkAt⁺, a version that supports oblivious updates. In short: A policy issuer can update the authentication policy without revealing anything new This is super powerful in real-world blockchain systems where policies may need to evolve — think DAOs updating voting rules or institutions rotating keys. They also explore using recursive zk-proofs to make zkAt⁺ scalable and suitable for blockchain integration. The researchers implemented zkAt in a prototype for threshold-based authentication. Their evaluation shows: Performance is on par with traditional threshold signatures zkAt supports far more complex policies All that, with minimal overhead
- Sui
- Architecture
1
0xduckmove308
May 19, 2025
Article
What is IKA? “Not just the hype 👀”
(p/s: Not one of those “web3 updates” that give you 3 lines of fluff and call it alpha 😮‍💨) Read full article: https://x.com/InternSui81687/status/1897309368644985108 You ever move assets between chains and feel like you’re Indiana Jones dodging traps? Yeah. That’s because interoperability right now = risky bridges + central points of failure. Ika says: “Nah, we’re done with that.” They’re building a system that’s trustless, fast AF, and doesn’t give your keys to anyone. Built on Sui, it uses Threshold encryption and 2PC-MPC In the video here, David Lash (co-founder of Ika) straight up says what everyone’s thinking: interoperability is broken AF. And instead of writing another “we need a solution” blog like most teams do, they spent two years pulling in security experts, AI nerds, and academics to actually build one. What they came up with? A system using 2PC MPC and threshold encryption — fancy words that basically mean: your keys stay yours, your assets don’t get rewrapped like a Christmas gift from 2017, and everything moves fast as hell. Like, Ika doesn’t just secure your stuff. It rips through transactions at sub-second latency and still stays decentralized. Meanwhile bridges are out here taking 8 minutes and your soul just to confirm a swap. They built this on Sui. And if you’ve slept on Sui until now, that nap is over. Sui’s object-centric model, blazing-fast finality, and Mysticeti Consensus (yes that’s a thing, no it’s not made up) are perfect for what Ika’s trying to do. David even said Sui’s dev experience made it an obvious choice — which is rare praise in crypto where every dev tool feels like an ancient scroll. But what really got me was their take on UX. The best crypto? The kind that’s boring. Not in a bad way, but in the “it just works” kinda way. Ika’s shooting for a future where you don’t even know you’re doing cross-chain stuff. No popups, no bridges, no fake tokens. Just open your wallet, lend your BTC natively, do a swap across chains, and keep vibin’. That’s what we’ve been asking for and somehow forgot to demand. And don’t think this is just for degen bros. Ika enables DAOs, indie teams, and businesses to roll out their own custody solutions — think “Fireblocks starter pack” but on steroids and actually accessible. You don’t need a $500k setup to build secure infra anymore. Just Sui, Ika, and a little bit of courage. Oh, and let’s not sleep on Bitcoin. BTC’s been sitting on the sidelines for years like that dude who refuses to join the game. But Ika’s making it playable. DeFi with no wrapping, no moving — just lock it as native collateral and go. Institutions are gonna love it because it keeps them compliant and efficient. No tax FUD, no custodial traps. Just capital flowing clean. So if someone asks you, “What’s next for crypto?” don’t send them a tweet thread that says “Interoperability is the future"
- Sui
1
RogueRig134
May 13, 2025
Article
What is IKA and Why the hype?
@ikadotxyz, the ultra-fast parallel MPC network on the Sui blockchain, is generating serious buzz for its potential to revolutionize Web3 security and interoperability. Recent posts on X highlight the bullish sentiment, with IKA reportedly trading between $4.90 and $10 on pre-market platforms like Whales, despite a 1B token supply. This suggests a possible market cap in the billions if the momentum holds, fueled by a $21M strategic investment from the Sui Foundation and a record-setting 1.4M SUI NFT art campaign. Ika’s sub-second latency and ability to scale across hundreds of signer nodes make it a game-changer for DeFi, decentralized custody, and cross-chain applications. The upcoming IKA token launch on Sui is expected to unlock new utility, driving further adoption. X users are hyped about IKA’s role in the @GiveRep loyalty program, with some calling it one of the biggest airdrop opportunities on Sui. That said, pre-market prices can be volatile and speculative, so the $4.90–$10 range isn’t guaranteed to hold post-launch. Always dig into the project’s fundamentals—check Ika’s official channels for deeper insights—and weigh the risks before jumping in. The Sui ecosystem is heating up, but nothing’s a sure bet in crypto
- Sui
- Architecture
1
Rogue129
May 13, 2025
Article
SUI Node Setup - A detailed guide
To set up a Sui node, you'll need to install the Sui binaries, clone the Sui repository, and configure the node. You can either build from source or use Docker. Once the node is running, you can monitor its status and sync progress. Detailed Steps: Install Sui Binaries: Follow the instructions in the Sui Documentation to install the Sui binaries. If you're using Docker, follow the instructions in the Sui Full node Docker Readme. If you're building from source, you'll need to clone the Sui repository and compile it. Configure the Node: Full Node: You can configure a Sui Full node using Docker or by building from source, according to the Sui Documentation. Validator Node: Follow the instructions in the Sui Validator Node Configuration to configure a validator node. This includes installing and configuring Sui, key management, and storage configuration. Full node configuration: Shut down any running Full node. Remove the database and genesis.blob file. Fetch the source from the latest release. Reset your branch. Download the latest genesis blob. Update your fullnode.yaml configuration file, if needed. Restart your Sui Full node. Run the Node: Start the Sui node using the appropriate command for your configuration method (e.g., sui-node or Docker commands). Monitor the Node: Monitor your node's status, sync progress, and logs to ensure it's running correctly. Use tools like logging, tracing, and metrics to monitor the node. The default metrics port is 9184, but you can change it in the fullnode.yaml file. Additional Steps: Committee registration: If you're running a validator node, you'll need to register with the committee. Liquid staking: If you're running a node, you can also participate in liquid staking. Sync your fork: If you're contributing to the Sui project, you'll need to sync your fork with the main repository. By following these steps, you can successfully set up and run a Sui node.
- Sui
1
HaGiang164
May 12, 2025
Article
“Decoding the Sui Trilogy: Paving the Future of Web3 Infrastructure
In the exploration of the Web3 world, beyond the common pursuit of faster transaction speeds and lower fees, deeper, structural challenges are increasingly surfacing. How can massive amounts of data be stored economically? How can sensitive information be securely protected in a decentralized environment? Can complex computations be efficiently executed off-chain while still having their results verified and trusted on-chain? Many projects attempt to address these problems by combining various third-party services. However, this path often brings with it integration complexity, potential trust friction, and a fragmented user experience. Facing these infrastructure-level challenges, the Sui blockchain and its core development team Mysten Labs have proposed a more integrated solution. Rather than relying on a patchwork of external tools, they’ve designed a blockchain with a unique architecture—including its object-centric model and the Move programming language while simultaneously building three tightly connected native infrastructure components: Walrus, Seal, and Nautilus. This article aims to unpack the design concepts behind these three components, explore how they work, how they relate to each other, and what real changes they might bring to Web3 applications. Sui’s Unique Architecture To understand how these three tools operate on Sui, we must first look at some key characteristics of the Sui platform itself. One of Sui’s core innovations is its object-oriented model, a fundamental shift from the traditional account-based architecture. Sui treats tokens, NFTs, and even complex data structures as standalone “objects”. Imagine managing each asset as a separate box instead of logging everything into a single ledger. This design allows unrelated actions—like handling two unrelated NFTs—to be processed in parallel, enhancing throughput. This object granularity creates a natural synergy with Walrus and Seal: Walrus treats stored data as objects, while Seal can attach permission rules directly to individual objects. In addition, Sui uses the Move programming language, designed specifically for managing digital assets. Move emphasizes safety and aims to reduce many common smart contract vulnerabilities at the language level. This strong foundation makes it well-suited for building robust infrastructure components. By aligning chain design and infrastructure development under one roof (Mysten Labs), Sui aims to deliver a more seamless, synergistic developer experience. ⸻ Walrus: Economical, Programmable Decentralized Storage Storing large files (images, videos, AI models—collectively called blobs) directly on-chain is notoriously expensive. Existing decentralized storage solutions each have trade-offs, but Walrus seeks a new balance between cost-efficiency and smart contract interactivity, directly tackling the cost barriers of large-scale on-chain data. At the heart of Walrus is Erasure Coding, a clever technique that “shards” a file and adds “recovery clues” so the file can be reconstructed even if parts are lost. Walrus calls these extra fragments “Red Stuff”. Think of it this way: if you have two numbers, say 3 and 5, and you store both as well as their sum (8), losing the 3 isn’t catastrophic—you can recover it using 8 - 5 = 3. The additional recovery fragments play a similar role, mathematically tied to the originals. After fragmenting and encoding, Walrus distributes these shards across many nodes. Even if some shards go missing, the system can reconstruct the original file as long as a threshold number of fragments is retrieved—saving significant space compared to full file replication. This approach dramatically reduces storage costs and could bring decentralized storage pricing closer to that of centralized cloud providers. Even more interesting, Walrus leverages Sui’s object model: each stored file becomes a programmable on-chain object. Developers can use Move to write smart contracts that manage these storage objects—setting access rules, auto-updating metadata, etc. Storage is no longer just passive—it becomes a natively programmable resource. There’s also a token utility layer: interacting with Walrus data on Sui requires SUI tokens to record metadata (like file names, sizes, storage locations) and potentially lock tokens for storage fees. If Walrus adoption grows, demand for SUI could increase, tightening supply. ⸻ Seal: The Decentralized Vault and Access Gatekeeper Many Web3 apps deal with sensitive data: user IDs, financial details, paywalled content. In a decentralized context, how do you securely store secrets and control access to them? Seal is a Decentralized Secrets Management (DSM) solution designed to answer that question. One of its core technologies is Threshold Encryption. Imagine a vault that requires two keys to open, each held by a different person. Similarly, threshold encryption splits decryption keys into multiple parts and distributes them to independent key servers. Only when a predefined number of them collaborate (the threshold) can the data be decrypted—no single server can do it alone, which spreads out trust and increases fault tolerance. Seal’s other clever feature is that access control logic is written as Move smart contracts on-chain. Developers can define clear rules: for example, only users holding a certain NFT or who’ve paid a fee can access certain data. This transparency and verifiability distinguishes Seal from traditional centralized access systems. When a user or app wants to decrypt a secret, it sends a request to key servers. These servers check the on-chain rules. Only if conditions are met do they release their key fragments. The actual decryption happens on the client device, so key servers never touch the original data. Seal can protect data stored anywhere—on Walrus, other decentralized networks, or even centralized clouds. This makes it ideal for secure messaging, private user data, paid content gating, confidential voting, and more. ⸻ Nautilus: Making Off-Chain Computation Verifiable On-Chain Blockchains aren’t great at complex or resource-heavy tasks. Doing those on-chain is slow, expensive, and compromises privacy. Solutions like Layer 2s or oracles help, but Nautilus explores a different path: enabling trustworthy off-chain computation. Nautilus uses a hardware-based solution called Trusted Execution Environments (TEEs). Think of a TEE as a secure, isolated zone inside a CPU. Code and data inside this zone are shielded from the rest of the system, including the operating system itself. The basic workflow is as follows: A developer deploys a computational task (e.g., financial models, AI inference, game logic) to a TEE they control. When the task finishes, the TEE produces a cryptographic attestation—a kind of tamper-proof “receipt” that proves: the task ran in a TEE the code wasn’t tampered with the process completed successfully. This attestation and the result are submitted to a Move smart contract on Sui. The contract verifies the attestation (e.g., signature validity and hash of the code). Only if verification passes does the contract accept the result and proceed with on-chain actions. Nautilus bridges high-performance off-chain computing with on-chain verifiability and trust, without exposing sensitive details. ⸻ Nautilus in Action: The Case of Bluefin A concrete example is Bluefin, a decentralized perpetuals trading platform. Most high-performance trading platforms face a dilemma: keeping order books fully on-chain offers transparency but is slow and expensive; moving them off-chain improves speed but introduces trust issues. Bluefin uses Nautilus to bridge this gap: • Order matching runs inside a TEE, ensuring secure, isolated processing. • Nautilus provides cryptographic proof that the matching logic ran correctly. • Proofs and results are submitted on-chain, where smart contracts verify them before executing settlement. This approach allows Bluefin to offer fast off-chain matching with on-chain trust guarantees, making it viable for performance-heavy DeFi like derivatives trading. Of course, this does shift some trust from pure blockchain consensus to TEE hardware and implementation.
- Sui
- Architecture
1
HaGiang164
May 01, 2025
Article
Inside Sui’s Kiosk: How to Build Secure NFT Marketplaces
What is Sui’s Kiosk? Kiosk is a native smart contract module on the Sui blockchain, designed to standardize and simplify the way NFTs are stored, managed, and traded. It acts as a programmable NFT storefront—ideal for devs who want to avoid reinventing the wheel for every NFT-related project. Whether you’re building a marketplace, a game asset exchange, or a digital collectibles gallery, Kiosk offers you secure, customizable building blocks. ⸻ 🛠️ Key Features of Kiosk 📦 NFT Storage & Display: Users can deposit NFTs into Kiosk smart contracts to store, show off, or trade them 🔐 Secure Ownership Transfer: All buy/sell flows are standardized and verifiable—goodbye shady swaps 👋 🎛️ Fine-grained Permissions: Kiosk lets devs define exactly who can do what with each NFT. 📈 Developer Extensibility: Plug in auctions, batch listings, bundles, and more. ⸻ 🤔 Why Build with Kiosk? Imagine you’re launching an NFT app. You’ll likely need a way for users to store assets safely. A way to list and buy assets. Kiosk handles all that for you. Instead of writing all these flows from scratch (and risking bugs 🐛 or exploits), you use Kiosk’s battle-tested API. ⸻ 🧪 Example App: Building with Kiosk Let’s get into a real example. You’ll create a basic NFT module, then use the Kiosk module to deposit it, list it, and allow others to purchase it. Step-by-Step Code Breakdown module 0xNFT::simple_nft { use sui::object::{UID}; use sui::tx_context::TxContext; struct SimpleNFT has key { id: UID, name: String, description: String, url: String, } public entry fun mint( name: String, description: String, url: String, ctx: &mut TxContext ): SimpleNFT { SimpleNFT { id: UID::new(ctx), name, description, url, } } } Commands (Sui CLI) Compile your package sui move build Deploy to network sui client publish --gas-budget 10000 Mint NFT sui client call --function mint --module simple_nft \ --args "My NFT" "Desc" "https://example.com/img.png" --gas-budget 1000 Initialize Kiosk sui client call --function init_kiosk --module kiosk_example --gas-budget 1000 Deposit NFT to Kiosk sui client call --function deposit_nft --module kiosk_example \ --args --gas-budget 1000 List for sale sui client call --function list_nft_for_sale --module kiosk_example \ --args 100 --gas-budget 1000 Purchase NFT sui client call --function purchase_nft --module kiosk_example \ --args --gas-budget 1000 Kiosk is one of the most powerful primitives in the Sui ecosystem for NFT developers. It abstracts away repetitive logic and injects security and modularity into your app stack. With just a few lines of code, you’re building full NFT marketplace flows that are production-ready and battle-tested.
- Sui
2