How to Understand the “First Principles” of the Sui Public Blockchain?

User experience is critically important.

The blockchain ecosystem has advanced rapidly in recent years, becoming increasingly complex and dazzling. Bitcoin pioneered the field by transforming the concept of “peer-to-peer electronic cash” from a whitepaper into reality; Ethereum brought “smart contracts” to the forefront, spawning countless applications. However, the narratives of most subsequent new public blockchains generally fall into two categories: either claiming compatibility with Ethereum to “port” its existing ecosystem and developers over, or emphasizing performance by investing heavily in hardware and modifying architecture in an attempt to resolve Ethereum’s congestion issues.

Both approaches have achieved certain successes, but each has also left lingering concerns. Ethereum’s compatibility has fostered the most prosperous ecosystem, yet it remains plagued by the longstanding issues of congestion and high fees. Public blockchains competing on performance have, in some cases, achieved impressive transactions per second (TPS) through substantial capital expenditure on hardware, but at the cost of expensive operational expenses and compromises to decentralization; others feature complex, multi-layered architectures, with increasing maintenance difficulties and hidden risks becoming apparent. From the user’s perspective, the experience is often still summarized by a few words: slow, expensive, and counterintuitive.

Against this backdrop, Sui emerged. Rather than branding itself as a “faster Ethereum” or a “cheaper Solana,” it put forward a rather confident slogan: “A Layer 1 public blockchain redesigned from first principles.”

Initially, I paid little attention—new concepts are abundant in the blockchain world. However, I gradually noticed that many developer friends, investors evaluating projects, and even individuals previously unconcerned with public blockchains, began discussing Sui. They stated that this blockchain is truly different from Ethereum and Solana.

Out of curiosity, Attorney Honglin devoted time to researching the following:Where exactly are its so-called “first principles” reflected? Compared to its predecessors, what are its highlights, and what potential issues exist?The following content represents my organization and reflections as a blockchain enthusiast. A preliminary disclaimer is necessary: Attorney Honglin does not have a technical background, and some expressions may lack rigorous precision or accuracy. Your understanding is appreciated.

 

What Exactly Are Assets?

At its core, a blockchain essentially records assets. This raises the question:How should assets be represented on-chain?The answers provided by Bitcoin and Ethereum are straightforward—accounts and balances. Who holds how much value is recorded merely as a line item in a ledger. While this approach is simple, it differs significantly from assets in the real world. Concert tickets are individual items that become void after a single use; in-game equipment possesses levels and durability; bank mortgage contracts include specific terms and interest rates. If all such items were compressed into “an increase in balance within an account,” additional logic would be required for explanation. Consequently, Ethereum has continuously introduced standards such as ERC-20, ERC-721, and ERC-1155, acting as patches to compensate for the limitations of the balance model.

Sui has taken a different path. It did not continue with this logic, but insteadmodels assets directly as "objects."Each object has a unique ID, ownership, and attributes, and can change over time and with use. A ticket automatically shows as "used" after one use; a sword can be upgraded or may become damaged. In other words, on-chain assets are no longer cold numbers, but "living entities" with life cycles. This makes the development of complex assets more natural, without the need to circumvent extensive logical frameworks for explanation.

Of course, this design is not without its costs. Developers accustomed to Solidity must re-adapt to managing the "life cycle" of objects. The toolchain must also keep pace; otherwise, if indexers, wallets, and trading markets are not tailored to the object model, developers may still revert to a "balance-based mindset." A more practical issue is that the ERC series has become the de facto global standard. When interoperating with ecosystems such as Ethereum and Solana, Sui's object logic requires additional mapping and conversion, a process that may not always be smooth.

Therefore, the concept of treating assets as objects is elegant and indeed closer to the form of real-world assets (RWA). However, whether it can truly succeed depends onwhether the entire ecosystem can be built in support, ensuring standardization, tooling support, and cross-chain interoperability.Otherwise, even the most elegant concepts may become trapped in the gap between "idealism and compatibility."

 

