First-generation protocols represented by Bitcoin are limited by their proof-of-work mechanism and UTXO model, achieving transaction throughput of only 7 transactions per second, making it difficult to support large-scale commercial applications. Subsequent blockchain platforms, such as Ethereum [2], while greatly expanding application scenarios by introducing Turing-complete smart contracts—enabling innovative applications like decentralized finance (DeFi) and non-fungible tokens(NFTs)—have seen their sequential transaction execution design gradually become a key bottleneck constraining overall system performance, with a theoretical maximum TPS of only 178.6 TX/s [3].To overcome these limitations, the industry has witnessed the emergence of a series of innovative high-performance blockchain architectures in recent years, conducting important explorations in areas such as parallel execution, sharding technology, and consensus mechanism optimization. However, in pursuing extreme performance metrics, these solutions often have to make significant compromises on other critical system characteristics, creating new technical bottlenecks and application barriers.1）Weakened Decentralization: Decentralized trust ensures the censorship resistance, fairness, and security of blockchain systems. However, many high-performance solutions compromise on this key attribute in order to achieve high performance.Taking zero-knowledge proof solutions as an example, ZK-SNARK [4], as a revolutionary scaling solution, achieves extremely small proof sizes and very fast verification speeds, with verification complexity independent of the scale of the original computation. However, behind this technical advantage lies the cost of trust assumptions: the system must generate a set of proving keys and verification keys through a ”Trusted Setup” in advance. Once the generated keys are obtained by a malicious party, attackers can forge arbitrary proofs, thereby compromising the security of the entire system. Therefore, this ceremony typically requires multi-party participation to distribute trust, but this mechanism essentially still introduces trust assumptions, deviating from blockchain’s ”trustless”
philosophy.In contrast, ZK-STARK [5] technology completely avoids the trusted setup required by SNARK by using public hash functions to generate the randomness needed for proofs, achieving a more pure trustless characteristic. However, this security improvement comes at the cost of proof sizes dozens of times larger than SNARK, which not only increases on-chain storage costs but also places higher
demands on network bandwidth.More critically, whether SNARK or STARK, their extremely high computational requirements for proving nodes have created significant participation barriers. Generating a valid zero-knowledge proof often requires high-end GPUs or specialized hardware facilities, with investment costs reaching tens of thousands of dollars. This technical complexity and economic barrier make it difficult for ordinary users to participate as verification nodes in network consensus, essentially forming a specialized proof
generation class. In the long term, this will inevitably lead to proof generation capabilities being concentrated in the hands of a few large institutions, creating new centralization risks that fundamentally deviate from blockchain technology’s core principles of equal participation and distributed power.2）Lack of Ecosystem Compatibility: A thriving ecosystem is one of the key factors in blockchain platform success. A vibrant ecosystem means not only rich application scenarios but also a large developer community, mature toolchains, and deep liquidity. However, while high-performance solutions using asynchronous execution models achieve theoretical throughput improvements of thousands of times through parallel transaction processing, they face serious compatibility challenges in practice.Sharding technology, as one of the most representative scaling solutions, fundamentally splits the entire network state and transaction processing tasks horizontally into multiple smaller, parallelprocessing shard chains. Each shard only needs to be maintained by a subset of network nodes,thereby achieving decentralization of computational and storage burdens.Existing sharding solutions can be roughly divided into two categories. The first is partial sharding solutions, which only shard certain parts of the blockchain system—usually transaction processing capability—while keeping other parts (especially data availability and state) unified across the entire chain. While this design simplifies system complexity, its performance improvement is limited: the system’s ultimate bottleneck lies in the hardware capabilities of individual nodes (especially coordinator nodes). Because each node ultimately still needs to process and store network-wide data,as transaction volume increases, hardware requirements for nodes will rise accordingly, inevitably raising participation thresholds and ultimately harming decentralization.The second category is complete sharding solutions, which achieve comprehensive sharding of state,transaction processing, and data availability. Since each node only needs to handle a small portion of the network’s workload, the entire network’s throughput can increase almost linearly with the number of shards, truly achieving horizontal, theoretically unlimited scalability. However, this design brings new technical challenges: when cross-shard transactions are needed (for example, a user in shard
A transferring to a user in shard B), the system requires a complex cross-shard communication protocol. Since state updates in different shards are asynchronous, cross-shard transactions cannot guarantee atomicity: either all succeed or all fail. This means developers must separately handle
partially successful intermediate states, greatly increasing application logic complexity, resulting in fundamental differences from programming models in mature ecosystems like Ethereum. On Ethereum, a simple decentralized exchange can complete token swaps, liquidity updates, and fee distribution in a single transaction while guaranteeing the atomicity of these operations. In a sharded environment, if these operations involve states from different shards, developers must redesign the entire application architecture, introducing complex state synchronization mechanisms and error recovery logic. This not only significantly increases the development difficulty and maintenance costs of decentralized applications but also hinders the seamless migration of existing smart contract ecosystems. A large number of mature DeFi protocols, NFT marketplaces, and other applications
need deep restructuring to run on sharded systems. This technical disconnect makes it difficult for new platforms to quickly accumulate ecosystem resources, creating an awkward situation of ”superior performance but lacking applications.”
