Original article: https://www.parity.io/blog/scalability-tradeoffs-polkadot-web3
By Andrei Sandu
Compiled by: OneBlock+
As blockchain continues to pursue higher efficiency, a key question gradually emerges: while expanding performance, must security and system resilience be sacrificed?
This is not only a technical challenge, but also a deep choice in architectural design. Especially for the Web3 ecosystem, a faster system that is built on the basis of sacrificing trust and security is often difficult to support truly sustainable innovation.
As an important promoter of Web3 scalability, has Polkadot also made some sacrifices in its goal of high throughput and low latency? Has its rollup model made concessions in decentralization, security or network interoperability?
This article will focus on these issues, deeply analyze the trade-offs and considerations of Polkadot in its scalability design, and compare it with the solutions of other mainstream public chains to explore their different path choices between performance, security and decentralization.
🧬Challenges in Polkadot’s Scaling Design
The balance between flexibility and decentralization
Polkadot's architecture relies on a validator network and a centralized relay chain. Is it possible that this will introduce centralization risks in some aspects? Is it possible that a single point of failure or control will be formed, thus affecting its decentralized characteristics?
The operation of Rollup depends on the sequencer connected to the relay chain, and its communication uses a mechanism called collator protocol. This protocol is completely permissionless and trustless. Anyone with an Internet connection can use it to connect to a small number of relay chain nodes and submit rollup state transition requests. These requests will be verified by a core of the relay chain, and only one premise needs to be met: it must be a valid state transition, otherwise the state of the rollup will not be advanced.
The trade-offs of vertical scaling
Rollup can achieve vertical scalability by leveraging Polkadot's multi-core architecture. This new capability is introduced by the "Elastic Scaling" function. During the design process, we found that since rollup block verification is not fixed to a certain core, this may affect its elasticity.
Since the protocol for submitting blocks to the relay chain is permissionless and trustless, anyone can submit blocks to any core assigned to the rollup for verification. Attackers may take advantage of this and repeatedly submit previously verified legitimate blocks to different cores, maliciously consuming resources and reducing the overall throughput and efficiency of the rollup.
Polkadot’s goal is to maintain rollup resilience and efficient use of relay chain resources without compromising key features of the system.
Is the Sequencer trustworthy?
A simple solution is to make the protocol “permissioned”: for example, by using a whitelist mechanism, or by default trusting the sequencer not to act maliciously, thereby ensuring the liveness of the rollup.
However, in Polkadot’s design philosophy, we cannot make any trust assumptions about the sequencer because we want to maintain the “trustless” and “permissionless” nature of the system. Anyone should be able to submit a rollup state transition request using the collator protocol.
🏄Polkadot: The uncompromising solution
The solution that Polkadot finally chose is to leave the problem entirely to the rollup state transition function (Runtime). The Runtime is the only trusted source of all consensus information, so it must be clearly stated in the output on which Polkadot core the verification should be performed.
This design achieves dual guarantees of flexibility and security. Polkadot will re-execute the rollup state transition in the availability process and ensure the correctness of core allocation through the ELVES cryptoeconomic protocol.
Before any rollup block is written to Polkadot's data availability layer (DA), a group of about 5 validators will verify its legitimacy. They receive the candidate receipt and proof of validity (PoV) submitted by the sorter, which contains the rollup block and the corresponding storage proof. This information will be processed by the parachain verification function and re-executed by the validators on the relay chain.
The verification result contains a core selector, which is used to specify the core on which the block should be verified. The validator will compare whether the index is consistent with the core for which he is responsible; if not, the block will be discarded.
This mechanism ensures that the system always maintains the trustless and permissionless properties, prevents malicious actors such as sequencers from manipulating validation positions, and ensures resilience even when rollups use multiple cores.
Security
In the pursuit of scalability, Polkadot has not compromised on security. The rollup is secured by the relay chain, and only one honest sequencer is required to maintain liveness.
With the ELVES protocol, Polkadot fully extends its security to all rollups, verifying computations on all cores without any restrictions or assumptions on the number of cores used.
Therefore, Polkadot’s rollup can achieve true scalability without sacrificing security .
Versatility
Elastic scaling does not limit the programmability of rollups. Polkadot’s rollup model supports Turing-complete computations in a WebAssembly environment, as long as a single execution is completed within 2 seconds. With elastic scaling, the total amount of computation that can be performed in each 6-second period is increased, but the type of computation is not affected.
Complexity
Higher throughput and lower latency inevitably introduce complexity, which is the only acceptable trade-off in system design.
Rollup can dynamically adjust resources through the Agile Coretime interface to maintain a consistent level of security. They also need to implement some RFC103 requirements to adapt to different usage scenarios.
The exact complexity depends on the rollup’s resource management strategy, which may rely on on-chain or off-chain variables. For example:
Simple strategy : always use a fixed number of cores, or adjust manually off-chain;
Lightweight strategy : monitors specific transaction load in the node mempool;
Automation strategy : Call the coretime service to configure resources in advance through historical data and XCM interface.
Although the automated method is more efficient, the implementation and testing costs also increase significantly.
Interoperability
Polkadot supports interoperability between different rollups, and elastic expansion does not affect the throughput of messaging.
Message communication across rollups is implemented by the underlying transport layer. The communication block space of each rollup is fixed and is independent of the number of cores allocated to it.
In the future, Polkadot will also support off-chain messaging, with the relay chain as the control plane rather than the data plane. This upgrade will improve the communication capabilities between rollups along with elastic expansion, further enhancing the system's vertical scalability.
🧩What trade-offs do other protocols make?
As we all know, performance improvements often come at the expense of decentralization and security. However, judging from the Nakamoto coefficient, even some Polkadot competitors with lower levels of decentralization still perform poorly.
Solana
Solana does not adopt the sharding architecture of Polkadot or Ethereum, but instead achieves scalability with a single-layer high-throughput architecture, relying on Proof of History (PoH), CPU parallel processing, and a leader-based consensus mechanism, with a theoretical TPS of up to 65,000.
A key design is its pre-public and verifiable leader scheduling mechanism :
At the beginning of each epoch (approximately two days or 432,000 slots), slots are allocated based on the staked amount;
The more you stake, the more you get. For example, a validator who stakes 1% will get about 1% of the block generation opportunities;
All block producers are announced in advance, which increases the risk of the network being subjected to targeted DDoS attacks and frequent downtime.
PoH and parallel processing have extremely high hardware requirements, leading to the centralization of verification nodes. The more staked nodes are, the greater the chance of producing blocks. Small nodes have almost no slots, further exacerbating centralization and increasing the risk of system paralysis after being attacked.
In pursuit of TPS, Solana sacrificed decentralization and anti-attack capabilities, and its Nakamoto coefficient is only 20 , far lower than Polkadot's 172 .
TON
TON claims that its TPS can reach 104,715, but this number is achieved on a private test network, 256 nodes, and ideal network and hardware conditions. Polkadot has reached 128K TPS on the decentralized public network.
TON's consensus mechanism has security risks: the identity of the shard verification node will be exposed in advance . The TON white paper also clearly points out that although this can optimize bandwidth, it may also be used maliciously. Due to the lack of a "gambler's bankruptcy" mechanism, attackers can wait for a shard to be completely controlled by them, or block honest validators through DDoS attacks, thereby tampering with the state.
In contrast, Polkadot’s validators are randomly assigned and revealed with a delay . Attackers cannot know the identities of validators in advance. The attack requires gambling on the success of all control. As long as one honest validator initiates a dispute, the attack will fail and cause the attacker to lose the stake.
Avalanche
Avalanche uses a mainnet + subnet architecture for expansion. The mainnet consists of X-Chain (transfer, ~4,500 TPS), C-Chain (smart contracts, ~100–200 TPS), and P-Chain (managing validators and subnets).
The theoretical TPS of each subnet can reach ~5,000, which is similar to the idea of Polkadot: reducing the load of a single shard to achieve expansion. However, Avalanche allows validators to freely choose to participate in subnets , and subnets can set additional requirements such as geography and KYC, sacrificing decentralization and security.
In Polkadot, all rollups share unified security guarantees, while Avalanche's subnets have no default security guarantees, and some can even be completely centralized. If you want to improve security, you still need to compromise on performance, and it is difficult to provide a deterministic security commitment.
Ethereum
Ethereum’s scaling strategy is to bet on the scalability of the rollup layer, rather than solving the problem directly at the base layer. This approach does not essentially solve the problem, but passes the problem to the upper layer of the stack.
Optimistic Rollup
Currently, most optimistic rollups are centralized (some even have only one sequencer), and have problems such as insufficient security, isolation from each other, and high latency (need to wait for a fraud proof period, usually several days).
ZK Rollup
The implementation of ZK rollup is limited by the amount of data that can be processed in a single transaction. The computational requirements for generating zero-knowledge proofs are extremely high, and the "winner takes all" mechanism easily leads to system centralization. In order to ensure TPS, ZK rollup often limits the transaction volume per batch, which will cause network congestion and gas price increases when demand is high, affecting user experience.
In comparison, a Turing-complete ZK rollup costs about 2x10^6 times as much as Polkadot’s core cryptoeconomic security protocol.
In addition, ZK rollup’s data availability issues also exacerbate its disadvantages. In order to ensure that anyone can verify the transaction, complete transaction data must still be provided. This usually relies on additional data availability solutions, further driving up costs and user fees.
🎈 Conclusion
The end of scalability should not be compromise.
Compared with other public chains, Polkadot has not taken the path of exchanging centralization for performance or pre-set trust for efficiency. Instead, it has achieved a multi-dimensional balance of security, decentralization and high performance through elastic expansion, permissionless protocol design, a unified security layer and flexible resource management mechanism.
As we pursue the implementation of larger-scale applications today, Polkadot’s adherence to “zero-trust scalability” may be the solution that can truly support the long-term development of Web3.
