Trade-offs of Scalability: The Choice Between Polkadot and Web3

In today's continuous pursuit of efficiency improvement in blockchain technology, a key question is gradually emerging: how to enhance scalability while avoiding the sacrifice of security and system resilience? This is not only a technical challenge but also a deep choice in architectural design. For the Web3 ecosystem, a faster system built on the sacrifice of trust and security often struggles to support truly sustainable innovation.

As an important driver of Web3 scalability, has Polkadot made certain compromises in the pursuit of high throughput and low latency? Has its rollup model made concessions in terms of decentralization, security, or network interoperability? This article will delve into the trade-offs and compromises Polkadot has made in scalability design, comparing them with solutions from other mainstream public chains, and exploring their different choices among performance, security, and decentralization.

Challenges Faced in Polkadot Extension Design

The balance between elasticity and decentralization

The architecture of Polkadot relies on a network of validators and a relay chain. Could this potentially introduce centralization risks in certain aspects? Is it possible for a single point of failure or control to emerge, thus affecting its decentralized characteristics?

The operation of Rollup relies on a sequencer connected to the relay chain, and its communication uses a mechanism called the collator protocol. This protocol is completely permissionless and trustless, allowing anyone with a network connection to use it, connect to a small number of relay chain nodes, and submit state transition requests for the rollup. These requests will be verified by a core of the relay chain, with one prerequisite: they must be valid state transitions; otherwise, the state of the rollup will not advance.

Trade-offs of Vertical Scaling

Rollups can achieve vertical scaling by leveraging Polkadot's multi-core architecture. This new capability is introduced by the "elastic scaling" feature. During the design process, it was discovered that because rollup block validation does not execute on a fixed 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 validation. An attacker could exploit this by repeatedly submitting previously validated legitimate blocks to different cores, maliciously consuming resources and thereby reducing the overall throughput and efficiency of the rollup.

Polkadot's goal is to maintain the elasticity of rollups and the effective utilization of relay chain resources without compromising the key characteristics of the system.

Is ### Sequencer trustworthy?

A simple solution is to set the protocol to "permissioned": for example, by adopting a whitelist mechanism, or defaulting to trusting that the sequencer will not act maliciously, thereby ensuring the activity of the rollup.

However, in the design philosophy of Polkadot, we cannot make any trust assumptions about the sequencer, as it is necessary to maintain the system's "trustless" and "permissionless" characteristics. Anyone should be able to use the collator protocol to submit rollup state transition requests.

Polkadot: The Uncompromising Solution

The final solution chosen by Polkadot is to completely delegate the issue to the state transition function (Runtime) of the rollup. The Runtime is the only trusted source of all consensus information, so it must explicitly state in the output on which Polkadot core the validation should be executed.

This design achieves a dual guarantee of flexibility and security. Polkadot will re-execute the state transitions of the rollup in the availability process and ensure the correctness of core allocation through the ELVES cryptoeconomic protocol.

Before writing data to the data availability layer of Polkadot in any rollup block, a group of about 5 validators will first verify its legitimacy. They receive candidate receipts and validity proofs submitted by the sequencer, which contain the rollup block and the corresponding storage proofs. This information will be processed by the parachain validation function and re-executed by the validators on the relay chain.

The verification result includes a core selector, which specifies on which core the block should be verified. The verifier will compare whether this index matches the core they are responsible for; if not, the block will be discarded.

This mechanism ensures that the system always maintains its trustless and permissionless properties, avoiding manipulation of validation positions by malicious actors such as sorters, ensuring that even when rollups use multiple cores, resilience can be maintained.

Security

In the pursuit of scalability, Polkadot has not compromised on security. The security of rollups is guaranteed by the relay chain, and only one honest sequencer is needed to maintain liveness.

With the ELVES protocol, Polkadot extends its security comprehensively to all rollups, verifying all computations on the core without any restrictions or assumptions about the number of cores used.

Therefore, Polkadot's rollups can achieve true scalability without compromising security.

Universality

Elastic scaling does not limit the programmability of rollups. Polkadot's rollup model supports executing Turing-complete computations in a WebAssembly environment, as long as a single execution completes within 2 seconds. With elastic scaling, the total amount of computable work within a 6-second cycle can be increased, but the types of computations remain unaffected.

Complexity

Higher throughput and lower latency inevitably introduce complexity, which is the only acceptable trade-off in system design.

Rollups can dynamically adjust resources through the Agile Coretime interface to maintain a consistent level of security. They also need to implement some of the requirements of RFC103 to adapt to different usage scenarios.

The specific complexity depends on the resource management strategies of the rollup, which may rely on on-chain or off-chain variables. For example:

• Simple strategy: Always use a fixed number of cores, or manually adjust off-chain;

• Lightweight strategy: Monitor specific transaction load in the node mempool;

