The blockchain world has been moving at breakneck speed in recent years, becoming increasingly dazzling. Bitcoin started the trend, turning "peer-to-peer electronic cash" from a theoretical concept into reality; Ethereum brought "smart contracts" to the forefront, spawning countless applications. But the stories of most new public chains since then have fallen into two categories: either they claim to be compatible with Ethereum, "moving" the existing ecosystem and developers over; or they focus on performance, piling up hardware and modifying the architecture in an attempt to solve Ethereum's congestion problem.
These two paths have their own achievements, but both also leave behind hidden concerns. Ethereum's compatibility has made it the most prosperous ecosystem, but it still suffers from the age-old problems of "congestion + high fees"; some public chains that compete on performance rely on burning money on hardware to achieve amazing TPS, but in return they incur high operating costs and sacrifice decentralization; some have complex architectures, layered on top of each other, making maintenance difficult and presenting increasingly hidden risks. From a user's perspective, the experience is often the same: slow, expensive, and inhumane. It was against this backdrop that Sui emerged. Instead of claiming to be "a faster Ethereum" or "a cheaper Solana," it confidently touted itself as a "L1 public chain redesigned 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 developer friends, investors looking at projects, and even people who had previously been indifferent to public chains were talking about Sui. They said it was truly different from Ethereum and Solana. Out of curiosity, attorney Honglin spent some time researching: Where exactly does Sui's so-called "first principles" manifest itself? Compared to its predecessors, what are its strengths, and what are its potential problems? The following is my analysis and reflections as a blockchain enthusiast. A disclaimer is that Honglin, as a lawyer, does not have a technical background, so some of the content may not be entirely rigorous or accurate. Please forgive me for any inaccuracies. What exactly are assets? At its core, blockchain is essentially about recording assets. This begs the question: How should assets be represented on-chain? Bitcoin and Ethereum offer a straightforward answer—accounts and balances. Who owns how much money is represented, just like a line of numbers in a ledger. While this approach is simple, it differs significantly from real-world assets. Concert tickets are individual, invalidated after a single swipe; in-game equipment has levels and durability; bank mortgage contracts have specific terms and interest rates. If all of these were compressed into "an additional balance in an account," they would require additional logic to explain. This is why Ethereum has continuously introduced standards like ERC-20, ERC-721, and ERC-1155, like patches to address the shortcomings of the balance model. Sui takes a different approach. Rather than continuing this logic, it models assets directly as "objects." Each object has a unique ID, ownership, and properties that can change over time and with usage. A ticket automatically displays as "used" after a single use; a sword can be upgraded and damaged. In other words, on-chain assets are no longer cold numbers but "living things" with a lifecycle. This makes the development of complex assets more natural, eliminating the need for complex logical explanations. Of course, this design doesn't come without a price. Developers accustomed to Solidity will have to re-adapt to the life cycle of managing objects. The toolchain must also keep pace; otherwise, if indexers, wallets, and exchanges aren't tailored for the object model, developers may fall back on a "balance mindset." A more realistic 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 may not be smooth. Therefore, the idea of treating assets as objects is appealing and indeed more closely resembles the form of real-world assets. However, whether it can truly succeed depends on the overall ecosystem's ability to build support, 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 long-standing problem in the blockchain world is that all transactions must queue up one by one. Ethereum is designed this way: within each block, transactions are processed sequentially. This is a bit like having only one toll booth in a city. Whether buying a cup of coffee or signing a real estate contract, everyone queues in the same line. If someone dawdles, those behind are left waiting. The resulting efficiency bottleneck is obvious. 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 is stacked up, the higher the cost, the stricter the requirements for participating nodes, and the lower the degree of decentralization. Sui took a different approach. Since it models 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 can run simultaneously, and only operations that modify the same object need to queue. It's like converting a single-lane highway into a multi-lane highway: most vehicles go their own way, and only those competing for the same exit need 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 mid-process bottlenecks or repeated confirmations. A practical analogy is: Imagine you're checking out at a supermarket. The traditional Ethereum model means a single checkout counter in the entire supermarket. Whether buying a bottle of water or a full truckload of groceries, customers must 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 check out at different locations, significantly improving efficiency. This design significantly improves potential performance and makes high concurrency possible. However, it's not a free lunch. First, the system needs to identify dependencies between transactions before execution, which inherently incurs computational overhead. Just like a traffic police officer must first determine which cars can travel simultaneously and which are likely to collide, and then direct them to pass. If there are too many transactions, this scheduling alone consumes resources. Second, the hotspot problem persists. Once a shared object becomes a hot topic across the entire network, such as a popular order book or NFT contract, all related transactions must still queue up, and this bottleneck persists.
For developers, parallel execution also means new challenges. In the world of sequential execution, the logic is relatively simple and the test path is controllable. In a parallel environment, however, we must consider concurrent reading and writing, state conflicts, and other situations. If not designed well, difficult-to-reproduce bugs may occur in extreme cases. This is like when developing software, jumping from single thread to multi-thread can bring performance improvements, but the complexity of debugging and verification often increases exponentially.
Therefore, parallel execution has indeed opened up a new path, allowing blockchain to no longer be limited by the ceiling of a single thread. But before it can truly run on a large scale,it still has to face practical tests such as scheduling overhead, hot spot bottlenecks, and developer mental complexity. Should security 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 writing of a wide range of unconventional 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 developers being careless, but another perspective: if a system's security relies on "constant human caution," then the system's rules themselves are not robust. Sui has chosen a different approach—building smart contracts based on the Move language. Move originated from Facebook's Libra project, and its core philosophy is that "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. Specific permissions are also required to store them in global storage. These aren't conventions that developers "voluntarily adhere to"; they're hard constraints hardwired into the language's rules. In other words, safety 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 can, but if you slip, you're in a ditch. Move, on the other hand, is like a highway, punctuated by guardrails, speed limits, and ramps. Even with inexperienced drivers, the probability of an accident is greatly reduced. The problem is that highways are expensive to build and maintain, and if highway regulations aren't standardized across regions, drivers still face challenges driving across different regions. This design does mitigate many common risks. Ethereum developers often need to be careful to avoid errors such as "duplicate transfers" or "generating tokens out of thin air", but in Move, these vulnerabilities will be blocked during the compilation phase. For users, this means that it is more difficult for assets to evaporate due to contract bugs.
But the other side of the guardrail is a threshold. The programming paradigm of Move is completely different from what most engineers are used to. Many Solidity veterans will feel that their hands and feet are restricted when they write Move for the first time: if they want to copy a value casually, the compiler will not allow it; if they want to destroy an object, they must meet specific conditions. When you first get started, the speed will be significantly slower. What's more troublesome is that the Move ecosystem is not mature enough. Solidity has accumulated countless libraries, frameworks, and auditing experience, while Move's tool chain, auditing companies, and best practices are still under construction. There's another reality that's easily overlooked: Move isn't exactly the same on Aptos and Sui. This means developers can't "learn once, use everywhere." This divergence will increase learning costs in the short term and easily fragment the Move ecosystem into smaller circles, weakening network effects. Therefore, from a security perspective, Sui's choice is rational: rather than relying on developers' caution and self-discipline, it's better to write the rules directly into the language itself. From an ecosystem perspective, however, 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 well, even the best guardrails could become "exclusive lanes for a select few." What drives scalability? Scalability is an unavoidable issue for almost all public chains. Ethereum chose the "second layer" approach: 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 can indeed divert traffic, it complicates uplinks and downlinks, 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. This is like building a superhighway and then forcing all cars to speed along a single lane. The result is faster speeds, but the cost is high, and the ability to drive is dwindling, compromising decentralization. Sui proposes a third path. Since it abstracts on-chain assets into independent objects, these objects can be split up and handled independently by different nodes. Most unrelated objects execute in parallel; centralized coordination is only required for particularly popular shared objects. This is more like building a subway network, with different lines operating simultaneously without interfering with each other, and congestion only occurring at a few transfer hubs. In theory, this design allows the system to scale horizontally: more users, more lines, and greater overall capacity. However, there's still a gap between paper blueprints 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, no one will maintain them. If the design is not sound, there's a risk that everyone will flock to popular objects, while less popular areas will be neglected. Over time, this could even lead to "bad money driving out good." So, from a conceptual perspective, Sui's scalability solution is more flexible than an "overpass" or "single-lane highway." However, to truly build a well-connected, stable subway network, it will require a multifaceted collaboration of technical validation, economic incentives, and ecosystem integration. Has the ecosystem truly taken off? No matter how beautiful the concept, without practical applications, it's just castles in the air. After Sui launched its mainnet, it did indeed attract a number of ecosystem projects, from finance to gaming, from portals to e-commerce, creating a prototype. However, turning this prototype into a thriving ecosystem still has a long way to go. 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 initiative is crucial because the order book is the heart of the financial market. If it works, it can support high-frequency trading and complex strategies. The problem is that the order book is inherently a shared object, which mitigates 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 find the best price across different pools, sounding like the Didi of DeFi, a "ride-hailing-everywhere" service. However, aggregation cannot create depth out of thin air; liquidity still depends on willing investors entering the market. 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 the lending sector, emphasizing institutional-grade quality and composability, hoping to attract more professional participants. Lending is the lifeblood of DeFi, but risk management still requires external funding and oracles. Sui's inherent architectural advantages cannot replace these "invisible hands." 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, using zero-knowledge proofs for security, 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. While these designs lower the barrier to entry, they also raise a new question: who will pay for sponsorship transactions in the long term? Without a healthy business model, this experience may be unsustainable and ultimately revert to the old practice of requiring tokens to be purchased first. In the NFT and e-commerce sectors, Sui launched the Kiosk standard, attempting to unify the on-chain processes 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 the vast majority of collections lack secondary market activity. 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 for expressing complex game items. A sword can be upgraded, a pet can evolve—these are natural "object state changes" in Sui's contracts. Parallel execution also alleviates lag when multiple people interact simultaneously. However, the longevity of a game ultimately depends on players' willingness to stick around, not just to cash in on airdrops. So far, Sui hasn't seen a project achieve global success like Axie Infinity. These efforts have prevented Sui from becoming a shell, 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 self-sustaining business models. 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 address performance issues, but it cannot automatically generate users and capital. Sui's ecosystem is like a new shopping mall: beautifully decorated and cutting-edge in design, with subway entrances and parking garages already built, yet the number of businesses still isn't there, let alone the foot traffic. The foundation can temporarily subsidize rent and attract a few major brands, but truly thriving the mall depends on profitable merchants and a willingness to attract customers. This will be Sui's true test in the coming years. How can blockchain become accessible to ordinary people? Most people new to Web3 often struggle with the initial hurdles: downloading a wallet, copying down an incomprehensible mnemonic phrase, and then trying to buy some native cryptocurrency 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 excessive wait times. The entry point to Web3 has long been fraught with "anti-human" barriers. Sui's design is, to some extent, addressing these challenges. Its 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 interact with on-chain assets, to experience them as "objects" rather than "numbers on a ledger." Parallel execution speeds up operations. On traditional public chains, transferring money and deploying a contract must be queued in the same window, much like buying coffee and transferring property ownership in the same window. Sui's parallel logic is closer to reality: in most cases, transactions between different objects don't 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. Coupled with PTB (Programmable Transaction Block), complex multi-step operations can be completed in one go, reducing the frustration of mid-step failures or repeated confirmations. New users often struggle with clicking for ages, only to receive an error message and not understand their mistake. PTB hides this complexity in the backend, making the user experience more like "one-confirmation, done." Sui also explored the cold start issue. With zkLogin, users can even log in directly with their Google or Apple accounts, eliminating the need to first understand the unfamiliar system of public keys, private keys, and mnemonics. Sponsored transactions allow new users to successfully complete their first on-chain transaction without having to purchase tokens first. This significantly lowers the barrier to entry—at least it prevents users from being turned off by the tedious first step. However, simply making the experience "not so bad" isn't enough. To truly migrate people to the blockchain, use cases need to emerge that Web2 can't offer. Alipay and WeChat have already polished the payment experience to near-zero friction. To compete with such rivals, Sui must offer compelling reasons to use it. For example: assets that users truly own and can't be frozen at will; 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 on a single vendor's servers but can be transferred between games. This kind of experience is what Web2 can't achieve, and it's the killer use case that Sui needs to deliver. From a broader perspective, Sui does offer a different approach than its predecessors: it transforms assets from balances into objects, enabling parallel transactions, embeds security into language rules, and replaces hardware with distributed scalability. In terms of its ecosystem, it attempts to gradually implement its concepts through DeFi projects like DeepBook, Cetus, and Scallop; the design of zkLogin and sponsored transaction portals; attempts at standardization of kiosks; and the exploration of blockchain games. However, the difficulties 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 scale of Move limit developer migration speed; distributed scalability remains unproven in large-scale scenarios; and the application ecosystem remains dependent on subsidies, hindering the emergence of real-world applications. Therefore, if Sui represents a "first principles" exploration, its greatest value lies in offering a different path: rather than tinkering with Ethereum's framework, it re-asks fundamental questions and attempts to provide new answers. As for how far this answer can go, it still needs the joint test of time, ecology, policies and the market.
Anais
Catherine
Joy
Kikyo
Weatherly