Balancing Scalability, Security, and Decentralization: Polkadot's Technical Choices

In today's blockchain environment, where higher efficiency is constantly pursued, a key question is gradually emerging: must security and system resilience be sacrificed while improving scalability?

This is not only a challenge at the technical level 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 any sacrifices in pursuit of high throughput and low latency? Has its rollup model made any concessions in terms of Decentralization, security, or network interoperability?

This article will delve into these issues, analyzing the trade-offs and compromises in Polkadot's scalability design, comparing it with the solutions of other mainstream public chains, and exploring their different paths in balancing performance, security, and Decentralization.

Challenges in the Design of Polkadot Expansion

Balance of Elasticity and Decentralization

The architecture of Polkadot relies on a network of validators and a centralized relay chain. Could this potentially introduce centralization risks in some aspects? Is it possible to form single points of failure or control that could affect its Decentralization characteristics?

The operation of the Rollup relies on the sorter of the connected 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 requests for state transitions of 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 be advanced.

Trade-offs of Vertical Scaling

Rollups can achieve vertical scalability by leveraging Polkadot's multi-core architecture. This new capability is introduced by the "elastic scaling" feature. It was discovered during the design process that since rollup block validation is not fixed to a specific 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 exploit this by repeatedly submitting previously validated legitimate blocks to different cores, maliciously consuming resources and thus reducing the overall throughput and efficiency of the rollup.

The goal of Polkadot is to maintain the flexibility 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 by default trusting that sorters will not act maliciously, thus ensuring the activity of the rollup.

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

Polkadot: An Uncompromising Solution

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

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

Before writing the data availability layer of Polkadot on 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 parallel chain validation function and re-executed by the validators on the relay chain.

The verification result includes a core selector, which is used to specify which core the block should be validated on. The validator will compare whether this index is consistent with the core they are responsible for; if it is inconsistent, the block will be discarded.

This mechanism ensures that the system always maintains the attributes of trustlessness and permissionlessness, avoiding manipulation of verification positions by malicious actors such as orderers, ensuring that even with multiple cores used in the rollup, elasticity can be maintained.

Security

In the pursuit of scalability, Polkadot does not compromise on security. The security of rollups is guaranteed by the relay chain, requiring only one honest sequencer to maintain viability.

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

Therefore, Polkadot's rollup can achieve true scalability without sacrificing security.

Universality

Elastic scaling does not limit the programmability of rollups. Polkadot's rollup model supports the execution of 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 executed within a 6-second cycle is increased, but the types of computations are not affected.

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 fulfill certain RFC103 requirements to accommodate different use cases.

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 core or manually adjust off-chain;

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

• Automated strategy: Configuring 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 of 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 acting as the control plane rather than the data plane. This upgrade will enhance the communication capabilities between rollups alongside elastic scaling, further strengthening the system's vertical scalability.

What trade-offs have other protocols made?

As we all know, 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 still unsatisfactory.

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 publicly disclosed and verifiable leader scheduling mechanism:

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

• The more you stake, the more you will receive. For example, a validator staking 1% will have about a 1% chance of producing a block;

• All block producers are announced in advance, increasing the risk of the network suffering targeted DDoS attacks and frequent outages.

PoH and parallel processing have extremely high hardware requirements, leading to the centralization of verification 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 that the TPS can reach 104,715, but this figure is 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 identity of the shard validation nodes 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 shard is completely under their control, or disrupt honest validators through DDoS attacks, thus altering the state.

In contrast, Polkadot's validators are randomly assigned and revealed with a delay, so attackers cannot know the identity of the validators in advance. The attack must bet all control for success, and as long as there is one honest validator to initiate a dispute, the attack will fail and result in the attacker losing their stake.

Avalanche

Avalanche adopts a mainnet + subnet architecture for scalability, 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).

The theoretical TPS of each subnet can reach ~5,000, similar to the idea of Polkadot: reducing the load of a single shard to achieve scalability. However, Avalanche allows validators to freely choose which subnets to participate in, and subnets can set additional requirements such as geographic 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 increase security, you still have to compromise on performance, and it's difficult to provide deterministic security commitments.

Ethereum

Ethereum's scaling strategy bets on the scalability of the rollup layer rather than directly solving issues at the base layer. This approach essentially does not solve the problem but rather passes it up to the next layer of the stack.

Optimistic Rollup

Currently, most Optimistic rollups are centralized (some even have only one sequencer), which leads to issues such as insufficient security, isolation from each other, and high latency (requiring a waiting period for fraud proofs, usually several days).

ZK Rollup

The implementation of ZK rollup is limited by the amount of data that can be processed per transaction. The computational demands 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 lead to network congestion and rising gas fees during high demand, affecting user experience.

In comparison, the cost of a 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 chosen the path of sacrificing decentralization for performance or trading efficiency for pre-established trust. Instead, it achieves a multidimensional 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 adherence to "zero-trust scalability" may be the true solution that can support the long-term development of Web3.