Web3's cloud infrastructure is taking shape. Polkadot 2.0 rewrites the "on-chain cost" with three technologies

As Web3 infrastructure is becoming more involuted, "how to deploy a high-performance application chain at a lower cost and with greater flexibility" is becoming the most concerned issue for developers. Polkadot, which has just gotten out of the misunderstanding of "slow technology development", is redefining the solution to this problem with an architecture upgrade solution called Polkadot 2.0.

The most prominent part of this upgrade is that it revolves around three technologies: Async Backing, Agile Coretime, and Elastic Scaling. These three seemingly complex underlying changes point to a deep reconstruction of Polkadot's core value - the resource allocation mechanism.

The End of Slot Auction: From “Buyout” to “Rentable”

In the past, deploying a parachain on the Polkadot network required obtaining computing resources on the relay chain through a slot auction. This process is costly, long, and has a high threshold - projects need to pledge a large amount of DOT (usually millions) and lock up for 6 to 24 months just to "buy out" the right to use a core.

This is very similar to data center leasing in the early Web2 era: if you can't afford the high upfront costs, you can't even run the server.

Now, Polkadot has replaced this system with Agile Coretime. It splits "core time" into elastic resources that are billed monthly, hourly, or even per block (the currently feasible solution is monthly), allowing project owners to rent and use execution resources just like using cloud services.

In other words, Polkadot's resource model has evolved from "real estate leasing with annual payment" to "cloud hosting with pay-as-you-go billing."

Async Backing: The key prerequisite for performance acceleration

The premise of flexible scheduling is to have sufficient performance support. To this end, Polkadot introduced Async Backing, a new block packaging and verification mechanism.

In the traditional Polkadot network, all parallel chains’ block generation is “serialized” — once a chain has generated a block and completed verification, the relay chain will take the next turn. This not only causes slow transaction confirmation, but also limits the overall throughput of the network.

Async Backing changes this logic. Now, all parallel chains can submit block candidates at the same time, and the relay chain verifies them concurrently, and then packages and publishes them uniformly. This structure is similar to the "multi-threaded parallel execution" in the Web2 system, which ultimately achieves faster block time (from 12 seconds to 6 seconds), higher execution time (from 500ms to 2 seconds), and stronger transaction concurrency capabilities.

According to official tests, with asynchronous packaging + elastic expansion, the Polkadot network TPS peak has exceeded 100,000.

Elastic Scaling: Automatically scale resources with application size

On the basis of Async Backing providing high performance, Polkadot also launched Elastic Scaling: that is, each parachain can apply for multiple core resources on demand to meet the performance requirements at different stages.

For example, if a blockchain game has a surge in users on the day it goes online, developers can temporarily apply for 3 to 5 core resources from the core market to process requests in parallel. After the peak, the resources will be released and payment will be based on actual usage.

This type of "elastic scaling of resources" capability is similar to the Auto Scaling function provided by AWS and is one of the basic capabilities for building a Web3 cloud service platform.

Agile Coretime ≠ Unlimited Freedom: This is the “Quota System” of Web3

Many people misunderstand that Agile Coretime is a completely free "resource democratization", but it is not. Its essence is to build an on-chain version of the "cloud resource quota system":

  • Core resources are limited and still need to compete according to market mechanisms;

  • Resource scheduling depends on the efficiency of the system chain and relay chain interface;

  • It’s not “you can use it whenever you want”, it’s more like “you can only adjust it if you have a credit limit”.

Under this mechanism, project owners no longer need to "empty their pockets to bid for slots", but they cannot deploy logical chains completely independently like on sovereign chains such as Cosmos/Celestia. Polkadot's freedom is controlled, refined, and predictable.

The core of Polkadot 2.0 is not the "chain itself", but the complete reconstruction of its scheduling, execution and billing models. It does not try to make each chain a super chain, but allows all chains to run like containers in a unified, secure, and high-performance resource coordination system.

In the future multi-chain world, there may not be the “strongest chain”, but there will definitely be the “strongest basic platform”. Polkadot is trying to play this role in resource scheduling and network collaboration.

Disclaimer: The materials provided by PaperMoon and included in this article are for educational purposes only. They do not constitute financial or investment advice and should not be interpreted as guidance for any business decision. We recommend that readers conduct independent research and consult professionals before making any investment or business-related decisions. PaperMoon assumes no liability for any actions taken based on the contents of this article.