Author: Liu Honglin

The blockchain world has been developing at breakneck speed in recent years, becoming increasingly dazzling. Bitcoin pioneered the concept of "peer-to-peer electronic cash" from a theoretical perspective into reality; Ethereum brought "smart contracts" to the forefront, spawning countless applications. However, the stories of most new public chains since then have fallen into two categories: either claiming compatibility with Ethereum, "transferring" existing ecosystems and developers; or focusing on performance, stacking hardware and redesigning architectures in an attempt to address Ethereum's congestion.

Both paths have achieved success, but both also leave hidden concerns. Ethereum's compatibility has made it the most prosperous ecosystem, but it's still plagued by the age-old problems of congestion and high fees. Some public chains, focused on performance, rely on expensive hardware to achieve impressive TPS, but this comes at the cost of high operating costs and the sacrifice of decentralization. Others have complex, layered architectures, making maintenance difficult and risks increasingly apparent. From a user's perspective, the perception is often the same: slow, expensive, and inhumane.

It was against this backdrop that Sui emerged. Instead of calling for a "faster Ethereum" or a "cheaper Solana," it confidently declared: "A redesigned L1 public blockchain based on first principles."

At first, I didn't pay much attention—the blockchain world is never short of new concepts. But gradually, I noticed that many of my friends who work as developers, investors looking at projects, and even people who had previously been indifferent to public chains, were all talking about Sui. They said it was truly different from Ethereum and Solana.

Out of curiosity, Honglin Lawyer spent some time researching: Where exactly does this so-called "first principles" manifest itself? Compared to its predecessors, what are its strengths, and what potential problems does it face? The following is my analysis and reflections as a blockchain enthusiast. A disclaimer is that Honglin does not have a technical background, so some of my statements may not be rigorous or accurate. Please forgive me for any inaccuracies.

What exactly are assets?

The core of blockchain is essentially the recording of assets. This raises the question: how should assets be represented on-chain? Bitcoin and Ethereum offer a straightforward answer—accounts and balances. Who has how much money is represented by a line of numbers in a ledger. This approach is simple, but it differs significantly from real-world assets. Concert tickets are individual and expire after a single purchase; in-game equipment has levels and durability; bank mortgage contracts have specific terms and interest rates. If all of these were compressed into a single statement like "an additional balance in an account," additional logic would be required to explain them. Consequently, Ethereum has continuously introduced standards like ERC-20, ERC-721, and ERC-1155, acting as patches to address the shortcomings of the balance model.

Sui took a different approach. Rather than continuing this logic, it modeled assets directly as "objects." Each object has a unique ID, ownership, and attributes, and these attributes can change over time and with usage. A ticket automatically displays as "used" after a single use; a sword can be upgraded or damaged. In other words, on-chain assets are no longer cold numbers, but "living things" with lifecycles. This makes the development of complex assets more natural, eliminating the need for complex logical explanations.

Of course, this design comes with a price. Developers accustomed to Solidity will have to re-adapt to managing the life cycle of objects. Toolchains must also keep pace; otherwise, if indexers, wallets, and exchanges aren't tailored for the object model, developers might fall back on a "balance mindset." A more practical issue is that the ERC series has become the de facto global standard. When interoperating with ecosystems like Ethereum and Solana, Sui's object logic requires additional mapping and conversion, which can be a cumbersome process.

Therefore, the idea of treating assets as objects is appealing and indeed more closely resembles the physical form of real assets. However, whether it can truly succeed depends on the development of a comprehensive ecosystem, ensuring standardization, tool support, and cross-chain interoperability. Otherwise, even the most elegant concept may be trapped between ideals and compatibility.

Why do transactions have to queue?

A persistent problem in the blockchain world is that all transactions must be queued up one by one. Ethereum is designed this way: within each block, transactions are processed sequentially. This is a bit like having only one cashier in a city. Whether buying a cup of coffee or signing a real estate contract, everyone has to queue in the same line. If someone dawdles, those behind them are left waiting in vain. This creates a significant efficiency bottleneck.

Solana's approach is to upgrade this toll booth into a super-highway toll booth, streamlining processing and stacking high-performance hardware to maximize the throughput of a single lane. The result is indeed much faster than Ethereum, but ultimately it's still a "single lane," just running faster. The more hardware you stack, the higher the cost, the more stringent the requirements for participating nodes, and the lower the degree of decentralization.