Why Must Transactions Queue?

A longstanding issue in the blockchain world is that all transactions must be executed sequentially, one by one. Ethereum is designed this way: within each block, transactions are processed in order. This is akin to having only one toll booth in an entire city; whether buying a cup of coffee or signing a real estate contract, everyone must wait in the same line. If someone delays, those behind them can only wait idly. The efficiency bottleneck is thus evident.

Solana's approach is to upgrade this toll booth into a super-high-speed toll station, processing transactions via an assembly line and leveraging high-performance hardware to maximize the throughput of the single lane. The result is indeed much faster than Ethereum, but fundamentally, it remains a "single lane," merely moving faster. The more intensive the hardware deployment, the higher the cost, the stricter the requirements for participating nodes, and the consequent reduction in the degree of decentralization.

Sui has adopted a different approach.Since it models assets as independent objects, why should operations involving two unrelated objects wait for each other? Thus, it simply changes the execution logic to parallel processing:Transactions involving different objects can be executed concurrently; only operations that modify the same object need to be queued.This is akin to upgrading a single-lane highway into a multi-lane one: most vehicles proceed in their respective lanes, and queuing is required only when competing for the same ramp exit. In addition, it incorporates Programmable Transaction Blocks (PTBs), which allow multiple complex steps to be bundled into a single transaction and executed atomically, thereby avoiding mid-execution stalls or repeated confirmations.

A everyday analogy is as follows:Imagine checking out at a supermarket. Under the traditional Ethereum model, there is only one checkout counter for the entire store; whether you are buying a bottle of water or a cart full of goods, you must wait slowly in the same queue. Solana’s approach equips this single counter with the fastest scanners and the most skilled cashiers, but the queue remains singular. Sui’s approach is more like opening ten checkout counters, allowing most customers to check out in parallel, thereby significantly improving efficiency.

This design substantially enhances potential performance, making “high concurrency” feasible. However, it is not without cost. First, the system must identify dependencies among transactions before execution, which itself incurs computational overhead. This is similar to traffic police first determining which vehicles can proceed simultaneously and which may collide, before directing traffic flow. If there are too many transactions, the scheduling process alone will consume resources. Second, hot-spot issues persist. Once a shared object contested across the network emerges—such as a popular order book or an NFT contract—all related transactions must still queue in an orderly manner, and this bottleneck does not disappear.

For developers, parallel execution also presents new challenges. In a sequential execution environment, logic is relatively simple and testing paths are controllable. In a parallel environment, however, one must account for concurrent reads and writes, state conflicts, and other scenarios; if not properly designed, hard-to-reproduce bugs may arise under extreme conditions. This is akin to moving from single-threaded to multi-threaded software development: while performance improves, the complexity of debugging and verification often increases manifold.

Thus, parallel execution indeed opens a new path, freeing blockchains from the ceiling imposed by single-threaded execution. However, before truly scaling to mass adoption,it must still confront practical challenges such as scheduling overhead, hot-spot bottlenecks, and the increased cognitive complexity for developers.

 

Should security rely on language constraints or on habits?

Security issues on public blockchains often arise not because attackers are exceptionally sophisticated, but because the language itself affords excessive freedom. Solidity is a typical example. It is flexible enough to enable all manner of imaginative logic, yet incidents such as DAO hacks, reentrancy attacks, integer overflows, and access-control vulnerabilities continue to occur with alarming frequency. One might argue that these stem from developers’ lack of caution; but from another perspective, if a system’s security depends on “people remaining highly vigilant at all times,” this indicates that the system’s rules themselves are insufficiently robust.

Sui has chosen a different path—it builds smart contracts on the Move language. Move originated from Facebook’s Libra project, with the core principle that “resources are resources.” Resources are treated as first-class citizens at the language level and, by default, cannot be copied or arbitrarily destroyed; they must be transferred under clear ownership. Placing them into global storage further requires specific permissions. These are not conventions that developers “voluntarily observe,” but hard constraints encoded into the language rules. In other words, security shifts from “relying on habits” to “relying on institutionalized constraints.”

