First time posting here with some very exciting news. Elastic Scaling MVP is going to hit Rococo and Westend testnets by the end of this month! 🚀🚀🚀

bafybeichewx3qqzpydvfphng6wfbbn7psyg6m5qqthly37pw563eakys5y

Elastic Scaling

The number of validators participating in parachain consensus will be bumped from 300 to 500 on Kusama!  This means the total core count can also be increased to 100, security is improved and backing vote rewards are more fairly distributed.

[See full forum post](https://forum.polkadot.network/t/update-parachain-validator-set-size-increase-on-kusama/8218)


bafybeianmour36muqeu5woshns5qbodebf5n3gnnxs3atnzlyzu6i4q6uq

Kusama parachain validator count going up

Coretime is specified in [RFC-1](https://polkadot-fellows.github.io/RFCs/approved/0001-agile-coretime.html#notes-on-economics), but only briefly explains an example pricing model and specifically states that the described model should only illustrate that a solution exists, but should not be treated as a concrete proposal.

This blog posts explains a concrete proposal we want to launch on Kusama and if all goes well also on Polkadot.

So let's start with requirements.

## Requirements on the model

A very basic requirement of any auction is to be able to find the right price. For coretime we go with a variant of the [Dutch auction](https://en.wikipedia.org/wiki/Dutch_auction) for its simplicity and its ability to handle selling of multiple items of the same good at once. Given enough time and fine enough price resolution front-running should also be very limited.

Another requirement we have is that we are selling core time and a major consumer of blocktime are heavy duty blockchains for which coretime is crucial and downtime is unacceptable. Those chains will be willing to pay a premium to get guaranteed continuous coretime: They ideally don't want any risk of getting front run and outbid. What they also want is being able to plan ahead and know for the upcoming year what they are going to pay for coretime (the most).

The third and final requirement is that we want the market to be stable. In particular price manipulation attacks should not be (easily) possible. In particular they must not be amplified.

## Sales

Coretime is organized around 28 day regions. In the first 28 days' region there is a sale happening for the coretime of the next 28 day region and so forth. So while the cores of the previous sale are served, the sale of the next region is ongoing. The sale over that 28 day period is organized in phases.

RFC-1 specifies a basic model for the price function, consisting of three phases:

1. The interlude phase
2. The leadin period
3. Stable minimum price at the end

A most basic implementation would be linear and look something like this:

![](https://ipfs.subsocial.network/ipfs/bafybeieukc3ho52cvtdudpxeqxr7nbki7hdpr5uc7rpojnnbat22ntwrkq?type=.png)

Now let's look into these phases.

### Interlude Phase (Renewals)

This phase is interesting and allows us to fulfill requirement (2): Providing a way to offer guaranteed coretime to heavy duty blockchains.

In this phase only renewals are allowed, the regular sale has not yet started, so you can not be outbid or front run. So what exactly is a renewal? For heavy duty blockchains, which actually absolutely need a block every 6s, they can ask for a renewal of their coretime, assuming they assigned their previously purchased whole 28 days region to one parachain, unshared.

So how does it work in practice?

First let's clarify renewals a bit, as they are actually a bit involved. Usually you will at some point (ignoring legacy auction leases for now) have
purchased coretime via the market we are describing in this very blog post. The price you paid there will be recorded and you are eligible for renewal in the next period, using that same price. Now this renewal will then in turn also already predetermine the price you will need to pay for the next: It is the minimum of the price you paid for this one + `renewal bump` (e.g. 3%) and the market price (e.g. in the interlude phase - only phase where renewal is guaranteed, the maximum price). So TL;DR: The price you pay in a renewal is always predetermined one period ahead, which is meant to help with price predictability.

Therefore, if you do your `renew` call in the interlude, you get a guarantee on your core _and_ you can calculate an upper bound on the cost.

This fulfills all the requirements. The issue is, is this "fair" and does it conflict with other requirements? One goal of Agile Coretime was to maximize resource utilization. Occupying a core fully, if most of your blocks are empty is not a good use of the validator's time. Therefore the renewal system should only be attractive to chains which really need consistent block times every 6 seconds. Luckily the described system achieves that:

As mentioned, if you want a guarantee for your renewal, you have to do it in the interlude phase, but this also implies that the price you are paying for the coretime will keep going up by `renewal bump` until it hits the upper bound of the current market, where it is capped. Therefore at least over time, you will pay more for your coretime than people competing on the open market. Hence if you can afford some risk, you will move back to the open market again and maybe even consider secondary markets, where you can buy coretime every 12s or even less frequent, if that fulfills your need equally. On top of that there is also on-demand coretime.

### Leadin Phase

In that phase we go down from the maximum price of the interlude down to the minimum price (configured and adjusted over time). In the simplest form this is simply linearly going down over e.g. 2 weeks. This is the Dutch auction part and people can buy the still available cores whenever the price appears low enough to them.

### Stable Minimum

The last section is whatever is left of the 28 days period. Here the price just stays stable at the minimum and any last buyers can still buy cores, in case they were not sold out before.

## Price Adjustments

Now with the general explanations out of the way, let's dive deeper into how things actually work and where things are becoming problematic.

1. How should the leadin curve actually look? Is linear a good fit? And if so, how big should the factor be: Like how much larger than the minimum price should the interlude price be?
2. How do we determine and adjust the minimum price from period to period?

The original proposal of RFC-1 suggested a linear model, with the minimum price being the actually expected sale price (more or less). Performance of the market would be measured with how many cores we intended to sell, vs. how many we actually sold. If we sold all cores we would adjust the minimum price to the sell out price + some additional percentage.

This model was adjusted and tuned and deployed on Kusama and it immediately proved to be problematic. Let's assume for example (similar to what actually happened on Kusama) there was only a single core for sale and that one was sold out right at the beginning of the leadin period. This would have resulted in the next minimum price to be that high price + some percentage.

This was causing some conflicts, because on the one hand you would want a high leadin factor to better capture the right price (otherwise you have to guess really well), but the higher the leadin the higher the next minimum price might go - it would overcompensate. In the example above, a single person willing to pay e.g. 10x, would have driven the minimum price to at least those 10x for the next sale, which now might have 10 cores or more for sale: Price manipulation was being amplified!

## Proposed New Curve and Adjustments

Therefore we needed something better and I decided to change the broker pallet to no longer adjust based on cores sold, but rather on the achieved price directly and made sure price manipulation attacks would no longer be possible. Full details on [this ticket](https://github.com/paritytech/polkadot-sdk/issues/4360), actual code [here](https://github.com/paritytech/polkadot-sdk/pull/4521).

Let's start with the curve. First by changing how price adjustments work, we are now able to use really high leadin factors: We are going with 100 for now. Furthermore we define a target price, which is no longer the minimum, but in the middle of the leadin. Meaning our target price is ten times the minimum price and the interlude price is ten times the target price or 100 times the minimum price. We therefore allow the target price to be off in both directions of a factor of 10 and would still be able to capture the value correctly.

We no longer have a plain linear curve, but instead are approximating an
exponential model to have the target price in the middle of the time period as
well:

![](https://ipfs.subsocial.network/ipfs/bafybeibax7wjhg7m4mdjs74zcfe3lp2siwljczdy6wstokm4kskeer7tqy?type=.png)

Now, how do price adjustments work? Quite straight forward: We define the next target price as the sellout price of the previous sale. If the last sold core was sold at 10 DOT for example, we would configure the minimum price of the next sale to be 1 DOT.

Now have we resolved our issue with price manipulation? Yes! Let's assume the minimum was 1 DOT, the maximum therefore 100 DOT. Someone bought that one core that was for sale for that 100 DOT. In the next sale period the minimum price would still only be 10 DOT, which was the target price of the previous sale. We therefore achieved two things here:

1. The worst thing that can happen from one sale to the next is that the new minimum price is the old target price. Meaning, even in that extreme scenario people get cores for the price that was seen as the "market price" anyways just one sale before.
2. There is no amplification anymore. That 100 DOT sale, only brought up the minimum price to 10 DOT. That is still 10 times cheaper than the investment.

### Renewal Price

To make the model work even in case of renewals, I had to made adjustments to what we consider the sellout price. In RFC-1 renewals would not affect the sellout price, this is now no longer the case and the renewals affect the price just as normal purchases.

With this, even a market only consisting of renewals still has a market price, ensuring the open market stays aligned with renewals. On the flip side if a renewal is made in the leadin, it is competing with the regular market and could be outbid anytime, we therefore also record the price that was paid for the renewal as the sellout price (if it was the last purchase).

For a normal market where renewals are done in the interlude and there are still some cores left for sale, the taking into account of renewals will have no effect whatsoever as the sellout price used is the last price that was achieved.

## Renewal Price for Expired Leases

We covered in the "Interlude Phase" how renewals work for cores that have been bought with coretime. There is another way to be allowed for renewals and that is if you have been a lease holder in the now obsolete auction model. In that case your first renewal price will be determined by the target price of the sale period where your lease expires.

## Further (future) Alternatives

The proposed curve is already hinting into a direction that has been suggested as an alternative by a few people: Instead of having a linear curve or a linear curve with a dent in the middle, we could go all the way and create an exponential leadin curve. An advantage of an exponential leadin would be that price adjustments of the minimum price would likely not be needed at all, except if the price ever moved into the very steep part of the curve, then we might run into problems with price changes being too high from block to block.

Such a drift, if a problem at all, would only happen very slowly though and thus could easily be addressed via governance. I personally would therefore consider a full exponential curve a valid alternative solution and should definitely be reconsidered if the here proposed solution is still showing any problems in practice.



bafybeigdzpj4h3owqjb4out62sowqp4lcjwf54dawajyaz36y5i5gsnu7y

Agile Coretime Pricing Explained

bafybeihwinbcaagoyevmuabcm6yhihet6brv6bfu6chdatdujb6cy7ox2u

Checkout Rob's blog post about how he sees the future of Polkadot [here](https://www.rob.tech/blog/plaza/). I think this is exactly the right approach to make Polkadot shine and show to the world what it is capable of. 

1. Keep it simple as long as it works.
2. Provide the means to extend even further once necessary.

The future: A perfectly connected network of megacities!

I am excited, this is what I want to build. How about you? You can raise your voice [here](https://polkadot.polkassembly.io/referenda/885).

bafybeihy3vejmdfs3pyeockl7yxbhlww33pvsu5n226naypda7e3zjvwku

Rob straight to the point: The Plaza

# **Proposing the Plaza: A Batteries-Included, Scalable Polkadot System Chain**

bafybeifoahbcv465cqt6cbsblnvsfz6x3nabls24d5pafcometiakyti3u

I already explained among other details how renewals work in [this post](https://grillapp.net/@eskimor/agile-coretime-pricing-explained-166522?ref=12935). Here I want to go into more details on how your renewal price will be determined.

The first concept to realize is that your renewal price is always pre-determined, you know exactly what you are going to pay beforehand.

Ok, so when is the price of your renewal determined? There are three options:

1. When you bought your core regularly previously (call to `purchase`) 
2. When your legacy auction model lease expired
3. At your previous renewal (previous call too `renew`)

Now that we know how the price is determined, that you are paying in `renew`, let's look into how it is determined in each of those cases:

## Renew after regular `purchase`

If you are renewing the core for the first time, after you purchased it regularly in the previous cycle, then the price for your renewal will be exactly the price you paid on that earlier `purchase`.

## Renew for lease holding chains

There used to be some confusion, which I want to clear up a bit here. Matters are a bit complicated because a sale in period X is for period X+1 and in that sale, parameters are set.

What happens exactly is that if your lease is going to expire in period X+1, this will be noticed at the sale rotation in sale X. It will still grant you a core for the entire period X+1, even if your lease ended technically in the middle of that period and it will mark the core eligible for renewal in that period X+1. The third thing it does, is what lead to confusion: It also removes the lease from the state already: Conceptually your lease ends in period X + 1, but it already gets removed in period X  (after you got granted your final period of coretime and the renewal rights). Hence UIs, which directly read the state will show that you no longer have a lease, despite the fact that you still have a core and also can not yet renew. 

For the actual price: The renewal right is given in the sale before, which only has the sale data of the sale even before that. Therefore you will be able to renew at the sellout price of the sale X-1, if your lease expires in X+1.



## Renew after renew

You already renewed before. In that case, the price for your renewal had been determined at that previous renewal, like this:

Either the price you paid for your previous renewal, increased by the configured renewal bump (3% on Kusama right now) or the market price at that time of the renewal: Whatever is cheaper.

In the interlude phase of the sale (the first part where the open market is not yet opened), this will usually be the bumped previous renewal price, except the market price dropped significantly over the sales.

What you can technically do, to reduce the price of your next renewal is to not renew in the interlude, but in the leadin: If you wait long enough, the price will be lower than the bumped renewal price and you get a better renewal price at the next cycle, but:

1. In the leadin period the market is already open, so your renewal is no longer guaranteed, you can be outbid.
2. If you are willing to accept some risk to lower your cost, a regulare `purchase` makes actually more sense as you will get the achieved lower price immediately at that `purchase` , instead of just setting that lower price for your next `renew`.



## Summary

1. Your renewal price is always determined beforehand (previous renewal, expired lease, previous purchase). You will always know one cycle ahead of time how much your renewal will cost.
2. Your renewal price will increase each sale cyle. The best way to reduce it again is to accept some risk and do a regular `purchase` on the open market (leadin phase) instead of renewing. The risk can be controlled: The sooner you buy in the leadin (the higher the price still), the lower the risk of getting outbid.
3. The renew price you pay for an ended release will be the sellout price of the sale before the previous one: It is predetermined a full cycle ahead of time. 

I hope that cleared things up! Happy core time!


bafybeih465qfjocr4vl6f3hf3b36bcuywfunc4v6lpbd2mqqaq32umsyle

Agile Coretime Renew Pricing Explained

More details on how the renewal price is determined !

bafybeidkg4khevt4e4m6gaxzm6jogmu4ax36pzuk62efaccw3yrsd2inwa

Need more than one core ? No problem, the first version of Elastic Scaling was just launched  🚀🚀🚀 . To try it out or learn more check out this [forum post](https://forum.polkadot.network/t/elastic-scaling-mvp-launched/9392)  

bafybeicr6sja4s6ipa7q3b6j76bk25al6555hhnh5cli3kaklit2nvkifq

2s blocks and 3x more throughput

***It’s no secret that Polkadot is the most scalable technology for building and hosting any kind of Web3 application. In the past year I’ve been working with an awesome team at Parity to implement and deploy Elastic Scaling, a game changer for rollup scalability and the Web3 cloud.*** 

***In this article I aim to explain the scalability story of Polkadot, the value proposition of Elastic Scaling and how the Web3 Cloud compares to traditional Web2 Clouds.***

***Before I dive into it, I want to thank Joyce Siqueira, Natalie Tillack, and Oliver Brett for their additional input and help.***

In the context of blockchains, it has been frequently argued how the technology behind Polkadot offers a compelling solution to the scalability problem. In Web3 this problem refers to the limitations of networks in handling a growing number of transactions. Without a proper solution, this can lead to network congestion, slower confirmation times, and higher fees. Several factors contribute to these issues, including block size, network bandwidth, storage requirements, and consensus mechanisms. 

To solve them, Polkadot splits load across many interoperable rollups (previously known as "parachains") which are secured by the Relay Chain. In the past few years we’ve continued to innovate and improve this amazing technology. We have incrementally pushed the evolution of Polkadot by scaling up in all dimensions and introducing layers of abstraction to ultimately shift the perspective towards a first-of-its-kind Web3 Cloud.

In this post we will explore Polkadot's scalability, discussing the scaling techniques that have been implemented, those still to come, including Elastic Scaling, and the general scalability challenges of Web3 applications. 

Our journey starts by going back in time to understand how Polkadot evolved to its current state.

## The Polkadot decentralized multicore computer

Launched in 2021 and completed two years later, Polkadot 1.0 was the first step towards a multicore "world computer". It represented a groundbreaking advancement in blockchain technology: a fully decentralized and scalable platform supporting a multitude of interconnected rollups.

Well ahead of its time, this innovative architecture allowed for a vast array of use cases, from decentralized finance and supply chain management to identity verification and gaming: [Centrifuge](https://polkadot.com/case-studies/centrifuge-real-world-asset-tokenization) , [Hydration](https://polkadot.com/case-studies/hydration-liquidity-management-defi-efficiency) , [Kilt](https://www.kilt.io/) are just some of these examples. This architecture allowed Polkadot to address the scalability problem at the L1 level from day one. We now see others considering similar solutions: for example the Ethereum Foundation has recently proposed to build [native rollups](https://x.com/2077Research/status/1883980391301755100).

Polkadot introduced the concept of “a core” as a fundamental unit that provided compute and bandwidth for rollups. Note that a core's resources can be consumed by rollups every 12 seconds. A total of 50 cores were available at the time, each one providing the following resources:

* 500ms of execution
* 5MB of bandwidth

**What is a core in Polkadot?** *It is important to make a distinction on how Polkadot cores are fundamentally different from regular CPU cores. The actual computation is not performed once, but multiple times to ensure that the result is verified in a fully trustless and decentralized way. At the lower levels it is implemented via specific protocols that leverage cryptography and economic incentives to ensure that the outcome of the computation is correct.* ***No malicious actor can prevent the computation from happening or alter its result.***

**How does a Polkadot core provide bandwidth?** *Due to its decentralized nature, Polkadot doesn’t make any assumptions about the input data storage location in relation to the compute resources location. The Polkadot DA (data availability) layer uses erasure coding to securely store the data in smaller redundant fragments on as many different nodes as possible. Each core provides the necessary bandwidth for this process. This is a necessity for implementing a fully trustless and permissionless system that can securely store these inputs. The bandwidth of the core bounds the size of the input available for computation.*

Polkadot has made a few early simplifying assumptions that had significant impact on both vertical and horizontal scalability in the short and medium term:

* core resources can be used only once every 12s
* each rollup is only able to use a single core

This resulted in a hard cap of maximum 50 rollups running on the global computer. Rollups are able to connect to Polkadot in a fully permissionless and trustless way after acquiring a core by participating in and winning [auctions](https://polkadot.com/auctions).

However, these simplifying assumptions are not to be considered one-way doors. In the next section you will learn how Polkadot has dramatically improved the rollup scalability story.

## Polkadot 2.0 - faster and more accessible

### Horizontal scaling

We’ve incrementally optimized and improved the consensus technology of Polkadot so the validator count can be raised from 200 validators (2021) to 500 validators (2024) with a goal of 1,000 validators (2025). 

This increased the number of usable cores and how many rollups can run on Polkadot. It also increased the resilience and security of the network, skyrocketing Polkadot to the top of the pile as the PoS network with the highest [Nakamoto coefficient](https://nakaflow.io/) . Learn more about why decentralization (measured by this coefficient) is important when comparing different networks in this [short video](https://youtu.be/%5FdXNNeqdYmw?si=9Vd0Za218QAL6v3O).

![](https://lh7-qw.googleusercontent.com/docsz/AD_4nXe1fuaVPj0LyZF5pTQMVPDaSjB2NRBSEedFt3DxihOKlGLzI5JxTO7SNCywyFFgmYhNDoF6LCcmuNSmMPd1QY5ufBaH_S4OZa00u048MIuvHBrPW1HVt-USzY6itKdeSBiQZih0vQ?key=lxKM9hDQF-1dD94s3F2cxQlX)

In December 2024, Polkadot demonstrated what performance can be achieved with just 15 cores (out of 100) during “[The Spammening](https://polkadot.com/spammening)”. It already outpaces top competitors like Solana and Aptos, proving its technical edge and, while impressive, these results only scratch the surface of Polkadot’s true potential. 

![](https://lh7-qw.googleusercontent.com/docsz/AD_4nXeYzATKm_5kzj11PNSMMgh441UDP9zEkQ-NxlVTlZq3urhZExKmMYoLPq0MBJSLetf10rtREv55EqwRmb6kusi_1sAMUZks5GzhWpb5kE3UmuRRdPNWnKnUUQwis2om7yRrRxOipQ?key=lxKM9hDQF-1dD94s3F2cxQlX)

Polkadot is not only the fastest in terms of throughput, but is also the leader in terms of data availability bandwidth by far.

![](https://lh7-qw.googleusercontent.com/docsz/AD_4nXd49H9Er44Rjb0C0D8mxLEnBEnmIL7fF_oRNcZLf1UYrd10QNOJkWDew34R5KrD5URfBssPFiJWypZMZgvHlpU9_tVfjDnaBaq34yEg2JgRD9VvLdElTjRZRxK_s0L54g7HOB9V?key=lxKM9hDQF-1dD94s3F2cxQlX)

Check out the full December live test results [here](https://polkadot.com/reports/polkadot-spammening-report-2024.pdf).

### Vertical scaling 

In 2024, Polkadot launched a [major protocol upgrade](https://polkadot.com/blog/the-way-to-a-10x-throughput-lift-on-parachains) to further scale the overall network capacity vertically as well as improving individual rollup performance characteristics. This feature reduced the rollup latency from 12s to 6s, effectively allowing one core’s worth of resources to be consumed every 6s. This doubled the individual rollup throughput. At the same time the compute resources a core provides was increased from 500ms to 2s which represents an additional 4x increase in throughput.

Following that upgrade, [Agile Coretime](https://polkadot.com/agile-coretime) was launched. It rendered the auction model obsolete and lowered the entry barrier for builders. It enabled simpler and more efficient management of compute and data availability bandwidth resources. What was once a very static model of resource consumption is now dynamic, allowing two distinct ways for rollups to acquire and use cores:

* Bulk: A fixed duration of continuous core allocation represented by an NFT that can be purchased through coretime sales with DOT. It can be split, shared, or resold, enabling rollups to share the same cores, effectively doubling the cap on how many rollups can run in the system.
* On-demand: As the name suggests, a single core can be acquired and used immediately when needed.

## Elastic Scaling - more vertical scalability

Scheduled to be launched in Q2 2025 on Polkadot, Elastic Scaling provides a proper solution to the scalability challenges that are currently affecting successful Web3 applications.

**High Transaction Fees:**

Network congestion on popular dapp platforms like Ethereum often leads to a bidding war driving up transaction fees ([gas chart](https://ycharts.com/indicators/ethereum%5Faverage%5Fgas%5Fprice)), as reported [here](https://cointelegraph.com/news/ethereum-gas-fees-rose-498-in-two-weeks-as-network-activity-surged-report). The focal point of the problem in most cases is the architecture which has inherent limitations in transaction throughput (transactions per second).

The effect is of great consequence, hindering the large-scale adoption of Web3 technology in critical sectors like financial services, for example. We can look at DeFi applications and reason that compared to their Web2 counterparts they suffer from:

* Throughput bottlenecks, leading to much lower performance and usability
* Higher cost of microtransactions and frequent interactions

**Slow Transaction Times:**

Network congestion can slow down transaction confirmation times, which negatively impacts the user experience and creates significant limitations for real-time Web3 applications.

**Web2 has incrementally raised the bar in terms of UI and UX, conditioning users to expect applications that are both fast and responsive. Slow-loading applications are simply unacceptable in today's digital landscape, and we must strive to bridge the gap and meet these heightened expectations.**

### The Benefits of Elastic Scaling - Use Cases and Examples

Polkadot’s transition as a first mover into the Web3 Cloud space means that it has become inherently scalable. It is able to satisfy the most demanding use cases - something it could not do before. As such, we are pushing the industry scalability gap between Web2 and Web3 to grow ever shorter. 

The value proposition of Elastic Scaling is built around key use cases that were not possible before due to the aforementioned unsolved challenges. All rollups running on Polkadot can adjust their usage of core resources on the fly to match any of the following application profiles:

#### High throughput, low latency

![](https://ipfs.subsocial.network/ipfs/bafybeigy63umgai5mfvu7mbptk76tr2zjfhjfqiszstzuwfr7dkhlxibhe)

Popular games with millions of players are a prime example of CPU-intensive applications. Gamers anticipate that their actions will have immediate results. Minimizing transaction latency is crucial for enhancing the Web3 gaming experience and bringing it closer to the engagement level of Web2 games.

#### High throughput and bandwidth 

![](https://ipfs.subsocial.network/ipfs/bafybeiejg4hr4wbln6rd5urymz5ycv3kqcn45thgsvzk6damoxjbtwe5qa)

Elastic scaling can significantly increase the speed of CPU and bandwidth-intensive applications, such as airdrops, account migrations, and storage migrations, potentially up to six times faster.

#### Low throughput, high bandwidth 

![](https://ipfs.subsocial.network/ipfs/bafybeiadbubjoukwec2fxvxxsvrzbdzlglqq4mwzp7f7n3svepvwesmdze)

Solutions for L2 availability, decentralized storage, IoT networks, or other DePIN use-cases, might require significant bandwidth but less CPU. These applications can scale their bandwidth usage up to 12MB/s when the need arises.  

#### Low latency

![](https://ipfs.subsocial.network/ipfs/bafybeid24kwuifrofxg2tesetyh4axijafssqda7yuv4ut52zfjcvspfyy)

Applications using 12 cores can confirm transactions in 500ms, improving user experience and efficiency where speed is critical, such as in high-frequency trading.

## Elastic Scaling gives Web3 real cloud capabilities

One of the key properties of any Web2 cloud is that the applications they host can scale their resource usage up and down to achieve lower costs or better end user experience. Polkadot cannot truly become the first Web3 cloud unless it is able to exhibit the same property. 

**To achieve the Web3 Cloud vision, we have improved the scalability story of rollups in Polkadot. And we have done so without compromising the long term value of security and decentralization for short term gains in performance or scalability.**

The table below shows how Polkadot further improved rollup scalability with the introduction of Elastic Scaling.

| **Polkadot 1.0**               | **Polkadot 2.0** | **Polkadot 2.0 + Elastic Scaling** |                |
| ------------------------------ | ---------------- | ---------------------------------- | -------------- |
| Execution time (per 6 seconds) | 500ms            | 2s                                 | Up to 12s\*\*  |
| DA bandwidth/storage           | 0.9MB/s          | 0.9MB/s                            | Up to 12MB/s   |
| Latency (confirmation time)    | 12s              | 6s                                 | 500ms          |
| Number of cores                | 1                | 1                                  | Up to 12 cores |

*\*\* The execution time and maximum number of cores that can be fully used depend on how fast the sequencer hardware is.*

Elastic Scaling builds on the existing capabilities of Polkadot without introducing new concepts or requirements for rollups. It simply allows rollups to dynamically provision and scale the resources needed to improve the end user experience.

Sequencers will submit the state transitions as they are built, but their verification happens in parallel on the Relay Chain, enabling the multi-core architecture for a single rollup. While the validation is a parallelizable process, the state transitions still need to form a chain. This indicates future performance improvements should be possible by improving the speed of sequencers.

### Can rollups be the VMs of Web3?

In a Web2 cloud environment, the physical hardware resources are partitioned into virtual machines of arbitrary size. For example, one 64-core bare metal machine can be partitioned into 32 dual-core VMs, or 16 quad-core VMs. Then each of these VMs are used to host one or many applications running in parallel.

The introduction of Elastic Scaling enables Polkadot to partition its resources dynamically in a similar fashion. Each rollup becomes a VM with an arbitrary number of Polkadot cores. 

A VM using a single core can consume two seconds of execution every six seconds.

![](https://lh7-qw.googleusercontent.com/docsz/AD_4nXe1QzPHF3Mc2APYHjQ_socQNuJyVBTJw2CMdxwtcxikvY2ypnEgOedLSOsU05B-pUXnmEbwNXtkZpA5LNrsKpLA_119lzsJpGc5V_XAI2bhLH9RJRv2tp4YSZkJm-M6df_lp-cO?key=lxKM9hDQF-1dD94s3F2cxQlX)

A VM can use Elastic Scaling to increase its computational power three times.

![](https://lh7-qw.googleusercontent.com/docsz/AD_4nXe1WDWgeJBs8bUrfPL59DoxIog9bj0IRpa-6Gfom4vkePRLXXCRhCkstjHxa93Nn26Edz53fTfEui1YysjjxYJpYkyAXXxthkXsqW9FtLFrPI3eh351z-Jnb6GAz96zYcIdqbQtwQ?key=lxKM9hDQF-1dD94s3F2cxQlX)

## Polkadot vs Web2 cloud - similar but different ?

Web2 clouds (like AWS, GCP, etc) have introduced a few key concepts that are widely understood and accepted:

* **Scalability:** The ability of a system to handle growth, achieved through horizontal scaling (adding more machines) and vertical scaling (adding more power to an existing machine).
* **Compute:** The ability to run applications and workloads on-demand, without the need to own the physical infrastructure.
* **Storage:** The ability to store data in a reliable and durable way, with easy access from anywhere.
* **Networking:** The ability to connect applications and services to each other with high performance and reliability.
* **Security:** The ability to protect data and applications from unauthorized access, use, or disclosure.
* **Management:** The ability to provision, monitor, and manage cloud resources.

By definition, the Web3 Cloud doesn’t stray away from these. Instead, it strongly aligns all of them with the Web3 mission. What we get is a fully permissionless, trustless, decentralized and transparent Cloud that empowers builders to securely own and manage compute, storage, bandwidth and networking resources. 

Developers can leverage the technology stack of Polkadot to build unstoppable applications that are highly reliable, performant, and secure but at the same time can scale to meet the ever increasing demands of end users.

To gain a clearer understanding of how Web2 and Web3 cloud compare and contrast, the table below provides a side-by-side comparison:

| **Any Web2 Cloud** | **Polkadot**                                   |                                      |
| ------------------ | ---------------------------------------------- | ------------------------------------ |
| Compute            | Centralized, Heterogenous CPUs                 | Decentralized, Standardized Cores    |
| Storage            | Disks                                          | DA layer, rollup state               |
| Networking         | Trust-based, VPC, Subnets                      | Trustless networking, DMP, UMP, XCMP |
| Security           | Trust-based security,IAM, security groups, etc | Trustless, crypto-economic security  |
| Management         | Permissioned, CloudFormation, Terraform, etc   | Permissionless, RPC                  |
| Scalability        | Horizontal and vertical scaling                | Horizontal and vertical scaling      |

### The world needs the Web3 cloud

Web3 has demonstrated solutions to solve problems that have been ignored or exacerbated for so long by Web2\. It should not be viewed as a drop-in replacement, but rather as an augmentation. 

Polkadot can host any kind of Web3 application and provides the scalability properties required for a seamless integration of Web2 and Web3 technologies into a unified end user experience. It is now possible to reduce or completely remove the trust users need to have in current centralized Web2 applications and systems. 

When implemented properly, Web3 services tremendously improve resilience, censorship resistance, ownership, privacy, security and transparency on behalf of end users:

* Financial services, offering lending, borrowing, and trading without intermediaries
* Enhanced transparency and traceability by recording every step of a product's journey on an immutable ledger.
* Representing ownership of art, collectibles, and other digital items.
* Creating in-game economies that enables true ownership of digital assets by players.
* Secure and self-sovereign digital identities, reducing fraud and enhancing privacy.
* Transparent and tamper-proof voting, increasing trust and participation.
* Streamlined property transactions, reduced paperwork, and increased transparency.

---

Finally, we can conclude that Polkadot isn’t just making Web3 better, it's changing the game entirely. With Elastic Scaling, rollups can adjust their throughput and latency on the fly, meaning we can finally have awesome performance without sacrificing security or decentralization. 

The future of the internet is in the Web3 cloud, built on the foundation of **less trust and more truth**. Polkadot is where this future is being created right now. Join us and let’s build it together!

Github: <https://github.com/paritytech/polkadot-sdk>

Forum: <https://forum.polkadot.network/>

Wiki: <https://wiki.polkadot.network/>

X: <https://x.com/Polkadot>

bafybeig6ocmljuek3u2cyixq4ixfbgql5pmn3i75zdz3fooqeh6zpcw4qy

Scalability² - the stepping stone to a Web3 Cloud

bafybeia3rwbzvrj4sx6fulc533c6lb4cdnlpruxflkuxkhhh5tfbl44t6e

eskimor

bafybeibfnco7zlaj7nj2eydp3odkb3tpujnj5ttqqgpjfpr2nzxg2v7ldm

sandreim

The number of validators participating in parachain consensus will be bumped from 300 to 500 on Kusama!  This means the total core count can also be increased to 100, security is improved and backing vote rewards are more fairly distributed.

See full forum post

Need more than one core ? No problem, the first version of Elastic Scaling was just launched  🚀🚀🚀 . To try it out or learn more check out this forum post

Proposing the Plaza: A Batteries-Included, Scalable Polkadot System Chain

It’s no secret that Polkadot is the most scalable technology for building and hosting any kind of Web3 application. In the past year I’ve been working with an awesome team at Parity to implement and deploy Elastic Scaling, a game changer for rollup scalability and the Web3 cloud.

In this article...

Coretime is specified in RFC-1, but only briefly explains an example pricing model and specifically states that the described model should only illustrate that a solution exists, but should not be treated as a concrete proposal.

This blog posts explains a concrete proposal we want to launch on...

I already explained among other details how renewals work in this post. Here I want to go into more details on how your renewal price will be determined.

The first concept to realize is that your renewal price is always pre-determined, you know exactly what you are going to pay beforehand.

Ok...

Checkout Rob's blog post about how he sees the future of Polkadot here. I think this is exactly the right approach to make Polkadot shine and show to the world what it is capable of.

Keep it simple as long as it works.

Provide the means to extend even further once necessary.

The future: A...