Sui took a different approach. Since it modeled assets as independent objects, why should operations between two unrelated objects wait for each other? So, it simply changed the execution logic to parallelize: transactions between different objects could run simultaneously, and only operations modifying the same object would need to queue. This is like converting a single-lane highway into a multi-lane highway: most vehicles would go their own way, and only those competing for the same ramp would have to queue. Furthermore, it designed Programmable Transaction Blocks (PTBs), which allow complex multi-step operations to be bundled into a single transaction and executed all at once, avoiding bottlenecks or repeated confirmations.

Here's a practical analogy: Imagine you're checking out at a supermarket. The traditional Ethereum model means there's only one checkout counter for the entire store, so whether you're buying a bottle of water or a full truckload of groceries, you have to wait in the same line. Solana's approach equips this checkout counter with the fastest barcode scanners and the most skilled cashiers, but the line remains one. Sui's approach is more like having ten checkout counters, allowing most customers to spread out their checkouts, significantly improving efficiency.

This design greatly improves potential performance and makes "high concurrency" possible. But it is not a free lunch. First, the system needs to identify the dependencies between transactions before execution, which itself has computational overhead. Just like traffic police must first determine which cars can go at the same time and which cars may collide, and then direct them to go. If there are too many transactions, just doing this scheduling will consume resources. Secondly, the hot spot problem still exists. Once a shared object that the entire network is vying for appears, such as a popular order book or NFT contract, all related transactions still have to queue up, and this bottleneck will not disappear.

For developers, parallel execution also presents new challenges. In the world of sequential execution, logic is relatively simple, and test paths are controllable. However, in a parallel environment, considerations must be given to concurrent reads and writes, state conflicts, and other issues. If not properly designed, difficult-to-reproduce bugs can occur in extreme cases. This is similar to the transition from single-threaded to multi-threaded software development: while performance may improve, the complexity of debugging and verification often increases exponentially.

Therefore, parallel execution has indeed opened up a new path, freeing blockchain from the limitations of single-threaded execution. However, before it can truly achieve large-scale application, it still faces practical challenges such as scheduling overhead, hot spot bottlenecks, and developer mental complexity.

Should safety rely on language or habits?

Security issues on public chains often stem not from sophisticated attackers but from the excessive freedom afforded by the language itself. Solidity is a prime example. Its flexibility allows for the development of a wide range of imaginative logic, yet at the same time, DAO hacks, reentrancy attacks, integer overflows, and permission management vulnerabilities—all these bloody cases continue to unfold. You could argue that this stems from a lack of care on the part of developers, but consider this from another perspective: if a system's security relies on constant human vigilance, then the system's rules themselves are inherently weak.

Sui chose a different approach here—it built smart contracts based on the Move language. Move originated from Facebook's Libra project, and its core concept is "resources are resources." Resources are treated as first-class citizens at the language level. By default, they cannot be copied or destroyed at will, and must be transferred under clear ownership. To store them in global storage, specific permissions are required. These aren't conventions that developers "voluntarily abide by"; they're hard constraints hardwired into the language's rules. In other words, security has shifted from relying on "habit" to relying on "system."

A more realistic analogy is this: Solidity is like a mountain road without guardrails. You can drive as fast as you want, but if you slip, you're in a ditch. Move, on the other hand, is like a highway, with guardrails, speed limits, and ramps everywhere. Even with inexperienced drivers, the chances of an accident are greatly reduced. The problem is that highways are expensive to build and maintain, and if highway regulations aren't standardized across regions, drivers still find it difficult to drive across different regions.

This design does mitigate many common risks. Ethereum developers often have to carefully avoid errors like "double transfers" or "generating tokens out of thin air." In Move, these vulnerabilities are prevented at the compile time. For users, this means it's much harder for their assets to vanish due to contract bugs.

But the flip side of these guardrails is a barrier to entry. Move's programming paradigm is fundamentally different from what most engineers are accustomed to. Many Solidity veterans, writing Move for the first time, feel constrained: the compiler won't let them copy a value, and destroying an object requires specific conditions. Initially, the process can be noticeably slow. To complicate matters further, the Move ecosystem is still immature. Solidity has accumulated countless libraries, frameworks, and auditing experience, while Move's toolchain, auditing firms, and best practices are still under development.

Another often overlooked reality is that Move isn't fully implemented on Aptos and Sui. This means developers can't "learn once, use everywhere." This divergence increases learning costs in the short term and easily fragments the Move ecosystem, weakening network effects.

Therefore, from a security perspective, Sui's choice is rational: rather than relying on developer caution and self-discipline, it's better to embed rules directly into the language itself. However, from an ecosystem perspective, this path isn't easy. Developers need time to adapt, tools and audit systems need to be completed, and fragmentation between different platforms needs to be avoided. If these issues aren't addressed properly, even the best guardrails could become "a lane reserved for a select few."

