Author: Liu Honglin
The blockchain world has been moving at a rapid pace in recent years, becoming increasingly dazzling. Bitcoin started it all, turning "peer-to-peer electronic cash" from a paper concept into reality; Ethereum brought "smart contracts" to the stage, spawning countless applications. However, most new public chain stories that followed can be categorized into two types: either they claim to be compatible with Ethereum, "bringing over" the existing ecosystem and developers; or they focus on performance, stacking hardware and altering architecture in an attempt to solve Ethereum's congestion issues.
Both paths have their achievements, but they also leave behind concerns. Ethereum's compatibility has made its ecosystem the most prosperous, yet it still suffers from the old problems of "congestion + high fees"; some performance-focused public chains achieve impressive TPS by burning money on hardware, but at the cost of expensive operational costs and sacrifices in decentralization; others have complex architectures that are layered and increasingly difficult to maintain, revealing hidden risks. From the user's perspective, the experience often boils down to a few words: slow, expensive, and user-unfriendly.
In this context, Sui emerged. It does not claim to be "a faster Ethereum" or "a cheaper Solana," but instead throws out a rather confident slogan: "An L1 public chain redesigned based on first principles."
Initially, I did not pay much attention—there is no shortage of new concepts in the blockchain world. But I gradually noticed that many of my developer friends, investors looking at projects, and even those who were originally indifferent to public chains began to talk about Sui. They said this chain is genuinely different from Ethereum and Solana.
Out of curiosity, lawyer Honglin spent some time researching: where exactly does its so-called "first principles" manifest? What highlights does it have compared to its predecessors, and what potential issues does it face? The following content is my整理 and thoughts as a blockchain enthusiast. I need to issue a disclaimer in advance: lawyer Honglin does not have a technical background, and some expressions may not be entirely rigorous or accurate; I hope everyone can understand.
What Exactly is an Asset
The core of blockchain is essentially the recording of assets. So the question arises: how should assets be expressed on-chain? Bitcoin and Ethereum's answers are straightforward—it's just accounts and balances. Whoever has how much money is like a line of numbers recorded in a ledger. This method is simple, but it differs significantly from real-world assets. Concert tickets are individual items that become void after being used once; game equipment has levels and durability; bank mortgage contracts have specific terms and interest rates. If all these things are compressed into "an increase in balance in the account," it requires additional logic to explain. Thus, Ethereum continuously introduced standards like ERC-20, ERC-721, and ERC-1155, like patches to compensate for the shortcomings of the balance model.
Sui took a different path. It did not continue this logic but instead modeled assets directly as "objects." Each object has a unique ID, ownership, and attributes, and can change over time and with use. A ticket that has been used once automatically shows as "used"; a sword can be upgraded or may break. In other words, assets on the chain are no longer cold numbers but "living things" with a lifecycle. This makes the development of complex assets more natural, eliminating the need to navigate a convoluted logic to explain.
Of course, this design does come at a cost. Developers accustomed to Solidity must readjust to managing the "life and death" of objects. The toolchain must also keep up; otherwise, if the indexer, wallet, and trading market are not tailored for the object model, developers may revert to "balance thinking." A more practical issue is that the ERC series has already become the de facto global standard, and when interoperating with ecosystems like Ethereum and Solana, Sui's object logic requires additional mapping and conversion, which may not be smooth.
Therefore, the idea of treating assets as objects is appealing and indeed closer to the form of real-world assets. But whether it can truly function well depends on whether the entire ecosystem can be built to support it, ensuring standardization, tool support, and cross-chain interoperability. Otherwise, no matter how elegant the concept, it may still get stuck in the gap between "ideals and compatibility."
Why Must Transactions Be Queued
A longstanding issue in the blockchain world is that all transactions must be executed one by one in a queue. Ethereum is designed this way: transactions are processed sequentially within each block. This is somewhat like having only one payment window in the entire city; whether buying a cup of coffee or signing a property contract, everyone must wait in the same line. If someone dawdles, those behind can only wait. The efficiency bottleneck is naturally evident.
Solana's solution is to upgrade this payment window to a super-fast toll booth, processing transactions in a streamlined manner and stacking high-performance hardware to maximize throughput on a single lane. The result is indeed much faster than Ethereum, but ultimately it is still a "single lane," just running faster. The more hardware is piled on, the higher the costs, and the stricter the requirements for participating nodes, which in turn reduces decentralization.
Sui took a different approach. Since it models assets as independent objects, why should operations between two unrelated objects wait for each other? Thus, it simply changed the execution logic to parallel: transactions involving different objects can run simultaneously, and only operations modifying the same object need to be queued. It's like transforming a single-lane highway into a multi-lane road, where most vehicles can go their own way, only queuing when vying for the same exit. Additionally, it designed Programmable Transaction Blocks (PTB), allowing multiple complex operations to be packaged into a single transaction, executed all at once, avoiding bottlenecks or repeated confirmations.
A relatable analogy is: imagine you're checking out at a supermarket. The traditional Ethereum model is like having only one checkout counter in the entire supermarket; whether buying a bottle of water or a cart full of goods, you must slowly wait in the same line. Solana's approach is to equip this checkout counter with the fastest scanners and the most skilled cashiers, but the line is still one. Sui's method is more like opening ten checkout counters, allowing most customers to check out separately, significantly improving efficiency.
This design greatly enhances potential performance, making "high concurrency" possible. However, it is not a free lunch. First, the system needs to identify the dependencies between transactions before execution, which incurs computational overhead. It's like traffic police needing to determine which cars can go simultaneously and which might collide before directing traffic. If there are too many transactions, just managing this scheduling can consume resources. Secondly, hotspot issues still exist. If a shared object is in high demand across the network, such as a popular order book or NFT contract, all related transactions must still queue up, and this bottleneck will not disappear.
For developers, parallel execution also means new challenges. In a sequential execution world, the logic is relatively simple, and testing paths are controllable. In a parallel environment, considerations like concurrent reads and writes, and state conflicts must be taken into account; if not designed well, it could lead to hard-to-reproduce bugs in extreme cases. This is akin to software development, where moving from single-threaded to multi-threaded can enhance performance, but the complexity of debugging and validation often increases exponentially.
Thus, while parallel execution indeed opens a new path, freeing blockchain from the constraints of single-threaded ceilings, it still faces practical challenges such as scheduling overhead, hotspot bottlenecks, and increased complexity for developers before it can scale to large applications.
Should Security Rely on Language or Habit
The security issues of public chains often arise not from the attackers' sophistication but from the excessive freedom granted by the language itself. Solidity is a typical example. It is flexible enough to write all sorts of imaginative logic, but at the same time, cases of DAOs being hacked, reentrancy attacks, integer overflows, and permission management vulnerabilities continue to unfold. One might say this is due to developers not being careful enough, but from another perspective: if a system's security relies on "people maintaining a high level of vigilance," it indicates that the system's rules are not robust enough.
Sui chose a different path here—it builds smart contracts based on the Move language. Move originated from Facebook's Libra project, with the core idea being "resources are resources." Resources are treated as first-class citizens at the language level, defaulting to being non-copyable and non-destroyable, and must be transferred under clear ownership. To place them in global storage, specific permissions are required. These are not agreements that developers "consciously adhere to," but hard constraints written into the language rules. In other words, security shifts from "relying on habit" to "relying on system."
A more relatable analogy is: Solidity is like a mountain road without guardrails; you can speed as much as you want, but once you skid, it's a bottomless abyss; Move, on the other hand, is like a highway filled with guardrails, speed limits, and exit ramps, significantly reducing the probability of accidents even if you lack experience. The problem is that building and maintaining highways is costly, and if the highway rules are not uniform across regions, drivers will still find it troublesome to drive across districts.
This design indeed reduces many common risks. Ethereum developers often need to be extremely careful to avoid errors like "double transfers" or "creating tokens out of thin air," while in Move, these vulnerabilities are blocked at the compilation stage. For users, this means that assets are less likely to evaporate due to contract bugs.
However, the downside of guardrails is the threshold. Move's programming paradigm is completely different from what most engineers are accustomed to. Many seasoned Solidity developers find their hands tied when they first write in Move: trying to copy a value freely, the compiler won't allow it; trying to destroy an object also requires meeting specific conditions. Initially, the speed will noticeably slow down. More troublesome is that Move's ecosystem is not yet mature. Solidity has accumulated countless libraries, frameworks, and auditing experiences, while Move's toolchain, auditing firms, and best practices are still under development.
Another easily overlooked practical issue is that Move is not entirely the same on Aptos and Sui. This means developers cannot achieve "learn once, use everywhere." This divergence will increase learning costs in the short term and make it easy for Move's ecosystem to be fragmented into several small circles, weakening the network effect.
Therefore, from a security perspective, Sui's choice is rational: rather than relying on developers' caution and self-discipline, it is better to write the rules directly into the language itself. But from an ecosystem perspective, this path is not easy. Developers need time to adapt, tools and auditing systems need to be completed, and different platforms need to avoid fragmentation. If these issues are not well addressed, even the best guardrails may turn into "exclusive lanes for a few drivers."
What Drives Scalability
Scalability is an issue that almost all public chains cannot avoid. Ethereum chose the "build layer two" route: the main chain is responsible for security and settlement, while layer two handles most transactions. This approach is like continuously building overpasses in a congested city; it can indeed divert traffic, but switching between levels is complex, and cross-chain bridges have become accident-prone areas. Solana, on the other hand, took another extreme, pushing single-machine performance to the limit, akin to building a superhighway where all cars speed on a single lane. The result is faster speeds, but at a high cost, with fewer and fewer people able to afford to drive, thus reducing decentralization.
Sui proposes a third path. Since it abstracts on-chain assets as independent objects, it can split objects and assign them to different nodes for separate processing. Most unrelated objects execute in parallel; only when encountering particularly popular shared objects does centralized coordination become necessary. This is more like building a subway network, where different lines run simultaneously without interfering with each other, and only at a few transfer hubs does congestion occur. Theoretically, such a design means the system can scale horizontally: the more users there are, the more lines there are, and the overall capacity becomes stronger.
However, there is still a gap between the blueprint on paper and reality. Sui's mainnet has yet to undergo the extreme test of millions of users online simultaneously. The larger a distributed system becomes, the more challenging the issues of scheduling and consistency become, much like how the pressure on a scheduling center increases exponentially with more subway lines. Additionally, the economic model for nodes remains a question mark: who is willing to operate nodes stably in the long term? If the rewards are too low, no one will maintain them; if the design is unreasonable, it could lead to a situation where everyone rushes to popular objects while neglecting less popular areas. Over time, this could even result in "bad money driving out good."
Therefore, conceptually, Sui's scalability solution is more flexible than "overpasses" or "single highways," but to truly build a well-connected, stably operating subway network, it requires a combination of technical validation, economic incentives, and ecosystem coordination.
Is the Ecosystem Truly Taking Shape?
No matter how beautiful the concept, if there are no applications in place, it remains a castle in the air. After launching its mainnet, Sui indeed attracted a number of ecosystem projects, ranging from finance to gaming, from entry points to e-commerce, piecing together a prototype. However, transforming this prototype into a thriving ecosystem is still a long way off.
In the financial sector, DeepBook is seen as infrastructure; it attempts to run a high-performance order book matching system on-chain, utilizing parallel execution and low latency to make matching and clearing as smooth as centralized exchanges. This attempt is significant because the order book is the "heart" of financial markets; if it can be successfully implemented, it can support high-frequency trading and complex strategies. The problem is that order books are inherently "shared objects," which diminishes the advantages of parallel execution, and hotspots still exist, making performance prone to bottlenecks. More realistically, whether on-chain matching can truly attract market makers and institutions is a challenge that requires funding and deep validation.
Cetus is positioned as a decentralized trading and liquidity protocol, providing aggregated routing to help users find better prices across different pools, akin to a "Didi" in DeFi where you can get a ride anywhere. However, aggregation cannot create depth out of thin air; liquidity still depends on the willingness of capital providers to enter the market. Currently, Cetus's trading volume is still just a fraction compared to Uniswap on Ethereum, and the ecosystem effect is far from established.
Scallop Lend represents the lending direction, emphasizing institutional-grade quality and composability, hoping to attract more professional participants. Lending is indeed the lifeblood of DeFi, but the issue is that risk management still relies on external capital and oracles; Sui's architectural advantages cannot replace these "invisible hands."
At the user entry level, Sui has proposed two interesting tools: zkLogin and sponsored transactions. The former allows users to log into dApps using familiar accounts, ensuring security through zero-knowledge proofs, effectively hiding the complex on-chain private key experience in the background; the latter allows new users to interact directly without needing to buy tokens first. These designs lower the barriers to entry but also bring new questions: who will foot the bill for sponsored transactions in the long term? Without a healthy business model, this experience may be hard to sustain, ultimately reverting to the old path of "having to buy tokens first."
In the NFT and e-commerce sectors, Sui launched the Kiosk standard, attempting to unify the on-chain processes of "listing—custody—settlement—transfer." The idea is good: reducing friction between markets and improving asset liquidity. However, currently, Sui's NFT market has limited overall trading volume, and the vast majority of collectibles lack secondary market activity. Even with improved standards, without users and capital flow, it remains an "island standard."
Gaming is another key direction. Sui has attracted well-known IPs like "Samurai Spirits R" and has original blockchain game attempts. The object model is indeed well-suited for expressing complex items in games; a sword can be upgraded, and a pet can evolve, all of which are naturally "object state changes" in Sui's contracts. Parallel execution also alleviates lag during simultaneous interactions among multiple players. However, whether games can sustain in the long run ultimately depends on whether players are willing to stay, not just claim airdrops. So far, no project on Sui has exploded globally like Axie Infinity.
These efforts prevent Sui from being a mere shell, but the challenges are equally evident: user scale and trading volume are still limited compared to Ethereum and Solana. Many projects still rely on foundation subsidies and lack self-sustaining business models. The so-called "daily applications" have yet to emerge, and ordinary users still find it rare to use the chain. Even in DeFi, depth and risk management still depend on external capital, and the chain's architectural advantages cannot replace the cold start of the market. In other words, while parallel execution can solve performance issues, it cannot automatically generate users and capital.
Sui's ecosystem resembles a new shopping mall: beautifully decorated, with advanced design concepts, and well-built subway entrances and parking lots, but the number of merchants is still insufficient, and foot traffic is lacking. The foundation can temporarily subsidize rent to attract a few big brands to open, but to make the mall truly lively, it relies on merchants being able to make profits and customers being willing to come. This is the true test for Sui in the coming years.
How Can Blockchain Enter the Lives of Ordinary People?
For the vast majority of people, their first encounter with Web3 often gets stuck at the most basic threshold: downloading a wallet, writing down a string of incomprehensible mnemonic phrases, and then figuring out how to buy some native tokens to start operating. Even if they grit their teeth and complete these steps, they often lose patience due to high gas fees, transaction failures, or long wait times. The entry into Web3 has long been accompanied by "anti-human" barriers.
Sui's design somewhat addresses these issues. The object model makes on-chain assets resemble real-world items, making them much more intuitive to understand. For example, a concert ticket is not "an increase in balance in the account," but a ticket with an ID that automatically shows as "used" after being used once; 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 to feel the "thing" rather than "a line of numbers in a ledger" when they first encounter on-chain assets.
Parallel execution also speeds up operations. On traditional public chains, transferring money and deploying a contract must queue in the same line, much like waiting at a single window for both coffee and property transfers. Sui's parallel logic is closer to reality: in most cases, transactions involving different objects do not interfere with each other, and users receive feedback quickly after completing their operations. For ordinary users accustomed to instant payments, this "no lag" feeling is crucial.
Additionally, with PTB (Programmable Transaction Blocks), multiple complex operations can be completed in one go, reducing the hassle of mid-operation failures or repeated confirmations. New users fear clicking for a long time only to receive an error without knowing where they went wrong, while PTB hides the complexity in the backend, making the user experience feel like "one confirmation and it's done."
Sui has also made attempts to address the cold start issue. Through zkLogin, users can even log in directly using Google or Apple accounts, without needing to first understand the entire unfamiliar system of public keys, private keys, and mnemonic phrases; sponsored transactions allow newcomers to complete their first on-chain operation smoothly without needing to buy tokens first. This is significant for lowering the barriers to entry—at least it won't deter people due to the cumbersome first step.
However, merely making the experience "not so bad" is not enough. To truly encourage people to migrate to the chain, there need to be some application scenarios that Web2 cannot provide. Alipay and WeChat have refined the payment experience to nearly eliminate friction; to compete with such rivals, Sui must present "irresistible" reasons. For example: assets that users truly own and cannot be frozen at will; experiences that allow for free combinations across applications—concert tickets can not only be purchased through official channels but also transferred in the secondary market, or even bundled as collectibles displayed alongside virtual items in games; game items are no longer locked on a specific vendor's server but can circulate between different games. Such experiences are what Web2 cannot achieve and are the killer use cases that Sui needs to develop.
From a broader perspective, Sui indeed offers a different set of answers compared to its predecessors: it transforms assets from balances into objects, enables parallel transactions, embeds security into language rules, and replaces hardware stacking with distributed scaling. In terms of ecosystem, it attempts to gradually implement its concepts through DeFi projects like DeepBook, Cetus, Scallop, the entry designs of zkLogin and sponsored transactions, the standardization attempts of Kiosk, and explorations in blockchain gaming.
However, the difficulties it faces cannot be overlooked. The object model is disconnected from the ERC world, requiring additional costs for interoperability; parallel execution will still encounter bottlenecks under hotspot objects; the learning curve and ecosystem scale of Move limit the migration speed of developers; distributed scaling has yet to be validated in large-scale scenarios; and the application ecosystem still relies on subsidies, with true daily scenarios yet to emerge.
Therefore, if Sui represents an exploration of "first principles," its greatest value lies in providing a different path: not merely patching up the Ethereum framework but re-asking the most fundamental questions and attempting to provide new answers. As for how far this set of answers can go, it will require the joint validation of time, ecosystem, policy, and market.
免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。