A more relatable analogy is:Solidity is akin to a mountain road without guardrails: you may drive at high speed, but a single slip can plunge you into an abyss. Move, by contrast, resembles a highway equipped with guardrails, speed limits, and ramp entrances; even for developers with limited experience, the probability of accidents is significantly reduced. The issue is that building and maintaining such highways entails high costs, and if traffic rules vary across jurisdictions, drivers crossing regional boundaries will still encounter considerable inconvenience.

This design indeed mitigates many common risks. Ethereum developers must constantly exercise caution to avoid errors such as "double transfers" or "spontaneous token creation," whereas in Move, these vulnerabilities are blocked at the compilation stage. For users, this means that assets are less likely to vanish spontaneously due to smart contract bugs.

However, the guardrails also raise the barrier to entry. Move’s programming paradigm differs fundamentally from what most engineers are accustomed to. Many seasoned Solidity developers find their hands tied when first writing Move code: the compiler prohibits casual value copying, and object destruction is permitted only under specific conditions. Initial development velocity inevitably slows. More troublingly, the Move ecosystem remains immature. While Solidity has accumulated countless libraries, frameworks, and audit expertise, Move’s toolchain, audit firms, and best practices are still under construction.

Another easily overlooked practical issue is:Move implementations on Aptos and Sui are not entirely identical.This means developers cannot achieve "learn once, deploy anywhere." Such divergence will increase learning costs in the short term and risks fragmenting the Move ecosystem into several small silos, thereby weakening network effects.

Thus, from a security perspective, Sui’s choice is rational: rather than relying on developers’ prudence and self-discipline, it embeds rules directly into the language itself. From an ecosystem perspective, however, this path is far from easy. Developers need time to adapt, tools and audit systems require completion, and fragmentation across different platforms must be avoided. If these issues are not adequately addressed, even the best guardrails may become "exclusive lanes accessible only to a few."

 

What Drives Scalability?

Scalability is an unavoidable challenge for nearly all public blockchains. Ethereum has adopted a Layer 2 approach: the main chain handles security and settlement, while Layer 2 networks process the majority of transactions. This strategy is akin to continuously building overpasses in a congested city; while it does divert traffic, switching between layers is complex, and cross-chain bridges have become high-risk areas for incidents. Solana, by contrast, has taken another extreme by pushing single-node performance to its limits, comparable to constructing a superhighway where all vehicles speed along a single lane. Although this results in faster speeds, the costs are high, leading to a decreasing number of participants who can afford to operate nodes, thereby compromising decentralization.

Sui proposes a third path.By abstracting on-chain assets as independent objects, Sui can split these objects and assign them to different nodes for parallel processing. Most unrelated objects execute concurrently; coordination is required only when handling particularly popular shared objects. This resembles a subway network, where different lines operate simultaneously without interfering with one another, with congestion occurring only at a few transfer hubs. In theory, such a design enables horizontal scalability: as the number of users grows, more lines are added, and overall throughput increases.

Nevertheless, a gap remains between theoretical blueprints and reality. Sui’s mainnet has yet to undergo extreme stress tests involving tens of millions of concurrent users. As distributed systems scale, scheduling and consensus challenges become more formidable, much like how a subway control center faces exponentially greater pressure as the number of lines increases. Furthermore, the economic model for node operators remains uncertain: who will maintain nodes stably over the long term? If rewards are too low, no one will participate; if the design is flawed, it may lead to herd behavior toward popular objects while neglecting less active areas. Over time, this could even result in a "bad money drives out good" scenario.

Therefore, from a conceptual standpoint,Sui’s scalability solution is more resilient than an “overpass” or a “single-lane expressway.” However, to truly build a comprehensive, stable, and interoperable network akin to a subway system, it requires the concerted alignment of technical validation, economic incentives, and ecosystem integration.

 

Has the ecosystem achieved genuine adoption?