What does scalability rely on?

Scalability is an unavoidable issue for almost all public chains. Ethereum chose to build a second layer: the main chain is responsible for security and settlement, while the second layer handles the majority of transactions. This approach is like repeatedly building overpasses in a congested city. While it does help divert traffic, it complicates switching between upstream and downstream, and cross-chain bridges become a high-risk area for accidents. Solana takes the other extreme, pushing the performance of a single machine to its limits. It's like building a superhighway and then forcing all cars to drive on it. The result is faster speeds, but the cost is high, and the number of people who can afford to drive is decreasing, which in turn compromises decentralization.

Sui proposed a third approach. Since it abstracts on-chain assets into independent objects, these objects can be split and processed independently by different nodes. Most unrelated objects are executed in parallel; only when encountering particularly popular shared objects does centralized coordination require it. This is more like building a subway network, with different lines running simultaneously without interfering with each other, and congestion only occurring at a few transfer hubs. In theory, this design means the system can scale horizontally: more users, more lines, and greater overall capacity.

However, there's still a gap between the blueprint on paper and reality. Sui's mainnet has yet to withstand the extreme test of tens of millions of concurrent users. The larger the distributed system, the more complex the scheduling and consistency issues become, just as the more subway lines there are, the exponentially greater pressure on the dispatch center. Furthermore, the economic model for nodes remains a question mark: who will be willing to operate them stably and long-term? If the rewards are too low, maintenance will be a flop. If the design is illogical, there's a risk that everyone will flock to popular nodes, while less popular areas will be neglected. Over time, this could even lead to "bad money driving out good."

Therefore, from a conceptual point of view, Sui's scalability solution is more flexible than "overpasses" or "single-lane highways." However, to truly build a well-connected and stable subway network, it still requires the coordination of technical verification, economic incentives, and ecological integration.

Is the ecosystem truly implemented?

No matter how brilliant the concept, without real-world applications, it's just castles in the air. Sui's mainnet launch has indeed fostered a number of ecosystem projects, from finance to gaming, from portals to e-commerce, creating a rudimentary ecosystem. However, there's still a long way to go before this prototype becomes a thriving ecosystem.

In the financial sector, DeepBook is considered infrastructure. It attempts to run a high-performance order book matching system on-chain, leveraging parallel execution and low latency to ensure matching and clearing are as seamless and smooth as those of centralized exchanges. This effort is crucial, as the order book is the heart of the financial market. If it works, it can support high-frequency trading and complex strategies. However, the order book is inherently a shared object, which negates the advantages of parallel execution. Hotspots still exist, and performance can easily become bottlenecked. More realistically, whether on-chain matching can truly attract market makers and institutions is a difficult question that requires both financial and in-depth verification.

Cetus is positioned as a decentralized trading and liquidity protocol. It provides aggregated routing, helping users negotiate the best prices across different pools. It sounds a bit like Didi, the DeFi equivalent of "hailing a ride anywhere." However, aggregation doesn't create depth out of thin air; liquidity still depends on willing investors. Currently, Cetus's trading volume is only a fraction of Uniswap on Ethereum, and its ecosystem impact is far from being realized.

Scallop Lend represents lending, emphasizing institutional-grade quality and composability, hoping to attract more professional participants. Lending is the lifeblood of DeFi, but risk management still relies on external funding and oracles. Sui's inherent architectural advantages cannot replace this "invisible hand."

At the user entry level, Sui proposed two interesting tools: zkLogin and sponsored transactions. The former allows users to log in to dApps with familiar accounts, secured by zero-knowledge proofs, essentially hiding the complex on-chain private key experience behind the scenes. The latter allows new users to interact directly without having to purchase tokens first. These designs lower the barrier to entry, but they also raise a new question: who will pay for sponsored transactions in the long term? Without a healthy business model, this experience may be unsustainable and ultimately revert to the old practice of requiring users to purchase tokens first.

In the NFT and e-commerce sectors, Sui launched the Kiosk standard, attempting to unify the on-chain process of listing, custody, settlement, and transfer. The concept is sound: reducing friction between markets and improving asset liquidity. However, Sui's NFT market currently has limited overall trading volume, and most items lack active secondary markets. Even the most refined standards, without user and capital flow, remain isolated.

Gaming is another key area of focus. Sui has attracted well-known IPs like Samurai Shodown R and has also experimented with original blockchain games. The object model is indeed well-suited to expressing complex game items. A sword can be upgraded, a pet can evolve; these are natural "object state changes" in Sui contracts. Parallel execution also alleviates lag when multiple people interact simultaneously. However, the longevity of a game ultimately depends on players' willingness to stay, not just to take advantage of airdrops. To date, no project on Sui has achieved the global success of Axie Infinity.

