---
# System prepended metadata

title: Untitled

---

## State of the Ecosystem

I have to say I am impressed how quickly the ecosystem on Polkadot is maturing.

It has not been too long ago, when I tried doing basic things on Parachains, I just failed - nothing really worked. Just a few months later, things don't only work, but are actually a pleasant and more importantly an *exciting* user experience!

I am truly proud! With easy to use DEXes, it became astonishingly easy to get ahold of tokens for any Parachain and just use it right away. Not really harder and definitely more satisfying than setting up Web 2 user accounts for a service: You just get some token and you are good to go. I love it!

With that out of the way, what are we at Parity up to on the node side?

## Agile Coretime, Mythical Games

Right now the Parachains and Node SDK team are busy building Elastic Scaling, and pushing Asynchronous Backing and Agile Coretime into production to name a few highlights. We are expecting a high volume launch of Mythical Games in the first half of 2024\. Showcasing with applications that Polkadot can scale! It is cool if the tech can, but if you can show it with real applications, that's a totally different thing. Talk is cheap, show me! That's why we are really exited to do our best to make this a huge success!

For those non familiar on the above: Asynchronous Backing will enable Parachains to use up to two seconds of execution in each block and will half their block time from 12s to 6s, giving Parachains lower latency and eight times the throughput (700% increase)!

Agile Coretime will allow more efficient allocation of blockspace/coretime for Parachains, improving allocation efficiency and lowering the barrier to entry for teams.

And finally, Elastic Scaling allows fast collators to use multiple cores on Polkadot simultaneously, with the effect that their blocks will be validated in parallel, allowing even higher throughput and even lower block times: Fast and optimized collators should be able to produce 3 blocks, each with 2s worth of execution, every 6s relay chain block. Therefore the effective block time for that Parachain would be just 2s, with another 3x increased throughput (total together with asynchronous backing of 2300%)!

Concrete Status: Asynchronous Backing can be enabled on Kusama with the upcoming 1.2 Fellowship runtime release, same for Agile Coretime. If all goes well we should be able to enable Asynchronous Backing on Polkadot shortly after.

Agile Coretime and a first version of Elastic Scaling are expected to be ready for Polkadot by end of June.

## On-demand Coretime

An easily overlooked feature of Agile Coretime is On-demand Coretime. A feature that seems quite important though, for developer experience and low barrier to entry. What on-demand coretime allows for, is low-latency + low-throughput Parachains!

Put differently, what on-demand allows, is for early stage teams to offer their users a superb user experience (low-latency), despite them barely having users yet, giving those users a good experience, attracting more users, until eventually utilization will be high enough, that buying bulk Coretime becomes sensible.

Let me explain this a bit more: I, as a user, want to try out a new cool Parachain, but it just launched and also it is in the middle of the night, so literally nobody is using that Parachain right now. Yet, traditionally what that Parachain would need to do to ensure good user experience, is build a block or at least buy the possibility of authoring, for every relay chain block, despite the fact that most of that Coretime is not needed and any produced blocks would be empty. With On-demand, what the Parachain can do is the following:

1. User is sending some tokens to the chain to use it - the chain will notice this and order a core, build a block and the user is ready to go: Latency should be smaller than 12s.
2. User uses the chain, does a few things, sends funds back to origin chain: The chain orders a core, builds a block, user is served.
3. Parachain is idling again (and not producing any blocks).

It is also possible to imagine hybrid models: Early stage chain orders bulk, but only wants to afford one block per minute. Now they can offer their users two options:

1. Fast processing (several seconds), with higher fees.
2. Or: I have time, 1 minute is fine: Lower fees.

## Get faster and scale more!

Thanks to Aaro Altonen with have a new networking library litep2p and he also ported our [networking stack to use it](https://github.com/paritytech/polkadot-sdk/pull/2944), enhancing our networking performance significantly!

Why is this important? One of the most important critique points on blockchains always has been: "They don't scale!" And for many, even popular projects, this is just true. Polkadot can scale by design, but we also need to prove it! People want to build on a platform that does not only fulfill their needs today, but they also want to be confident that it will do so tomorrow. Hence, I believe it is important to show improvements on a regular basis, to give confidence in the project. Also it is just cool to make things work at scale ;-)

I hope for these networking improvements to get enabled on Rococo best yesterday, if that does not work, then tomorrow and I would love to seem them on Parity's validators with the next node release.

We also have other improvements ([#1191](https://github.com/paritytech/polkadot-sdk/pull/1191) and [#1178](https://github.com/paritytech/polkadot-sdk/pull/1178)) which are ready and are just waiting to be rolled out and we have more in the pipeline: [Systemic chunk recovery](https://github.com/paritytech/polkadot-sdk/pull/1644), improving performance on data availability.

## Outlook

For the second half of 2024, I want us to go even further in terms of

1. Developer Experience
2. Scaling

For (1) a major component I want to see is making On-demand Coretime [easy to use](https://github.com/paritytech/polkadot-sdk/issues/1487). We must have ready to use integration into node side + pallets, so you can just plug it in and use On-demand Coretime, to offer the best possible user experience.

Another crucial aspect with regards to developer experience: We will also make interfaces for builders more stable, so upgrading a Parachain node should finally become easy!

For (2) it is always hard to predict how much an improvement brings, but I see huge potential in optimizing our approval subsystems. I don't find it to unrealistic that with optimizations like [this one](https://github.com/paritytech/polkadot-sdk/issues/1617) and also additional work on networking, on top of the improvements already mentioned above, to get to 1000 validators and at least 100 Parachains at superb security properties.

Speaking of security, obviously security is a main focus all the time anyways and we do plan further improvements with regards to DoS resilience for the second half of 2024 as well.

## Further Outlook

With our ecosystem maturing further and the number of messages exchanged, increasing, off-chain XCMP will become more and more important. Therefore I expect this project to gain traction in 2025.

## Thank you!

Thanks again to everybody building on Polkadot! Without you, all our work would be pointless! I am really glad to see, that it is not, in fact you are making incredible use of it! Thanks for being with us on this exciting journey!

# About the Author

I am eskimor, lead developer at Parity technologies. I am leading the Node SDK, the Parachains and the Zombienet team, building the best possible tech with those amazing teams.

Views expressed in this post are my own and don't necessarily reflect the ones of Parity Technologies.