No matter how elegant the concept, without practical implementation, it remains a castle in the air. Following the launch of its mainnet, Sui did attract a cohort of ecosystem projects, spanning from finance to gaming and from entry points to e-commerce, thereby cobbling together a preliminary framework. However, there is still a long road ahead to transform this nascent stage into a thriving ecosystem.

In the financial sector,DeepBookis regarded as infrastructure. It attempts to operate a high-performance order book matching system on-chain, leveraging parallel execution and low latency to make matching and settlement as seamless and continuous as those on centralized exchanges. This endeavor is significant because the order book is the “heart” of financial markets; if successfully implemented, it could support high-frequency trading and complex strategies. The challenge lies in the fact that order books are inherently “shared objects,” which diminishes the advantages of parallel execution. Hotspots persist, and performance is prone to bottlenecks. More pragmatically, whether on-chain matching can genuinely attract market makers and institutional participants is a critical issue that must be validated through capital inflows and market depth.

Cetuspositions itself as a decentralized trading and liquidity protocol. It provides aggregated routing to help users secure better prices across different pools, akin to a ubiquitous ride-hailing service within DeFi. However, aggregation cannot create depth ex nihilo; liquidity ultimately depends on the willingness of capital providers to enter the market. Currently, Cetus’s trading volume is merely a fraction of that of Uniswap on Ethereum, and the network effect has yet to materialize.

Scallop Lendrepresents the lending sector, emphasizing institutional-grade quality and composability with the aim of attracting more sophisticated participants. Lending is the lifeblood of DeFi, yet risk management still relies on external capital and oracles. Sui’s architectural advantages cannot replace these “invisible hands.”

At the user onboarding layer, Sui has introduced two notable tools: zkLogin and sponsored transactions.The former allows users to log in to dApps using familiar accounts, employing zero-knowledge proofs to ensure security, thereby abstracting the complex experience of managing on-chain private keys into the background. The latter enables new users to interact directly without first purchasing tokens. While these designs lower entry barriers, they also raise new questions: Who will bear the long-term costs of sponsored transactions? Without a sustainable business model, this user experience may prove untenable, eventually reverting to the traditional requirement of “purchasing tokens first.”

In the NFT and e-commerce sectors, Sui introduced the Kiosk standard, aiming to unify the on-chain processes of “listing, custody, settlement, and transfer.”The rationale is sound: reducing friction between markets and enhancing asset liquidity. However, the overall trading volume in Sui’s NFT markets remains limited, with most collections lacking secondary market activity. No matter how refined the standard, without users and capital flow, it remains an “isolated standard.”

Gaming is another key focus area.Sui has attracted well-known intellectual property (IP) franchises such as Samurai Shodown R, alongside attempts at original on-chain games. The object model is indeed well suited to representing complex in-game items; for example, a sword can be upgraded and a pet can evolve, which in Sui smart contracts naturally manifest as “changes in object state.” Parallel execution also alleviates lag during simultaneous multi-user interactions. However, whether a game can sustain long-term operation ultimately depends on whether players are willing to remain engaged, rather than merely claiming an airdrop. To date, no project on Sui has achieved global breakout success comparable to Axie Infinity.

These efforts prevent Sui from being an empty shell, but the challenges are equally evident:Its user base and transaction volume remain limited compared with Ethereum and Solana. Many projects still rely on subsidies from the foundation and lack self-sustaining business models. So-called “everyday applications” have not yet emerged, and scenarios in which ordinary users need to interact with the blockchain remain scarce. Even in decentralized finance (DeFi), liquidity depth and risk management continue to depend on external capital; the architectural advantages of the chain itself cannot substitute for the cold-start problem in markets. In other words, while parallel execution can resolve performance issues, it cannot automatically generate users and capital.

Sui’s ecosystem resembles a newly built shopping mall: the fit-out is attractive and the design concepts are advanced, with subway access and parking facilities already in place, but there are insufficient tenants and foot traffic has yet to materialize. The foundation can temporarily subsidize rents and attract a few major brands to open, but for the mall to become truly vibrant, merchants must be able to earn profits and customers must be willing to visit. This is the real test for Sui in the coming years.

 