• Automated strategy: Configure resources in advance by calling the coretime service through historical data and the XCM interface.

Although automation is more efficient, the costs of implementation and testing have also significantly increased.

Interoperability

Polkadot supports interoperability between different rollups, and elastic scaling does not affect the throughput of message passing.

Cross-rollup message communication is implemented by the underlying transport layer, and the communication block space for each rollup is fixed, regardless of the number of cores allocated to it.

In the future, Polkadot will also support off-chain messaging, with the relay chain serving as the control plane rather than the data plane. This upgrade will enhance the communication capabilities between rollups along with the elastic scalability, further improving the system's vertical scalability.

What trade-offs have other protocols made?

As is well known, performance improvements often come at the cost of decentralization and security. However, from the perspective of the Nakamoto coefficient, even though some Polkadot competitors have a lower degree of decentralization, their performance is not satisfactory.

Solana

Solana does not use the sharding architecture of Polkadot or Ethereum, but instead achieves scalability through 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 publicly disclosed and verifiable leader scheduling mechanism:

• At the beginning of each epoch (approximately two days or 432,000 slots), slots are allocated based on the amount staked;

• The more you stake, the more you distribute. For example, staking 1% of the validators will result in about a 1% chance of block production;

• All block producers are announced in advance, which increases the risk of the network being targeted by DDoS attacks and experiencing frequent outages.

PoH and parallel processing have extremely high hardware requirements, leading to the centralization of validation nodes. The more stakes a node has, the greater its chances of producing blocks, while small nodes have almost no slots, further exacerbating centralization and increasing the risk of system paralysis after an attack.

Solana sacrifices decentralization and resistance to attacks in pursuit of TPS, with its Nakamoto coefficient being only 20, far lower than Polkadot's 172.

TON

TON claims a TPS of up to 104,715, but this figure was achieved under private testnet conditions with 256 nodes, ideal network, and hardware conditions. In contrast, Polkadot has reached 128K TPS on a decentralized public network.

The consensus mechanism of TON has security vulnerabilities: the identities of shard validators may be exposed in advance. The TON white paper also clearly states that while this can optimize bandwidth, it may also be maliciously exploited. Due to the lack of a "gambler's bankruptcy" mechanism, attackers can wait until a certain shard is 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, so attackers cannot know the identities of the validators in advance. An attack must bet on complete control to succeed; as long as there is one honest validator who raises a dispute, the attack will fail and result in the attacker losing their stake.

Avalanche

Avalanche adopts a mainnet + subnet architecture for scaling, with the mainnet consisting of X-Chain (transfers, ~4,500 TPS), C-Chain (smart contracts, ~100-200 TPS), and P-Chain (managing validators and subnets).

Each subnet theoretically can achieve a TPS of ~5,000, similar to the idea of Polkadot: reducing the load of a single shard for scalability. However, Avalanche allows validators to freely choose to participate in subnets, and subnets can set additional requirements such as geographical and KYC, sacrificing decentralization and security.

In Polkadot, all rollups share a unified security guarantee; whereas Avalanche's subnets do not have a default security guarantee, and some can even be fully centralized. If you want to enhance security, you still have to compromise on performance, making it difficult to provide deterministic security assurances.

Ethereum

Ethereum's scaling strategy bets on the scalability of the rollup layer, rather than directly addressing issues at the base layer. This approach essentially does not solve the problem but rather shifts it to the layer above the stack.

Optimistic Rollup

Currently, most Optimistic rollups are centralized, facing issues such as insufficient security, isolation from each other, and high latency (requiring a wait for the fraud proof period, which usually lasts several days).

ZK Rollup

The implementation of ZK rollup is limited by the amount of data that can be processed per transaction. The computational requirements for generating zero-knowledge proofs are extremely high, and the "winner-takes-all" mechanism can easily lead to system centralization. To ensure TPS, ZK rollup often limits the transaction volume per batch, which can cause network congestion and an increase in gas fees during high demand, affecting user experience.

In comparison, the cost of Turing-complete ZK rollup is approximately 2x10^6 times that of the Polkadot core cryptoeconomic security protocol.

In addition, the data availability issues of ZK rollups will also exacerbate their disadvantages. To ensure that anyone can verify transactions, complete transaction data still needs to be provided. This often relies on additional data availability solutions, further increasing costs and user fees.

Conclusion

The end of scalability should not be compromise.

Compared to other public chains, Polkadot has not taken the path of centralization for performance or preset trust for efficiency. Instead, it achieves a multi-dimensional balance of security, decentralization, and high performance through elastic scalability, permissionless protocol design, a unified security layer, and flexible resource management mechanisms.

In today's pursuit of larger-scale applications, Polkadot's commitment to "zero-trust scalability" may be the real solution that supports the long-term development of Web3.