These efforts have prevented Sui from becoming a shell company, but the challenges remain clear: user scale and transaction volume remain limited compared to Ethereum and Solana. Many projects still rely on foundation subsidies and lack a self-sustaining business model. So-called "everyday applications" have yet to emerge, and scenarios for ordinary users to use the chain remain scarce. Even in DeFi, depth and risk management still rely on external funding, and the chain's inherent architectural advantages cannot replace the market's cold start. In other words, parallel execution can solve performance issues, but it cannot automatically generate users and capital.

Sui's ecosystem is like a new shopping mall: beautifully decorated, with cutting-edge design, and a subway entrance and parking lot built, but the number of businesses still isn't there, and the customer flow is even lower. The foundation can temporarily subsidize rent and attract a few major brands, but truly thriving the mall depends on profitable businesses and a strong customer base. This will be Sui's true test in the coming years.

How can blockchain enter the homes of ordinary people?

Most people new to Web3 often get stuck at the initial hurdles: downloading a wallet, writing down an incomprehensible mnemonic phrase, and then trying to buy some native tokens before they can even begin. Even if they manage to complete these steps, they often lose patience due to high gas fees, failed transactions, or long wait times. For a long time, Web3's entry point has been fraught with inhumane barriers.

Sui's design is, to some extent, a targeted solution. The object model makes on-chain assets more like real-world objects, making them much easier to understand. For example, a concert ticket isn't just a "balance in your account"; it's a ticket with an ID that automatically displays "used" after a single use. A sword in a game is no longer just a number; it's an object that can be upgraded, damaged, and even resold. This allows users, when they first encounter on-chain assets, to experience them as "objects" rather than "numbers on a ledger."

Parallel execution makes operations faster. On traditional public chains, transferring money and deploying a contract are queued in the same queue, much like buying a coffee and transferring property ownership in the same window. Sui's parallel logic is closer to reality: in most cases, transactions between different objects do not interfere with each other, and users receive immediate feedback after clicking an action. For ordinary users accustomed to instant payments, this "no lag" experience is crucial.

Combined with PTB (Programmable Transaction Block), complex, multi-step operations can be completed in one go, reducing the frustration of mid-step failures and repeated confirmations. New users often struggle with clicking for ages, only to receive an error message without knowing where they went wrong. PTB hides this complexity in the backend, making the user experience more like "one-click completion."

Sui also explored solutions to the cold start problem. With zkLogin, users can log in directly with their Google or Apple accounts, eliminating the need to understand the unfamiliar system of public keys, private keys, and mnemonics. Sponsored transactions allow new users to successfully complete their first blockchain-on-chain transaction without having to purchase tokens first. This significantly lowers the barrier to entry—at least it prevents users from being put off by the tedious first step.

However, simply making the experience "not so bad" isn't enough. To truly migrate people to the blockchain, application scenarios that Web2 can't provide need to emerge. Alipay and WeChat have already polished the payment experience to a point of near-zero friction. To compete with such rivals, Sui must provide compelling reasons to use it. For example: assets that users truly own and cannot be arbitrarily frozen; an experience that can be freely combined across applications—concert tickets can be purchased not only through official channels but also transferred on the secondary market, or even packaged into collections and displayed alongside virtual items in games; game props are no longer locked in a single vendor's servers but can be transferred between different games. This kind of experience is what Web2 can't achieve, and it's the killer use case that Sui needs to exploit.

From a broader perspective, Sui's approach differs from that of his predecessors: it transforms assets from balances into objects, enabling parallel transactions, embedding security into language rules, and replacing hardware with distributed scalability. Ecosystem-wide, Sui attempts to implement this concept through DeFi projects like DeepBook, Cetus, and Scallop, the design of zkLogin and sponsored transaction portals, attempts at kiosk standardization, and exploration of blockchain gaming.

However, the challenges it faces cannot be ignored. The object model is disconnected from the ERC world, requiring additional costs for interoperability. Parallel execution still encounters bottlenecks with hot objects. The learning curve and ecosystem size of Move limit the speed of developer migration. Distributed scalability remains unproven in large-scale scenarios. The application ecosystem still relies on subsidies, and real-world use cases have yet to emerge.

So, if Sui represents a "first principles" exploration, its greatest value lies in offering a different path: rather than tinkering with the Ethereum framework, it re-asks fundamental questions and attempts to provide new answers. As for how far these answers will go, it will require the combined test of time, the ecosystem, policies, and the market.