How can blockchain technology reach ordinary households?

For most people, their first encounter with Web3 often stalls at the most primitive barriers: downloading a wallet, writing down a string of incomprehensible seed phrases, and then figuring out how to purchase native tokens before they can begin operating. Even if they persevere through these steps, they frequently lose patience due to high gas fees, failed transactions, or excessive waiting times. The entry point to Web3 has long been characterized by “counterintuitive” barriers.

Sui’s design addresses these pain points to some extent. The object model makes on-chain assets resemble physical items, making them much more intuitive to understand. For example, a concert ticket is not merely “an increase in balance within an account,” but a ticket with an ID that automatically displays as “used” after one use; a sword in a game is no longer just a number, but an object that can be upgraded, damaged, or even transferred. This allows users, upon their first exposure to on-chain assets, to perceive them as “objects” rather than “a line of digits in a ledger.”

Parallel execution makes operations faster. On traditional public blockchains, transferring funds and deploying a smart contract must queue in the same line, akin to buying coffee and transferring real estate title at the same service window. Sui’s parallel logic is closer to reality: in most cases, transactions involving different objects do not interfere with one another, and users receive feedback shortly after initiating an operation. For ordinary users accustomed to instant payments, this “lag-free” experience is crucial.

Furthermore, with Programmable Transaction Blocks (PTB), multi-step complex operations can be completed in a single transaction, reducing the frustration of mid-process failures or repeated confirmations. Novices often fear clicking through multiple steps only to encounter an error message without understanding what went wrong; PTB hides this complexity in the backend, making the user experience feel like “one confirmation gets it done.”

Sui has also made attempts to address the cold-start problem. Through zkLogin, users can even log in directly using Google or Apple accounts, without first needing to understand the unfamiliar system of public keys, private keys, and seed phrases; sponsored transactions allow newcomers to complete their first on-chain operation without having to purchase tokens beforehand. This is significant for lowering barriers to entry—at the very least, it prevents users from being deterred by the cumbersome nature of the initial step.

However, merely making the experience “less bad” is insufficient. To genuinely migrate users on-chain, there must be application scenarios that Web2 cannot provide. Alipay and WeChat Pay have refined the payment experience to be nearly frictionless; to compete with such rivals, Sui must offer compelling reasons that make its use indispensable. Examples include: assets that are truly owned by users and cannot be arbitrarily frozen; an experience of free composability across applications—concert tickets that can not only be purchased through official channels but also resold in secondary markets, or even bundled as collectibles and displayed alongside virtual items in games; and in-game items that are no longer locked on a specific vendor’s servers but can circulate across different games. Such experiences are beyond the reach of Web2 and represent the killer use cases that Sui needs to deliver.

From a broader perspective, Sui has indeed offered a different set of answers than its predecessors: it transforms assets from balances into objects, enables parallel transaction execution, embeds security into the language rules, and replaces hardware scaling with distributed scalability. In terms of ecosystem development, it is gradually putting these concepts into practice through DeFi projects such as DeepBook, Cetus, and Scallop; entry-point designs like zkLogin and sponsored transactions; standardization efforts via Kiosk; and explorations in blockchain gaming.

However, the challenges it faces cannot be ignored. The object model is fragmented from the ERC world, requiring additional costs for interoperability; parallel execution still encounters bottlenecks under hot-spot objects; the learning curve of Move and the scale of the ecosystem limit the speed at which developers migrate; distributed scalability has not yet been validated in large-scale scenarios; and the application ecosystem remains dependent on subsidies, with no true daily-use scenarios having emerged yet.

Therefore, if we say that Sui represents an exploration based on "first principles," its greatest value lies in offering a different path: rather than making piecemeal fixes within the Ethereum framework, it reasks the most fundamental questions and attempts to provide new answers.As for how far this approach can go, it will require joint validation by time, the ecosystem, policy, and the market.