Background 23.jpg

[Polkadot JS](https://wiki.polkadot.network/general/polkadotjs-ui/) is a cornerstone for developers building in the Polkadot ecosystem, powering everything from wallets and dashboards to custom UIs and dapps. The suite includes critical client-side components such as the Developer Interface (Polkadot JS Apps), API, Developer Signer (Extension), and several other dependencies and libraries.

As the ecosystem matures and more specialized teams step up to drive its growth, Parity Technologies is proud to announce that BlockDeep Labs will be taking over the support and maintenance of the entire Polkadot JS suite. This year, Parity teams and BlockDeep Labs have collaborated closely on the progressive and successful handover of Polkadot JS-related activities, including its rebranding and ongoing maintenance. 

#### About BlockDeep Labs

[BlockDeep Labs](https://www.blockdeep.io/) is a Berlin-based blockchain engineering firm, set up by former Parity staff. It specializes in building secure, scalable, and production-grade decentralized systems based on Polkadot technology and has a strong track record of ecosystem contributions, including deep involvement in Substrate-based development and building the Mythos parachain. Its hands-on experience with developer tooling and commitment to open source make it an ideal steward for the continued evolution of Polkadot JS.

While Parity Technologies will continue to focus on core protocol development and advancing the Polkadot roadmap, we are confident that BlockDeep Labs will bring new energy, responsiveness, and innovation to the Polkadot JS stack.

#### What to Expect

-   Continued maintenance and support for the Polkadot JS suite, including regular security penetration testing.
-   New features and performance improvements tailored to evolving ecosystem needs.
-   Transparent communication and opportunities for community collaboration.

We're incredibly grateful to everyone who has contributed to Polkadot JS over the years, from code to issues, to documentation and feedback. Your support made the project what it is today. And as we pass the torch, we look forward to seeing BlockDeep Labs expand its potential even further.

Polkadot is built to enable a collaborative, decentralized future, and this is one more step in that direction.

jpeg-Hero_test_1200.jpg

We've already explored the [rollup scalability](https://www.parity.io/blog/polkadot-web3-cloud) problem and how Polkadot has delivered one of the most innovative ways to solve it. In this post, we continue by investigating the trade-offs made by Polkadot and a few other Web3 projects. Let's start with a simple question.

#### What is the Cost of Scalability?

_Polkadot has positioned itself as a leader in scalability, but does this come at a cost? Are there trade-offs that Polkadot makes to enable rollups to achieve higher throughput and lower latency?_

Scalability, resilience, and security are interwoven into the Polkadot architecture.

While high throughput and fast transaction speeds are desirable, and are key to achieving scalability, they should not be achieved at the expense of two other critical properties - resilience and security. Nor should the interoperability of the network be unduly affected.

Adding more validators increases the number of resources available for rollups, and improves both the resiliency and the economic security of the network. The issue is whether scalability affects the other Web3 fundamental properties of Polkadot.

For a wider context one should also consider understanding the properties described in [this post](https://www.forbes.com/sites/digital-assets/2025/01/31/what-makes-or-breaks-a-blockchain-gavin-woods-5-criteria/) by Gavin Wood as existential for true Web3 systems.

#### Resilience
_Does Polkadot's architecture, which relies on a network of validators and its central Relay Chain, potentially centralize certain aspects of the network? Does it introduce single points of failure or control that could compromise its decentralized nature?_

Rollups are run by sequencers that connect to the Relay Chain using the "collator" protocol. This protocol is fully permissionless and trustless. It allows anyone with internet access to connect to a small group of Relay Chain nodes and provide a rollup state transition to be verified using the resources of a single core. One requirement needs to be fulfilled - what is provided needs to be a valid state transition. If it is not, the rollup state does not advance.

#### Vertical scalability trade-offs

Rollups can scale vertically by leveraging Polkadot's multi-core architecture. This new functionality is introduced by the [Elastic Scaling](https://wiki.polkadot.network/learn/learn-elastic-scaling/) feature. During design, we discovered that rollup resilience can be affected, because the rollup block validation is not enforced on a particular core.

The protocol for submitting the blocks to the Relay Chain is trustless and permissionless, so anyone can submit blocks to be validated on any of the cores assigned to a rollup. Attackers can simply take an earlier valid block and use it to spam the validators assigned to the other cores of the rollup, wasting the resources of the rollup and reducing its throughput.

We want to maintain the resilience of the rollup and its effective use of Relay Chain resources without compromising these key properties.

#### Can sequencers be trusted?

It would be very simple to solve the problem by making the protocol permissioned - white lists, or just simply trusting the sequencers that they behave in a way that doesn't harm the rollup liveness.

But, in Polkadot, we cannot make any trust assumption about sequencers, because we want to retain the trustless and permissionless nature of the system. Anyone must be able to use the collator protocol to submit the state transitions of a rollup.

#### No compromises

The solution which was implemented pushes the problem forward to be solved entirely by the rollup state transition function. The rollup logic (aka Runtime) is the source of truth for anything that needs consensus. So it is only natural that the state transition function must commit (via its output) to the exact Polkadot core to be used for validation.

Doing so, we make no trade-off on the resilience or security of the rollup. The core assignment is guaranteed to be correct at Polkadot level by re-executing the rollup state transition as part of the availability process and through the ELVES crypto-economic security protocol.

Before any rollup block is written in the Polkadot DA, a small group of validators (typically 5) verify the validity of a rollup block after receiving its "candidate receipt" and proof of validity (PoV) from a sequencer. The PoV contains the rollup block and the corresponding storage proof that will be passed to the parachain validation function during re-execution on the Relay Chain validators.

The output of the execution is a set of commitments which include the core selector that determines the core index.

![diagram.png](https://storage.googleapis.com/parity-io-parity-prod/diagram_32c666cf1b/diagram_32c666cf1b.png)

Validators check if the core index is equal to the core they are assigned to. If it is not, the rollup block is dropped.

This ensures that the system remains fully trustless and permissionless while malicious actors (including more privileged actors like rollup sequencers) cannot control the core where the blocks are validated. Rollups retain their resilience when they use multiple cores.

For the more technical eye, there is a full technical description in [RFC103](https://github.com/polkadot-fellows/RFCs/blob/main/text/0103-introduce-core-index-commitment.md).

#### Security
_Does Polkadot's focus on rollup scalability lead to any compromises in security? Are there potential vulnerabilities that could be exploited by malicious actors?_

The security of Polkadot rollups is a concern of the Relay Chain. The rollup is just responsible for its own liveness which can be achieved with just a single honest sequencer. 

Polkadot extends its full security over rollups through the ELVES crypto-economic security protocol. It verifies all of the computations happening on all cores without making any assumptions or introducing constraints for rollups that make use of an arbitrary number of cores. 

This means Polkadot rollups scale with zero compromises on security.

#### Generality
_Does rollup scalability constrain the programmability or applications that can be built on top of them?_

Polkadot's rollup model allows Turing-complete computations to be executed in a WebAssembly environment, as long as they are completed within two seconds. Using Elastic Scaling doesn't add any restriction on the range of computations, it only increases the quantity of computations that rollups can perform over a period of six seconds. 

#### Complexity
_What about additional complexity that could make it more difficult to develop and maintain applications on the network? Could this complexity lead to unforeseen issues or bugs?_

This trade-off is largely unavoidable. Higher throughput and lower latencies don't come for free. In fact, all else considered, a higher degree of complexity is the only acceptable trade-off to be made. Rollups can seamlessly scale up and down by using the interfaces of Agile Coretime. To preserve the same level of resilience in all scenarios they also need to implement a few RFC103 requirements.

In practice additional complexity depends on the use cases, as rollups need to define their own strategy for acquiring and assigning more resources, which can depend on on-chain and/or off-chain variables and triggers.

A best-case scenario is when the rollup runs with a constant fixed scaling factor, for example three cores, or when the number of cores very rarely needs to be adjusted and it can be adjusted manually from an off-chain context.

Simpler methods also exist, such as monitoring certain transaction load in the "mempool" on the nodes.

More automation, for example using historical data to provision more resources ahead of time by using the coretime service through XCM, increases the complexity of the implementation and significantly increases the complexity of testing that needs to be done.

#### Interoperability
_While Polkadot enables interoperability between different rollups, does this reduce their scalability? Are there limitations or trade-offs that developers need to be aware of when building scalable rollups that interact with other Web3 applications?_

While Elastic Scaling can drastically reduce block time and increase throughput, it doesn't affect in any way the throughput of messaging between different rollups. Cross-rollup messaging is a feature of shared security, with its transport layer implemented in Polkadot. The amount of blockspace dedicated to sending and receiving messages remains constant for each rollup regardless of the amount of cores assigned to any of them.

One future upgrade on Polkadot, off-chain messaging, aims to improve this by using the Relay Chain as a control plane rather than a data plane for messaging. Once this is implemented, the vertical scalability enabled by Elastic Scaling will drive an increase in the maximum messaging throughput that can be achieved between two rollups.

#### What trade-offs do other protocols make?

It is widely known that it is possible to trade decentralization and security for a boost in all performance metrics. But, judging by Nakamoto coefficients, it is surprising to see that Polkadot's competitors achieve inferior performance even with a much lower degree of decentralization.

**Solana** does not use sharding in the way Polkadot and other blockchains do, and Ethereum plans to. Instead, it achieves its scalability through a single-layer, high-throughput design that relies on mechanisms like Proof of History (PoH), CPU-level parallelism, and a leader-based consensus model. Solana's theoretical maximum TPS number  is claimed to be 65K.

What is very interesting about this approach is the leader schedule which is done ahead of time and is publicly verifiable:

-   At the start of each epoch (~2 days, or 432,000 slots), the network generates a schedule assigning slots to validators based on their staked tokens.
-   Validators with more stake get more slots, proportional to their share of the total active stake (e.g., a validator with 1% of stake gets ~1% of slots).

Knowing all the block producers in advance enables focused planned DOS attacks against Solana, exposing the network to the risk of frequent outages.

PoH and parallel processing place very high hardware demands on the validators, which has led to centralization. Furthermore, the amount of staked tokens is correlated with more block authoring opportunities, leaving small validators with minimal stake to zero or just a handful of slots. This causes even more centralization and exacerbates potential outages due to DDOS.

Solana maximizes its TPS by compromising decentralization and resilience, evident in its Nakamoto coefficient of 20. In contrast, Polkadot, with a Nakamoto coefficient of 172, is significantly more decentralized.

While centralization inherently introduces security risks, there are even worse trade-offs that can be made by sacrificing security up front.

For example, let's look at **TON.**

[The claim](https://live.ton.org/) is 104,715 TPS. It was achieved using 256 validators in a private test net with high quality hardware and perfect networking. By comparison Polkadot achieved 128K TPS on a public and decentralized network.

What is interesting is that the consensus protocol is not secure by design. It simply allows whole classes of attacks by revealing the identity of shard (subnet) validators ahead of time. This design choice is documented in the TON [whitepaper](https://ton.org/whitepaper.pdf):

![Screenshot 2025-04-25 at 12.42.56.png](https://storage.googleapis.com/parity-io-parity-prod/Screenshot_2025_04_25_at_12_42_56_6198615ab7/Screenshot_2025_04_25_at_12_42_56_6198615ab7.png)

TON trades off security to achieve its high TPS numbers. Knowing validators of one shard in advance enables DA bandwidth optimizations, but this can be exploited. Without any [gambler's ruin](https://en.wikipedia.org/wiki/Gambler%27s_ruin)  property, malicious actors can wait long enough until a "task group" is entirely controlled by an attacker. Even if they are not controlling the entire "task group", it is still possible to just DOS the honest validators, allowing the rest to approve an invalid shard state transition.

By comparison, in Polkadot, each rollup block is validated by randomly assigned validators which are only revealed at the very last moment, when re-execution is started. This minimizes the chances of honest validators being censored.  The protocol will escalate if a validator is censored by randomly selecting new validators to re-execute.

It is important to note that attackers can only know if they control all the validators assigned to a rollup block only after starting the attack. Just a single honest validator can raise a dispute, leading to the attacker losing a significant stake.

**Avalanche** scales through a multi-network architecture, splitting its ecosystem into the primary network and customizable subnets. The primary network is composed of three interoperable chains secured by one validator subset.

-   X-Chain: DAG-based, used for asset transfers (~4,500 TPS)
-   C-Chain: EVM-compatible, for smart contracts (~100-200 TPS, Ethereum-like)
-   P-Chain: Manages validators and subnets

Theoretically, each subnet can achieve up to 5,000 TPS. Avalanche unlocks higher scalability by reducing the total amount of work performed by the system for a single shard. This is a good idea, and similar to Polkadot. The system cannot scale if all validators check everything.

However, a closer look at the Avalanche design tells us that it actually permits and motivates validators to only focus on the subnets they want to be a part of. On top of that, subnets can introduce additional requirements for validators which can include being located in a given country or a mandatory KYC check. This is a compromise on security and decentralization

In Polkadot all rollups benefit from the same level of security, In Avalanche there is not even a default minimum level of security or decentralization. Some subnets can be very centralized and permissioned, allowing them to theoretically hit ~5.000 TPS. Others can trade-off higher TPS for decentralization and resilience, but still there is no guarantee.

**Ethereum's** approach on scalability was a huge bet on scalability at the rollup level, rather than handling it directly. It is obvious that this doesn't actually solve the problem, but only passes it one level higher up the stack. 

#### Optimistic rollups

Many of these rollups are implemented as optimistic which are currently seen as either centralized (even to the extreme of running just a single sequencer), insecure, isolated or a combination of these. These rollups introduce high latency because they need to take an overly pessimistic view of the world and they need to delay enactment for days to give enough time for any unreported fraud proofs to be submitted.

#### ZK rollups

This implementation choice of rollups is largely constrained by the volume of data that can be handled in a single transaction. The computational demands of generating proofs, which are fundamental to security and integrity, is extremely high, and together with the "winner takes all" nature of proof generation increases the tendency of centralization of these systems. Also, to maintain a reasonable level of transaction throughput, ZK rollups often have to compromise and restrict the number of transactions included in each batch.  

This constraint can lead to network congestion and heightened competition for blockspace, particularly during periods of high demand. This can result in a surge in gas fees, making transactions on the ZK rollup network more expensive.  By comparison, Turing-complete ZK rollups are around 2x10^6 more expensive than the cryptoeconomic security protocol powering Polkadot cores (described in the [ELVES paper](https://eprint.iacr.org/2024/961.pdf)).

The data availability problem associated with ZK rollups can exacerbate it as they still need to ensure that the full transaction data is available for anyone to verify. This often involves the need to integrate data availability solutions, which incur additional costs and contribute to even higher gas fees for users.

#### Conclusion

Polkadot distinguishes itself by maintaining a strong emphasis on security and resilience while striving for efficiency. The fundamental Web3 principles are non-negotiable. In the long run, the only projects that will stand the test of time are the ones that adhere most closely to those principles.

chrissy_robot.jpg

The United States is an expensive country to get to if you don't live there already, the cost of things is high, and all the networking has to count for something when you are part of a team making the journey. There is a powerful argument that some of the new people you meet over cocktails in Colorado need to become converted leads a few weeks or months down the line to make the whole jamboree worth it, and I wouldn't oppose that.

My first impressions were clouded by jetlag and I wasn't alone. Denver is seven hours behind London time and eight behind mainland Europe. Bright-eyed and bushy-tailed many hours before breakfast meant clinging on with the assistance of caffeine by evening and truncated sleeping patterns became mandatory. Zoe from [WebZero](https://www.joinwebzero.com/), the brilliant organizer of Polkadot's quite unique Treasury-funded "Blockspace Mansion" (more on that later), posted on X afterwards: "[4 hours sleep a night for 8 days](https://x.com/ZoeCatherineF/status/1896709838836560278). Give me a week to recover and I'll want to do it again." Which rather sums up the resilience of people in Polkadot. Push us to our limits, but we tend to get up and go again.

This was my first [ETHDenver](https://www.ethdenver.com/), and I hope it won't be my last. It needs to be stated here and now that the enthusiasm from Parity and Polkadot people was contagious, despite the fact many of us were seven or eight hours away from our natural time zone. There was our own Shawn Tabrizi nailing an effervescent presentation on [the future of Web3](https://www.youtube.com/watch?v=ebdrPnk-268&t=5s) that was appropriate for all types of audience. It came either side of his two separate engagements in the Mansion. Also from Parity, Erin Grasmick and Remy Le Berre went straight into a panel on our first morning, a day before the main event started, that looked at the [blockchain skills gap](https://www.youtube.com/watch?v=ApqJwDxRJuQ). (Erin also gave a solo presentation on [scalability](https://www.youtube.com/watch?v=5yE9mkju37g)).

#### Homogenous thinking for global adoption

On the official first day, [Chrissy Hill](https://www.linkedin.com/in/chrissy-hill-aa76828/?originalSubdomain=uk), our chief legal officer and interim COO, gave a keynote address that had a thematic link to the Erin-Remy panel, when she challenged the industry's historical approach to talent acquisition. Chrissy argued: "The strongest teams combine technical expertise with cognitive diversity. In an industry building for global adoption, homogeneous thinking isn't just a missed opportunity - it's an existential risk to the future of Web3." Special mention too to Alex 'Birdo' Bird, another Parity staffer who was here, there and everywhere.

From beyond Parity but very much from the ecosystem agents squad, Tommi Enenkel (aka Alice_und_Bob) was one of those who was able to combine long hours in the Polkadot booth with important discussions on the side. Nobody could quite match the audacious coverage of Polkadot's most ubiquitous and vocal ambassador Lucy Coulden, however, who probably lost count herself of the speaking engagements she threw herself into across Denver. She featured alongside Birdo in a [punchy panel](https://www.youtube.com/watch?v=84vTGh7eRRE&t=3s) on the meaning of "community" in a post-memecoin world. By the way, if Uber posts particularly strong figures for its Denver operations this quarter, then a decent chunk of that can be put down to the miles covered across the city by everyone who attended after-hours side events, and of course regular trips to and from the Blockspace Mansion.

![Screenshot 2025-03-10 at 15.19.39.png](https://storage.googleapis.com/parity-io-parity-prod/Screenshot_2025_03_10_at_15_19_39_918d62abcb/Screenshot_2025_03_10_at_15_19_39_918d62abcb.png)
_Advertising by the freeway outside the Blockspace Mansion_

They counted 2,094 unique check-ins to the "Mansion", a detached house close to a big freeway carrying traffic downtown and within sight of the city's famous Mile High Stadium that plays host to the Broncos in the NFL. It had a porch, a back garden, and just enough space inside to make it feel cosy but never too squashed. Following a successful application to the [Polkadot events bounty](https://dotevents.xyz/), the Treasury released 27.3k DOT on January 30th to allow WebZero to hire the space: this included rent of the Mansion for 10 days, staff, a shuttle service to and from the event, and hackathon prizes.

With complimentary soft, hot and alcoholic drinks flowing throughout daylight and evening hours, and platters of food provided by a private  chef, the Mansion was all things to all crypto people: a hackerspace, a networking venue, a party zone, a place to just hang out and vibe. The wine and whiskey selection was replenished as swiftly as the piles of branded swag - and with non-Polkadot side events paying money to WebZero to use the Mansion for their own events, this mitigated the overall cost for the organizer.

#### Seduced by the Colorado way

If the Mansion was something of an unqualified success, what about the main conference spaces of ETHDenver? A relaxed vibe pervaded in tune with Denver's geographical position as a sort of gateway to the US West. Nobody was too rushed to have a conversation, and many took time to listen, pause, think, and respond. It was as though all non-Denver natives were seduced by the slower way of life in Colorado and it might have seemed quite unusual to those more used to the New York or European way of doing things. The aesthetics of this conference are quite unique: garishly bright colors on every stage, giant inflatables more in tune with children's theme parks - and space, so much indoor space for stages, stalls, eateries and so on. The venue is the National Western complex, renowned for its January rodeo series, but also notable for equestrian events and auctioning lambs, hogs, and cattle.

![Screenshot 2025-03-10 at 15.20.37.png](https://storage.googleapis.com/parity-io-parity-prod/Screenshot_2025_03_10_at_15_20_37_abe6e43260/Screenshot_2025_03_10_at_15_20_37_abe6e43260.png)
_'Birdo' with the mic in a main stage panel on the value of Web3 communities_

There were initial concerns that the Polkadot booth was not in prime position as it was quite far from the main entrance: but those concerns were swiftly negated. The booth was on the main "route" through the main hall and adjacent to the doorways for the main stage. Pretty much everyone had to pass right by the Polkadot arch on multiple occasions, and that was handy. When I say "Polkadot arch" I probably really mean the "[UNLOCK TOMORROW](https://polkadot.com/unlock)" banner, a new tagline promoted by the Distractive agency who are the primary marketers for Polkadot. The Polkadot colors and branding are now well established in the space so that nobody was in any doubt where they were - and of course the Polkadot logo itself was displayed lower in front of the "reception" desks. At times it was the busiest booth in the hall, and even at quieter times there was always a steady trickle of walk-ups.

DOT holders, and those generally familiar with the protocol, are loyal people on the whole who are aware of the high-quality tech the network provides. They were not all swept off their feet by the "[Ethereum-compatible smart contracts](https://forum.polkadot.network/t/update-on-ethereum-compatible-smart-contracts/11512), native to Polkadot, by Q3" narrative that I tried to engage some of them with. Happily, however, plenty were. And what was really interesting was that every long-term tokenholder I met was positive about the future for Polkadot, including a jovial guy in a Pittsburgh Steelers who had nothing to with ETHDenver, but bumped into Remy and me as we walked to the venue on the first morning, and saw the logo on my sweatshirt.

[Distractive](https://distractive.xyz/) sent a pretty big team to Denver to ensure the booth was well-staffed from start to finish. Their numbers were boosted by ecosystem agents, Parity staff, and project teams who had screens and desks of their own to exhibit their wares (including Moonbeam, Nova Wallet, Unique Network, PBA, TVVIN, Evrloot, Moonbeam, Acurast, StellaSwap, and BlockDeep Labs). This meant that at times, particularly during the first two days when representatives of all these orgs were lurking around the booth, the space looked really busy and encouraged bypassers to think "there must be something going on here - let's check it out".

Distractive's [Eric Holst](https://www.linkedin.com/in/web3-eric-holst/?originalSubdomain=de), whose LinkedIn page has him down as the agency's "Ecosystem Community Evangelist for Polkadot" provided a sure, calm hand on the tiller. And although there was a rota of sorts, we were encouraged to be there as much as possible to keep things ticking along smoothly. This approach worked well: at no point was any individual inundated with a flood of people to engage with, and when people queued up in numbers at times, they were processed efficiently.

![Screenshot 2025-03-10 at 15.21.28.png](https://storage.googleapis.com/parity-io-parity-prod/Screenshot_2025_03_10_at_15_21_28_69f04b940e/Screenshot_2025_03_10_at_15_21_28_69f04b940e.png)
_Inside the Blockspace Mansion, a panel featuring Shawn Tabrizi (right)_

The Polkadot Treasury paid a significant amount for top-tier sponsorship, releasing 41.7k DOT on December 27th to Distractive. For this outlay, Distractive was able to secure the booth as well as a number of prominent talks, including two on the main stage. Funded through a [separate OpenGov](https://polkadot.polkassembly.io/referenda/1392) initiative, Polkadot was also named sponsor of a very well-attended [closing party](https://www.instagram.com/p/DG_hnVsARrz/?img_index=1) at a huge nightclub.

#### A move to general tech events?

As is traditional, a number of other opinions have been expressed about what went well and what could have been improved upon, with Birdo and Shawn having [laid down their thoughts](https://forum.polkadot.network/t/eth-denver-2025-feedback/11931) while still in Denver. I don't want to extend the debate further here, apart from to say that the idea of looking at more non-Web3 tech conferences in the future for Polkadot to leverage is gathering momentum internally.

Principally, this is because Polkadot's long-term vision does seem to sit at odds with so many other projects in the space. There were, for example, a large number of new start-ups in Denver insisting they had the best AI-meets-blockchain offering, without really being able to clarify what their unique selling point was. There was a project offering "unruggable liquidity for your memecoin", whatever that is. As for the operators who have been around a bit longer, I really liked the high-school vibe of the Polygon booth (complete with dented lockers), but when I snuck into the Midnight Happy Hour I found that something was maybe missing. It included a pretty dry announcement of a [partnership with OpenZeppelin](https://coingape.com/cardanos-midnight-network-taps-openzeppelin-to-boost-defi/) - but I need to add that everyone there was friendly, thoughtful, and keen to engage.

And I think that would really be my biggest takeaway of all. In contrast to certain other meetups/conferences/events in this space I've attended over the years where little cliques emerge and invisible shutters go up between groups, in Denver it was entirely different. Further conversations will surely continue: from around 25,000 attendees, the Distractive team was able to capture contact details of more than 7,000 people.

The idea is some of those will become enterprise partners of the future while a significant number of developers we met are now pursuing careers at Parity for the first time. Ultimately, ETHDenver - for us Polkadot folk - was partially framed as an opportunity to start conversations with new contacts, and in that way at least it proved to be a qualified success. Just how big a success it was cannot accurately be determined right now - it will depend on where those conversations ultimately lead to.

v2.png

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.

#### Polkadot's 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, 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/_dXNNeqdYmw?si=9Vd0Za218QAL6v3O).

![Screenshot 2025-02-24 at 15.51.16.png](https://storage.googleapis.com/parity-io-parity-prod/Screenshot_2025_02_24_at_15_51_16_54eb7e678c/Screenshot_2025_02_24_at_15_51_16_54eb7e678c.png)

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. 

![Screenshot 2025-02-24 at 15.51.41.png](https://storage.googleapis.com/parity-io-parity-prod/Screenshot_2025_02_24_at_15_51_41_9d061e3b44/Screenshot_2025_02_24_at_15_51_41_9d061e3b44.png)

So Polkadot is the fastest for throughput, _and_ the leader in terms of data availability bandwidth by far.

![Screenshot 2025-02-24 at 15.52.07.png](https://storage.googleapis.com/parity-io-parity-prod/Screenshot_2025_02_24_at_15_52_07_d65ebea67f/Screenshot_2025_02_24_at_15_52_07_d65ebea67f.png)

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_average_gas_price)), 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.

#### 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

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 

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

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

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

#### Real Cloud Capabilities for Web3

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.

![Screenshot 2025-02-24 at 15.52.35.png](https://storage.googleapis.com/parity-io-parity-prod/Screenshot_2025_02_24_at_15_52_35_985e946e8f/Screenshot_2025_02_24_at_15_52_35_985e946e8f.png)_Execution time and max. 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.

![Screenshot 2025-02-24 at 15.52.51.png](https://storage.googleapis.com/parity-io-parity-prod/Screenshot_2025_02_24_at_15_52_51_e43105b836/Screenshot_2025_02_24_at_15_52_51_e43105b836.png)

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

![Screenshot 2025-02-24 at 15.53.00.png](https://storage.googleapis.com/parity-io-parity-prod/Screenshot_2025_02_24_at_15_53_00_a11e7cbc8c/Screenshot_2025_02_24_at_15_53_00_a11e7cbc8c.png)

#### 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:

![Screenshot 2025-02-24 at 15.53.13.png](https://storage.googleapis.com/parity-io-parity-prod/Screenshot_2025_02_24_at_15_53_13_a27ee35eaf/Screenshot_2025_02_24_at_15_53_13_a27ee35eaf.png)

#### 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](https://github.com/paritytech/polkadot-sdk)
Forum: [https://forum.polkadot.network](https://forum.polkadot.network)
Wiki: [https://wiki.polkadot.network](https://wiki.polkadot.network)
X: [https://x.com/Polkadot](https://x.com/Polkadot)

_This article has been reproduced from [this post](https://grillapp.net/29705/scalability-the-stepping-stone-to-a-web3-cloud-238580?ref=29705) published on [Grill](https://grillapp.net/c/landing), a revolutionary social platform that allows bloggers and their followers to earn together. It is an application built by the Polkadot parachain, [Subsocial](https://subsocial.network/)._

JAM.jpg

Dr Gavin Wood has stood on stages in every continent of the world many, many times over the course of his decorated journey in Web3.

But it's probably fair to say he has never been more passionate about an individual project than he is about [JAM](https://graypaper.com/), the next iteration of Polkadot in which the network's underlying tech will be redesigned as a semi-coherent multicore computer.

And this is perhaps most apparent once he has finished his excellent presentation in Emmanuel College's Queen's Lecture Hall. The question-and-answer session is particularly revealing because of the long and detailed answers that are provided.

The first, from [Xcavate's Richard Houldsworth](https://x.com/richardxcavate?lang=en), is a short one: "How easy is it to spin up a service?" The answer is largely provided through the medium of code as opposed to a verbal response with Gav flipping to a new tab on his laptop to run a demonstration.

He has (of course) a screen ready with some previously compiled code - part of his own prototype version of JAM. Having mentioned the "refine - accumulate - on_transfer" process multiple times in his talk, here we get a flavor of how it looks to a coder.

This demonstration is reminiscent of previous live coding displays by Gav, perhaps the best known of which was the time he ran a Substrate chain live on stage from a fresh-out-of-the-box MacBook [at the 2018 Web3 Summit.](https://www.youtube.com/watch?v=0IoUZdDi5Is)

#### JAM = AWS for Web3? 

The second question takes us up into the clouds, so to speak. The Web3 cloud that is. "How does the [Polkadot Virtual Machine](https://forum.polkadot.network/t/announcing-polkavm-a-new-risc-v-based-vm-for-smart-contracts-and-possibly-more/3811) [PVM, the machine of choice for JAM] compare to things like Amazon Web Service?" That's the question, and the answer takes up around five minutes of careful consideration and detail.

Gav says: "JAM could be potentially compared to Amazon cloud services. The comparison is a bit questionable because we're talking about Web2 to Web3. You wouldn't run the whole Bitcoin network and a Bitcoin authority and trust it on Amazon - you wouldn't trust it not to do something in its favor. The whole point is resilience against special interests."

![Screenshot 2025-02-13 at 09.17.27.png](https://storage.googleapis.com/parity-io-parity-prod/Screenshot_2025_02_13_at_09_17_27_19c1ff7ae4/Screenshot_2025_02_13_at_09_17_27_19c1ff7ae4.png)
_One of the slides from Dr Gavin Wood's JAM lecture_

Then he explores a different path: "There is a way of scaling JAM out, through what I would term a [JAM grid](https://permanencedao.medium.com/jam-and-the-jam-grid-the-subsequent-phases-of-the-polkadot-cloud-a79f416e5ec5) - many instances each connected to another instance. You can select any JAM instance, run your services there, and it allows your service to elastically scale through many instances of JAM. It kinds of scales indefinitely. You do need bridging, but we have good designs for lightweight bridges.

More questions, more detailed answers. Applause. A short walk to a reception with drinks and canapes, and some one-to-one-opportunities with Gav, or some good old networking. And finally, for the non-locals, a train back to London. A big shout-out to [Pala Labs](https://palalabs.org/), a relatively new ecosystem team, for its excellent organiZation of the Cambridge event, and some great updates on the current India leg of the tour.

#### A student-dominated audience

There is, within the Polkadot community, some strong feeling that enterprises should be more directly targeted at this point in time. And it is true that the many students in the Emmanuel College audience are not ready to launch their start-ups right now. But within there are a few early-stage founders too in the room, and the CEO of a crypto investment/risk intelligent company, who takes copious notes during the talk.

Inevitably, there are one or two familiar faces from the London Polkadot crowd. Houldsworth, a tireless advocate for the community, is one of them. So too is [Dr Lisa Cameron](https://en.wikipedia.org/wiki/Lisa_Cameron), a former MP from the Scottish National Party ousted in the last elections but busier than ever as she tries to build bridges between Web3 and politics.

Houldsworth and Cameron are among the preliminary speakers. You can call them warm-up acts if you like, and there is a sort of concert vibe going on given that there is a very clearly defined "main act" to follow. The whistle-stop nature of the tour as it now expands across Asia adds to the flavor.

![GjiEnIJbsAA5-_v.jpeg](https://storage.googleapis.com/parity-io-parity-prod/Gji_En_I_Jbs_AA_5_v_ecd06d2567/Gji_En_I_Jbs_AA_5_v_ecd06d2567.jpeg)
_Some of the Cambridge attendees posing with the Polkadot founder. Photo: Pala Labs_

The third pre-Gav speaker is an impressive young man called [Kisso Selvan](https://uk.linkedin.com/in/kisso), president of the [Cambridge Blockchain Association](https://cambridgeblockchain.org/), who only graduated last year but has already secured a fun-sounding job in the BD team of a Web3 start-up. Kisso's involvement in the association includes the very first Polkadot Blockchain Academy course back in the hot summer of 2022 - which already seems a lifetime ago.

Gav's speech is not purely JAM-focused. His opening remarks are centered on the purpose and ethos of Web3, and a criticism that many projects claiming to be Web3 are simply not decentralized enough by design. There's a consideration too of what might be meant by the Web3 cloud and how Polkadot - via JAM - can seize that territory.

#### JAM's focus on coherence

Plenty of concepts are relatively easy to understand for a non-developer. The notion of [coherence](https://x.com/kianenigma/status/1889350340388049169) is tabled. "As systems grow, it's harder to maintain coherence," says Gav. "If a system wants overall interactions to keep going fast we have to relax coherence, and that's where we get problems. This is what JAM aims to fix."

And the slides that are borrowed from [Shawn Tabrizi's latest talk](https://docs.google.com/presentation/d/1nPDGVwVOMpdo103jitZjKx2tD-F54h4W4c7tqdV7h44/edit) are very easy to digest. (Tabrizi, one of Parity's most important developers, is often put up as an alternative choice when Gav has to turn down the many speaking invitations he receives.)

A former Parity colleague now involved in a Cardano project tells me afterwards that, in his opinion, even engineers might have struggled with some of the content in the final segments. That said, there's no way that you could leave one of these lectures without being significantly enlightened, and perhaps that's really the whole point, isn't it?

_The JAM Tour - East & South Asia Edition has visited Cambridge, New Delhi and Mumbai. It continues in Mumbai, Hong Kong, Taiwan, Beijing, Shanghai, Hangzhou, and Shenzhen. Full details[  here](https://palalabs.org/events), and you can [follow Pala Labs on X](https://x.com/pala_labs) for more updates from the JAM Tour._

Parity_2 (1).png

In blockchain technology, scaling while keeping a good level of security remains one of the most critical challenges. Ethereum, one of the most prominent chains, has faced its fair share of scaling issues due to its popularity and the vast number of transactions it handles. To overcome those challenges, rollups have [gained popularity in recent years](https://l2beat.com/scaling/summary), offering a solution that enhanced Ethereum's capacity to optimize how transactions are processed and recorded. But what are rollups, how do they solve this problem, and, most importantly: how are they connected to Polkadot's chains?

#### Rollups, Simply Explained

The main task of a blockchain network is to verify transactions that are submitted on-chain through a consensus protocol. These include a "real" transaction, such as sending tokens from one account to another, or the transmission of data through the network. Since blockchain networks can only handle a certain number of transactions per block, they face limitations in throughput. This is where rollups come into play.

Simply put, rollups execute transactions off-chain, outside a Layer 1 (L1) mainnet such as Ethereum or Solana, in a separate environment. Rollups work by reducing the load on a blockchain's mainnet by "rolling up" multiple transactions into a single bundle. The transactions are processed off-chain, and the block data is compressed and "rolled up" into a smaller form. This compressed data is then submitted back to the L1 network, ensuring it leverages its security protocol, to guarantee the availability of the data. Finally, it is integrated into a block. This increases the network's capacity to handle more transactions.

Now what has this to do with Polkadot?

#### Building on Polkadot, Simply Explained

The case-specific chains in Polkadot have historically been called parachains. This term is still in use, though it is being phased out with the advent of Agile Coretime, in which all projects are invited to secure a quantity of high-quality blockspace to meet their needs. For ease of reference, we will continue to use it in this article. Parachains validate transactions independently and produce blocks. Each one operates according to its own business logic, determining the functionalities provided to end users or other chains. While parachains handle the execution and validation of transactions, the final consensus is provided by Polkadot's Relay Chain (L0). After parachain blocks are validated and backed by the Relay Chain validators, they are included in the Relay Chain and made available for other parachains to utilize.

#### Comparisons with Optimistic & ZK Rollups

First things first, let's break down how optimistic and ZK rollups actually work. After that, I'll dive into parachains and compare their block execution to that of the other rollups.

##### Optimistic Rollups 

Optimistic rollups, as the name suggests, operate on an optimistic assumption: that all transactions are valid by default. Some might call this approach naive - or maybe that's just my trust issues speaking?

Instead of verifying each transaction in real-time, optimistic rollups approve all transactions and send their bundled data to the L1 mainnet. Unlike ZK rollups, which verify each transaction upfront, optimistic rollups rely on fraud proofs.

If a fraudulent transaction is detected, the system reverts to the state before that transaction was processed, penalizing the bad actors involved. When submitting a transaction or a fraud proof to the mainnet, both parties must stake a bond. If a dispute arises, the transaction is re-executed on the main chain to resolve it. To ensure accurate dispute resolution, rollups must implement a system capable of replaying the transaction. If either the transaction or fraud proof is shown to be fraudulent, the bad actors face slashing (forfeiture of the bond), which punishes them and deters future malpractice.

Entering a dispute is rare due to the high costs involved. And since there needs to be sufficient time to allow for potential disputes, finality for these transactions typically occurs 7-14 days after they are submitted.

##### ZK Rollups

ZK rollups are stricter when it comes to trust. In this system, transactions are first validated and only after they pass this validation are they bundled together and assigned a cryptographic proof, known as a zero-knowledge (ZK) proof. This proof is then submitted to the L1, where it is verified by a smart contract. This approach ensures only valid transactions make it on-chain, keeping the process efficient and secure. If any invalid batches manage to slip through, they can be slashed immediately, preserving the integrity of the network. However, ZK rollups are more expensive and complex to implement than optimistic rollups due to their advanced cryptography, specialized hardware requirements, and potential centralization risks. They also face interoperability challenges across different L1 protocols, [complicating broader adoption](https://medium.com/coinmonks/what-are-zk-rollups-and-why-does-web3-need-them-57a601d0ca40#:~:text=The%20Challenges%20Ahead).

##### Parachains a.k.a "cynical rollups"

Parachains are essentially Polkadot's own "version" of rollups. And, similar to ZK Rollups, they validate their transactions before submitting them to the L0 mainnet. However, there are multiple steps put in place to ensure the blocks are valid. Parachains are a "cynical" type of rollup because they assume participants may not always act honestly, requiring multiple layers of verification and checks to enforce the rules.

Parachains operate with their own set of nodes, called collators, who collect transactions from users, execute them, and propose new blocks. **Collators** are responsible for gathering and processing transactions within the parachain and then proposing these blocks to the parachain's backers. Now, you might be thinking, "Jeeeesus, another whole new terminology!🙄" I know, I know---blockchain ecosystems are full of it. But bear with me; it will make sense in the end.

![Screenshot 2025-01-24 at 11.19.31.png](https://storage.googleapis.com/parity-io-parity-prod/Screenshot_2025_01_24_at_11_19_31_fc81ba3e74/Screenshot_2025_01_24_at_11_19_31_fc81ba3e74.png)

**Backers** are a subset (currently five) of validators from the Polkadot Relay Chain (L0) who are temporarily assigned to a specific parachain to validate the blocks produced by collators. This rotation is typically managed by the L0 to ensure fairness and security, preventing any single group of validators from consistently controlling the validation process for a particular parachain. Backers verify the validity of the block proposed by the collators, ensuring it follows the parachain's rules and does not conflict with any other part of the system. A backer validates the block by attesting to its validity. These attestations are then put into a Relay Chain block, which together with the availability system ensures those backers are accountable. They now have skin in the game.

![Screenshot 2025-01-24 at 11.20.59.png](https://storage.googleapis.com/parity-io-parity-prod/Screenshot_2025_01_24_at_11_20_59_8dce8b13fc/Screenshot_2025_01_24_at_11_20_59_8dce8b13fc.png)

Now that the attestations are on-chain, the next critical step involves preventing malicious or faulty blocks from being finalized. For that, Polkadot has an additional layer of validation, called the approval checkers.

**Approval checkers** must revalidate the blocks to maintain the network’s integrity. However, for this process, they need access to the blocks themselves. What if the backers simply don’t provide the data? This is where **data availability** and **erasure coding** come into play.

**Erasure coding** minimizes the traffic and reduces the amount of data each validator must handle by breaking the block data into fragments. These fragments are distributed across validators, ensuring that even if some data providers fail, the full block can still be reconstructed. This system not only guarantees availability but also optimizes the network’s efficiency by reducing bandwidth requirements.

![Screenshot 2025-01-24 at 11.22.15.png](https://storage.googleapis.com/parity-io-parity-prod/Screenshot_2025_01_24_at_11_22_15_b8e3a3a705/Screenshot_2025_01_24_at_11_22_15_b8e3a3a705.png)

If all goes well, the Relay Chain and, by extension the attested parachain blocks, get finalized via the [GRANDPA finality mechanism.](link) Approval checkers will raise a dispute if they believe the block is invalid, causing all the Relay Chain validators to conduct checks. Backing validators will be slashed (lose all their stake) if that proves to be true. This coordinated process ensures Polkadot achieves secure and reliable finality.

It sounds like a lot of work to be done in a short time, yet the whole process takes around 18 seconds in total to achieve finality, compared to other rollups where it takes up to 14 days for a block to gain finality and security from an L1 chain.

![Screenshot 2025-01-24 at 11.22.38.png](https://storage.googleapis.com/parity-io-parity-prod/Screenshot_2025_01_24_at_11_22_38_4925aca1c9/Screenshot_2025_01_24_at_11_22_38_4925aca1c9.png)

#### XCM: Interoperability by default

On top of secure finality, Polkadot comes with interoperability by default. Developers building on Polkadot can communicate effortlessly through [XCM](https://polkadot.com/blog/xcm-the-cross-consensus-message-format), enabling applications to leverage a wide array of multichain services across the ecosystem. This encourages true decentralization and a vibrant range of use cases. Developers have the tools to create versatile and interconnected dapps on top of the parachain layer, tapping into the diverse capabilities the Polkadot ecosystem has to offer. Due to the shared security offered by the L0, cross-chain communication is super fast (around 12s with plans to make it much faster than this) and secure. That's pretty good when you consider the seven days required for secure and decentralized communication between optimistic rollups.

#### Summary: Parachains are a Kind of Rollup

In simple terms, Polkadot effectively has native rollup functionality included at the protocol level. It has rigorous processes in place to ensure accuracy and also comes with rapid finality and data availability built-in, culminating in a powerful alternative to rollups.

If you would like to learn more about Polkadot's rollup architecture, or compare it to other rollups, check out this [comparison table](https://wiki.polkadot.network/docs/learn-comparisons#rollup-comparison-table). And if you're interested in diving deep into the mathematical foundations of the protocol, I highly recommend checking out the paper "[Efficient Execution Auditing for Blockchains under Byzantine Assumptions](https://eprint.iacr.org/2024/961)" published in 2024 and authored by some (former) W3F and Parity members. Or, if you prefer to keep things simple, you can watch [the Protocol Berg presentation by Parity's ](https://www.youtube.com/watch?v=O9QZveTdW5I)eskimor.

Thinking of building your own Rollup? Dive in and make it happen: [https://polkadot.com/developers](https://polkadot.com/developers)

hero2.png

### Addressing Existing Challenges

[XCM](https://wiki.polkadot.network/docs/learn-xcm) empowers Polkadot L2 rollup chains - once exclusively termed "parachains" - to interact seamlessly. It enables asset transfers, governance actions, smart contract calls, in fact all types of on-chain function calls across chains. In a blockchain landscape that treasures interoperability, XCM is the medium that makes the Polkadot ecosystem a cohesive whole in itself, and connects it to other ecosystems like Ethereum over fully trustless bridges.

But XCM has not behaved perfectly up to now. Indeed, as a developer or user, you've likely encountered some of its challenges.

Estimating fees for cross-chain actions has been a pain point. A single XCM transaction can involve multiple components, including execution costs on both local and remote chains, plus transport fees across each hop. This complexity makes it difficult to calculate the total cost upfront, impacting the user experience.

Developers have faced hurdles when creating multi-asset or multi-hop transfers. Some tools, while functional, impose constraints and require significant technical expertise to execute more advanced scenarios. These challenges highlighted the need for standardization, improved tooling, and a more user-friendly approach.

Fortunately, XCM is improving all the time. Recent updates are providing real benefits for both developers striving to build on Polkadot and users trying to navigate multi-chain interactions.

### Positive Developments

#### Fee Transparency & Execution Flexibility

Polkadot has introduced [the DryRun and XcmPayment runtime APIs](https://hackmd.io/@n9QBuDYOQXG-nWCBrwx8YQ/rkRNb5m71e) to address the issues around XCM fee calculation, a major challenge up to now. These tools allow you to simulate transactions and estimate the total fees - including local execution, transport costs, and remote chain execution - before initiating a transfer. This feature ensures you're never caught off-guard by unexpected costs.

System chains now support arbitrary XCM execution via pallet_xcm::execute(). This means you can build custom XCM programs off-chain and deploy them directly, unlocking new possibilities for tailored cross-chain interactions.

With these recent developments, XCM is already becoming more accessible, reliable, and versatile, but there's more.

#### Improved Multi-Asset & Multi-Hop Transfers

A new [InitiateTransfer XCM instruction](https://github.com/paritytech/polkadot-sdk/blob/5b1b34db0c03057c7962eb9682b4d581c324ae26/polkadot/xcm/src/v5/mod.rs#L1059C2-L1111C4) dramatically improves complex cross-chain asset transfers by enabling multi-asset transfers with different transfer types (teleport, local-reserve, destination-reserve) in a single transaction. It simplifies cross-chain operations, allowing developers to execute multiple asset transfers within one unified program, eliminating the need for multiple independent messages.

This reduces complexity and enhances UX for multi-hop transfers, such as bridging assets across chains. The instruction streamlines fee payment by integrating remote fee logic and also allows the preservation of the origin across multiple chains, enabling more complex programs, while boosting efficiency and reliability. 

Developers building wallets and apps, including those extending beyond the Polkadot ecosystem, gain powerful new capabilities for building complex cross-chain asset transfer solutions, using trustless bridges where necessary.

#### Seamless Fee Payments

The required functionality for seamless fee payments is ready and will be part of the upcoming [Polkadot runtimes v1.4.0 release](https://github.com/polkadot-fellows/runtimes/releases). Once it is deployed on-chain, it will enable fee payments using any asset on Polkadot Asset Hub. By leveraging autoswap mechanisms, you'll be able to cover both execution and transport fees using your preferred token - like USDT or parachain-native assets - as long as conversion pools exist. This will drastically improve flexibility and user experience.

The same can be done by any chain deploying pallet-asset-conversion, ultimately allowing its users great flexibility and great UX for all local or cross-chain actions.

<iframe width="560" height="315" src="https://www.youtube-nocookie.com/embed/qQahedN-nWQ" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" referrerpolicy="strict-origin-when-cross-origin" allowfullscreen></iframe>

_Parity's Cisco Aguirre giving a high-level talk on XCM at Polkadot Decoded, July 2024_

### Future Plans for XCM

[Parity's roadmap for Polkadot XCM](https://github.com/orgs/paritytech/projects/145/views/8) is focused on improving UX and capabilities even further. Here's what's on the horizon:

#### Empowering Cross-Chain Origins & Debugging

Future updates aim to standardize how accounts are derived across chains, ensuring consistent user experiences. Unified location-to-account mapping will make it easier for you to interact seamlessly across chains. Additionally, support for permissionless Origin Aliases will allow local accounts to be linked with external identities, enabling you to maintain consistent permissions and origins across chains.

Polkadot is making XCM easier to monitor and debug. Improvements like message tracking via global topics and detailed error events will help you trace transactions across chains more effectively. Additionally, tools like runtime APIs for replaying XCM messages with full logs will give you deeper insight into execution flows.

#### Ecosystem-Wide Regression Testing

To ensure compatibility and reliability across multiple chains, Polkadot plans to introduce an [ecosystem-wide regression tests suite](https://github.com/open-web3-stack/polkadot-ecosystem-tests). This will cover business-critical XCM programs from the entire ecosystem, ensuring that new runtime upgrades don't break existing functionality. This will allow chains, smart contracts, dapps, and others to contribute regression tests for their business-critical use cases and thus make sure they are compatible with all future ecosystem enhancements and deployments.

#### XCM Cookbook Expansion

The [XCM Cookbook](https://paritytech.github.io/xcm-docs/) will be updated with more practical guides, such as how to:

-   Configure foreign asset transfers.
-   Set up Asset Hub as a reserve for DOT and other tokens.
-   Use autoswaps for paying fees in non-native currencies.
-   Configure trustless bridging to other ecosystems.
-   General transactions (arbitrary calls) between any two smart contracts across different chains or even different ecosystems (over trustless bridges).

These recipes will provide actionable steps for developers to implement advanced XCM use cases.

#### Off-Chain Tooling and Libraries

Polkadot is shifting toward leaner on-chain implementations complemented by robust off-chain tools. By creating richer libraries for TS/JS and Rust, developers will have access to libraries and tools for automatic XCM program builds, such as asset transfers, swaps, and governance actions. These tools will accelerate development and reduce the barrier to entry for new contributors.

### Try Polkadot's Better XCM for Yourself!

Polkadot's vision for XCM is one of continuous improvement, allowing cross-chain interactions to become as easy and intuitive as possible. It all means interoperability is at the fingertips of everyone building in the ecosystem.

So now it's over to you. It's time for you to explore what these changes mean and how they can help you unlock the full potential of Polkadot. So take the next step - whether it's experimenting with the latest XCM tools, [reviewing XCM proposals](https://github.com/polkadot-fellows/RFCs/pulls?q=is%3Apr+XCM) and developments, or [simply staying informed](https://forum.polkadot.network/t/xcm-user-and-developer-experience-improvements/4511/24). The future of cross-chain communication is here, and Polkadot is leading the way.

Polkadot_hero_1_v2.png

Since a [blog post](https://www.rob.tech/blog/plaza/) by Polkadot co-founder Rob Habermeier, the idea of a "Polkadot Plaza" has gained traction in the Polkadot community.  This idea revolves around several protocol changes that make Polkadot more accessible and easier to use. After several months of discussions following this post, I present in this article a set of concrete deliverables that, although independent projects on their own, all contribute to the motivation behind this idea.

Polkadot offers a sharded, decentralized system that can support large-scale projects that need dedicated throughput. However, getting started on the technology is difficult for startups and tinkerers. Parachains -- practically speaking, rollups -- are an end-stage product for businesses that know they need the scale and also have the resources to commit to development and maintenance.

At an early stage, most projects value a fast time-to-market over scale. Even for later stage projects, many are still experimenting with blockchain tech stacks. With parachain development costs, Polkadot did not offer a compelling entry point. Further, with the prior parachain auction model, founders did not have the confidence that they could even launch their product due to the limited number of parachain cores available and highly variable auction outcomes. This combination has turned away many projects from Polkadot and led to the network having less activity than some of its competitors.

For developers who want to integrate Polkadot into their systems or build user-facing applications, Polkadot has also proved a challenge. Much like monitoring all Ethereum activity requires integrations with the Ethereum chain and all of its rollups, a Polkadot integration requires monitoring multiple parachains, the custom events and assets within each one, as well as the cross-chain messages that pass between them. Although a good user experience and chain abstraction are possible on Polkadot today, possible does not mean easy. Most applications have been unwilling or unable to commit the necessary resources to it. In addition, many users complain, understandably, of high deposits and base costs for access to features like proxy accounts and multisigs.

But it's not all bad news. While other L1 and L2 protocols have prioritized speed and cost by taking centralized and/or long-finality-time approaches, Polkadot developers have focused on resilience, safety, and decentralization (while still having competitive speed and cost with current L2s). And although the market seemingly values the former over the latter (to the detriment of their users in my opinion), now Polkadot can address core speed, cost, and the development time-to-market for applications on top of its secure and scalable foundation.

The parachains core team at Parity has already made dramatic improvements to the parachain product. Auctions are no more; projects can now access [Agile Coretime](https://www.parity.io/blog/agilecoretime-explained) with flexible time-to-market and predictable costs. [Async Backing](https://wiki.polkadot.network/docs/learn-async-backing) and [Elastic Scaling](https://polkadot.com/blog/elastic-scaling-streamling-growth-on-polkadot) bring notable performance improvements like faster block times and contemporaneous core access. Other improvements like sub-second block times are in a beta phase, which would make even a single parachain rival top L1 performance.

Background 28.jpg

One of the problems with the internet is that so much of it is simply a wasteland of out-of-date information. "Content" is not cleaned up in the way that it should be. Looking for the gems in the dirt is difficult if any old trash is just allowed to pile up on top, obscuring the stuff you need to get to.

Search engines are supposed to be engineered in such a way that they'll find the stuff you need, and disregard the old stuff that is no longer relevant. But they are far from perfect - and I'd rather not begin on the limitations of AI in this pursuit.

This is not just some absent-minded ideology. The reason for this blog's existence actually came during a recent message exchange I had with [Shawn Tabrizi](https://www.shawntabrizi.com/), one of Parity - and by extension Polkadot's - most experienced engineers. He's also a member of the [Polkadot Fellowship.](https://github.com/polkadot-fellows)

I wanted to knit together two pieces of content that Shawn has on his [GitHub profile](https://github.com/shawntabrizi) because I thought it would make a nice blogpost. Those pieces are his ["Polkadot Playbook"](https://github.com/shawntabrizi/awesome-polkadot/blob/master/playbook.md) - a guide to what Polkadot is and why it is the best place to build Web3 applications - and the ["Awesome Polkadot"](https://github.com/shawntabrizi/awesome-polkadot) page - where Shawn essentially lists his favorite Polkadot resources, things like wallets, educational guides, tooling, discussion forums, and so on.

![Screenshot 2024-10-14 at 20.43.44.png](https://storage.googleapis.com/parity-io-parity-prod/Screenshot_2024_10_14_at_20_43_44_5204a401cb/Screenshot_2024_10_14_at_20_43_44_5204a401cb.png)_Shawn Tabrizi speaking at sub0 Asia, Bangkok, March 2024_

The resultant amalgamated article was - of course - to be presented very much as one person's opinion. However, when I presented a draft to Shawn, he didn't like what I'd done and felt it was not a helpful piece of content to publish on the Parity blog.

#### Little Value in a 'Snapshot'

His issue was that a snapshot of the content as it currently looks would provide diminishing value for readers over time, and in a year or two would just contribute to the morass of useless content on the net that I alluded to in my introduction.

I gradually saw where he was coming from. The whole point is that Shawn works diligently to keep his resources constantly updated and relevant - and this wouldn't be the case with any blogpost showcasing it at a single moment in time.

In truth, a lot of what he said resonated with me, after some reflection. For instance, when the new [Parity website](https://www.parity.io/) was built earlier this year, it was felt by certain people it would be helpful to retain almost ALL of the old articles in the blog archive.

I saw little value in this, and ultimately we only retained a small selection of what was in some cases an overworked back story of half-baked partnerships and minor technical upgrades. While it is important the internet retains some freely available historical content to provide background information for researchers, the truth is the vast majority is simply not required.

The [Distractive](https://distractive.xyz/) agency, which has taken over Polkadot marketing in incremental stages from Parity since the start of the year, equally decided that many of the pages on the old Polkadot website were not valuable when it came to creating the new one.

I contacted [Alberto Viera](https://www.linkedin.com/in/alberto-viera/), a developer relations specialist within the Polkadot and specifically [Moonbeam](https://moonbeam.network/) ecosystems for some years. He now heads up [PaperMoon](https://papermoon.io/), which believes "complex builds can be achieved with the right instructions." Alberto's task, with his team and other contributors, is to produce those instructions for Polkadot.

#### 'Bad Documentation A Significant Barrier'

He says: "[Polkadot](https://polkadot.com/) is a complex project that enables people to build beyond smart contract-based applications. For some time, external developers have perceived it as a challenging ecosystem and tech stack to work with. One of our primary goals is to improve our storytelling by introducing a new Developer Documentation hub designed to guide developers through their journey of building on Polkadot.

"Access to up-to-date documentation is crucial when attracting developers to Polkadot. During my onboarding into Web3, outdated or non-functioning documentation was a significant barrier when trying new tools, libraries, or ecosystems---a sentiment shared by many developers.

![DFS_6774.JPG](https://storage.googleapis.com/parity-io-parity-prod/DFS_6774_56d1f6eee6/DFS_6774_56d1f6eee6.jpg)_Alberto Viera (centre), speaking at Polkadot Decoded, July 2024. This panel examined the developer experience_

"Polkadot has been somewhat fragmented, with each team or project operating independently and often distanced from it. This is reflected in the way its documentation is structured. However, having a heterogeneous ecosystem does not mean that developer documentation should be fragmented. Developers building smart contracts on parachains are as much a part of the Polkadot ecosystem as teams building parachains themselves."

The [Polkadot Developer Bounties](https://github.com/substrate-developer-hub/bounties) repository has a broadly similar goal. It seeks to coordinate and incentivize community-driven development and maintenance of the ecosystem. It is powered by the [Substrate Tip Bot](https://github.com/paritytech/substrate-tip-bot), a GitHub application which can submit tip proposals to the Polkadot Treasury.

As members of the Polkadot community, we at Parity are also keen to seek out truth through our own internal networks. For example, if multiple people had their own version of Shawn's "Awesome Polkadot", we could develop an up-to-date list from the "best bits" of all this content. This would be unbiased, with the object of providing truth among the crowd.

#### An Open-Source Website for Polkadot?

Distractive's challenge in keeping all pages in the new Polkadot website up-to-date, removing old ones, adding some that detail new features, and so on, is a considerable one. How best to do that remains a debatable question: should the entire project be a beacon for open-source content in Web3, for instance? That would be the perfect decentralized approach, after all.

Some closing thoughts. If you are someone who cares about providing quality Web3 content to be shared and distributed online, consider using resources that accept contributions such as GitHub, instead of popular blogging platforms like Medium.

Consider, too, the value of describing high-level architectural decisions and protocol designs which are likely to stand the test of time, instead of specific features which may be adapted or subsumed by something else. And try to link to sources of truth. This is particularly important when you present anything based on metrics. With a link provided, readers can easily check the latest numbers.

Whatever the market vibes of Web3 are at any given moment, this is a space where competition will always be fierce. With that in mind, tinkerers, retail users, enterprises big and small, old and new, have an awful lot of options to pick from when choosing where to build.

What you don't want them to find is documentation, articles, video how-to guides and so on that are at best a waste of time, and at worst providing dangerously erroneous information. It is no stretch of the imagination to suggest that, when choosing between ecosystems, decision-makers may pick the one where all the good info is easy to find and succinctly presented.

There is no suggestion that Polkadot is a particularly bad culprit when it comes to content saturation, but there is no harm in us all doing our bit to clean it up, refine the message, and highlight the good stuff.


Kians_hero.png

_The following, adapted and abridged from my original post [here](https://blog.kianenigma.nl/posts/tech/demystifying-jam/), is a [ground-up](https://www.navalmanack.com/almanack-of-naval-ravikant/how-to-think-clearly) explanation of Polkadot 1.0, Polkadot 2.0, and the eventual evolution into JAM. It is targeted towards a technical audience, and particularly those who are not very familiar with Polkadot, but have a good high-level understanding of blockchain-based systems, and are possibly familiar with one other ecosystem at a technical level. I believe reading this article can be a helpful "prelude" before reading the JAM [Gray Paper](http://www.graypaper.com/)._

### Background Knowledge

This article makes use and assumes familiarity of the following concepts:

- A blockchain as a state-transition function
- An understanding of what is "state"

(Both explained [here](https://paritytech.github.io/polkadot-sdk/master/polkadot_sdk_docs/reference_docs/blockchain_state_machines/index.html))

- Economic Security and Proof of Stake

(Explained in [this Polkadot Blockchain Academy lecture](https://polkadot-blockchain-academy.github.io/pba-book/economics/economics-of-polkadot/page.html#staking-concept), and its [recording](https://www.youtube.com/watch?v=suyram9vaFc))

### Prelude: Polkadot 1.0

First, a recap of what I consider the top novel features of Polkadot 1.0

#### Social

- Polkadot is one massive DAO, with fully onchain, self-enacting governance and [forkless runtime upgrades](https://wiki.polkadot.network/docs/learn-runtime-upgrades#forkless-upgrades).
- DOT is considered [software, not a security](https://polkadot.network/newsroom/press-releases/web3-foundation-announces-polkadot-blockchains-native-token-dot-has-morphed-and-is-software-not-a-security/), by the Web3 Foundation.
- The majority of network development is carried out by the [Polkadot Fellowship](https://polkadot-fellows.github.io/dashboard/), not a fiscal company (e.g. [Parity](http://parity.io/)).

#### Technological

- Shared security, sharded execution.
- Use of a [WASM-based meta-protocol](https://paritytech.github.io/polkadot-sdk/master/polkadot_sdk_docs/reference_docs/wasm_meta_protocol/index.html). Storing the code of the blockchain in the state as byte-code. This enables most upgrades to be forkless, and supercharges Polkadot to be not only sharded, but heterogeneously sharded.

Let's dive further into sharded execution and what we mean by it.

### Sharded Execution: All About Cores

Polkadot is often described as an L0 (Layer 0), hosting other sovereign chains that can be considered L1. For the sake of this article, however, we adjust this definition to describe Polkadot as an L1 network hosting other L2 blockchains, much like Ethereum. Therefore, the words L2 and parachain can be used interchangeably.

The core problem with blockchain scalability can be stated as follows: there exists a set of validators, whose execution of some code can be trusted through proof-of-state crypto economics. By default, these validators are expected to re-execute the entirety of each other's work. Therefore, the system as a whole is not scalable so long as we force all validators to perform so many executions.

Increasing the number of validators in this model doesn't really increase the system's throughput, so long as the absolute re-execution principle is in place.

![1.png](https://storage.googleapis.com/parity-io-parity-prod/1_a69b0d0ebf/1_a69b0d0ebf.png)

This describes a monolithic (as opposed to sharded) blockchain. Inputs (i.e. blocks) are processed by all network validators, one by one. In such a system, if the L1 wants to host further L2s, all validators have to now re-execute the work of all L2s as well.

Obviously, this will not scale. Optimistic rollups are one way to circumvent this issue, in that re-execution (aka. fraud-proofs) only happen if someone claims a fraud to have happened.

One naive solution to sharding is to merely split the validator set into smaller subsets, and have this smaller subset re-execute L2 blocks. The disadvantage here is that sharding execution diminishes the economic security of the network. The security of the L2 is weaker than that of the L1, and reduces further and further as we carve up the validator set into more shards.

![2.png](https://storage.googleapis.com/parity-io-parity-prod/2_d493e94088/2_d493e94088.png)

Unlike optimistic rollups that cannot afford re-execution at all times, Polkadot was designed with execution sharding in mind, and therefore can have a subset of its validators re-execute L2 blocks, whilst providing sufficient crypto-economical evidence to all network participants that the veracity of the L2 block is as secure as if the entire set of validators had re-executed it. This is possible through the novel [ELVES](https://eprint.iacr.org/2024/961) mechanism.

In short, ELVES is a "cynical rollup" mechanism. Through a few rounds of validators proactively asking other validators if an L2 block is valid, we reach an extremely high probability that the L2 block is valid. Indeed, in the case of any disputes, the entire validator set is asked to participate. This is explained in detail in an [article by Rob Habermeier, Polkadot co-founder](https://polkadot.network/blog/polkadot-v1-0-sharding-and-economic-security#approval-checking-and-finality).

ELVES is why Polkadot can have two properties previously assumed to be mutually exclusive: "Sharded Execution" with "Shared Security". This is the main technological outcome of Polkadot 1.0 when it comes to scalability.

![3.png](https://storage.googleapis.com/parity-io-parity-prod/3_f409c8d5ec/3_f409c8d5ec.png)

Now, let's consider the "Core" analogy. An execution-sharded blockchain is very much like a CPU: in much the same way that a CPU can have many cores that execute instructions in parallel, Polkadot can progress L2 blocks in parallel. This is why an L2 on Polkadot is called a Parachain, and the environment in which the smaller subgroup of validators re-executes a single L2 block is called a "core*. Each core can be abstracted as "a group of validators working in coordination".

You can imagine a monolithic blockchain as one that ingests a single block at any given time slot, while Polkadot ingests one Relay Chain block, and one parachain block per core, per time slot.

### Heterogenous Architecture

So far, we only talked about scalability, and that Polkadot provides sharded execution. It is important to understand that each of Polkadot's shards is an entirely different application. This is achieved with a bytecode-stored meta-protocol, in which the definition of the blockchain is stored as bytecode in state of the blockchain itself. In Polkadot 1.0, WASM was used as the bytecode of choice, and in JAM, [PVM](https://forum.polkadot.network/t/announcing-polkavm-a-new-risc-v-based-vm-for-smart-contracts-and-possibly-more/3811)/RISC-V is being adopted.

Polkadot is a [heterogeneous, sharded blockchain](https://x.com/kianenigma/status/1790763921600606259) because each of the L2s is an entirely different application.

![4.png](https://storage.googleapis.com/parity-io-parity-prod/4_bc4d3a34e7/4_bc4d3a34e7.png)

### Polkadot 2.0

A big part of Polkadot 2.0 is about making cores more useful to the projects building in the ecosystem. In the original Polkadot model, a core could be rented for between six months and two years at a time. This is suitable for resourceful businesses, but less so for small teams. The feature that enables Polkadot cores to be used in a more flexible way is called ["Agile Coretime"](https://polkadot.network/features/blockspace/agile-coretime/). In this model, Polkadot cores can be rented for as little as one block at a time, up to a month at a time, with price cap guarantees for those who want to rent long-term.

![5.png](https://storage.googleapis.com/parity-io-parity-prod/5_9e1c1ba701/5_9e1c1ba701.png)

### Inside Core vs. On the Chain

To understand JAM, it is first useful to look into what happens in a Polkadot core when an L2 block comes in. You will recall that a core is constituted primarily from a group of validators. So, when we say data is "sent to the core", it is gossiped to this group of validators, as so:

1.  An L2 Block + a subset of that L2's state is sent to the core. This is all the data that is needed to execute the L2 block.

2.  A subset of validators, those that constitute the core, re-execute the L2 block and proceed with further consensus-related tasks.

3.  The core validators make the data needed for re-execution available to other validators (outside the core). Further validators might decide to re-execute this L2 block based on ELVES rules, and they need the data to do so.

Note that all the operation so far is outside Polkadot's main block and state transition function. Everything so far happens inside a core, and the data availability layer.

Eventually, a small commitment of the L2's latest state becomes visible on the main Polkadot Relay Chain state. This operation, much cheaper than the actual re-execution of the L2 block, (unlike everything else so far), affects the main Polkadot state, becomes visible in a Polkadot block, and is executed by all Polkadot validators.

### What operations can Polkadot now perform?

From 1, we can learn that there exists a new type of execution in Polkadot that differs from normal blockchain state transition function. This typically happens when all validators of a network execute a task, and as the outcome the main blockchain state is updated. We call this an on-chain operation. This is what happens in step 3. Yet, what happens inside a core (step 1) differs from this. We call this novel type of blockchain computation in-core execution.

Next, from point 2 we can deduce that Polkadot already provides a native data-availability (henceforth DA) layer, and L2s automatically use it to keep their execution evidence available for some period of time. But the blob that can be posted to this DA layer is fixed, and it is always the evidence needed to re-execute an L2 block. Moreover, parachains' code is never read from the DA layer.

Understanding the above is the foundation of understanding the majority of what JAM does. To recap:

- **in-core execution:** What happens inside a core. Abundance, scalable, as secure as on-chain execution through crypto-economics and ELVES.
- **on-chain execution:** What happens in all validators. Secured by default through economically secured validators. More expensive and constrained, as everyone is executing everything.
- **Data Availability:** The ability for Polkadot validators to commit to having some data available for some period of time, and providing it to other validators.

### JAM

JAM is a new protocol, heavily inspired by Polkadot, and fully compatible with it, aiming to replace the Polkadot Relay Chain and make the usage of cores radically unopinionated.

JAM builds on top of [Polkadot 2.0](https://blog.kianenigma.nl/posts/tech/demystifying-jam/#polkadot-2), in that it tries to make Polkadot cores more accessible, but in ways radically more flexible and unopinionated than Agile Coretime.

- Polkadot 2.0 makes the deployment of L2s more flexible on cores.
- JAM is all about deploying _any application_ on Polkadot cores, even those that don't resemble a blockchain/L2.

This is primarily achieved through exposing all the main three primitives discussed in the previous section to programmers, namely: on-chain, in-core, and the DA layer.

With JAM, developers can allow any work done in-core and on-chain to be fully programmable. And they can also allow arbitrary data to be read from and written into the Polkadot DA layer.

This is a foundational description of what JAM aims to be. Needless to say, a lot has been simplified here, and the protocol might still evolve.

With this foundation in mind, we can now dive further into a few details of JAM in the coming sections.

### Service and Work Items

In the context of JAM, what was once called an L2/parachain is now called a service, and what used to be called block/transaction is now called work-item or work-package. Concretely, work-items belong to a service, and work-package is a group of work-items. Both terms are deliberately chosen to be generic enough to encapsulate use-cases beyond a blockchain/L2.

A service is described by three entry points, two of which are fn refine() and fn accumulate. The former describes what the service does in-core, and the latter describes what the service does on-chain. The third entry point is on_message, which is called when a message from another service arrives.

Finally, the name of the two entry points is why the protocol is called JAM: the Join Accumulate Machine. Join is fn refine(), when all Polkadot cores do a lot of work, all in parallel, for different services. Join is when the data is distilled into a smaller subset, and is then passed onto the next stage. Accumulate is when the result of all the aforementioned are accumulated into the main JAM state. This is the on-chain execution part.

![Jam_fixed.png](https://storage.googleapis.com/parity-io-parity-prod/Jam_fixed_7195a53d5b/Jam_fixed_7195a53d5b.png)

Work-items can specify exactly what code they execute in-core, on-chain, and if/how/what they read and write to/from the distributed data lake.

### Semi Coherence

Recall from existing material around XCM, Polkadot's language of choice for parachain communication, that [all such communication is asynchronous](https://github.com/polkadot-fellows/xcm-format?tab=readme-ov-file#11-xcm-communication-model). That is, a message is sent, and its reply cannot be waited upon.

Asynchrony is the manifestation of an incoherent system, and is a major drawback of systems that are permanently sharded, such as Polkadot 1.0 and Polkadot 2.0 and the existing L2 landscape in Ethereum.

Yet, as described in the [Gray Paper](https://graypaper.com/graypaper.pdf) section 2.4, a fully coherent system that is always synchronous for all of its tenants can also only grow so much without compromising generality, accessibility or resilience.

**Synchronous ~ Coherent || Asynchronous ~ Incoherent**

This is another area where JAM stands out: through the introduction of multiple properties, JAM achieves a novel middle-ground: a semi-coherent system, one in which sub-systems that communicate often have a chance at creating a coherent environment with one another, whilst not enforcing the entire system to be coherent. Dr. Gavin Wood, the author of the Gray Paper, has given several interviews about JAM which shed further light on this aspect.

JAM unwrapped

Another helpful analogy may be to see Polkadot in the JAM era as a sharded system where the boundaries of those shards are fluid, and determined on the fly.

The properties that enable this are:

1.  Access to a stateless, parallel in-core execution where different services can only interact synchronously with other services that reside on the same core in that particular block, and on-chain execution where a service has access to the outcome of all services across all cores.

2.  Freedom over the scheduling of services. Services that talk to each other frequently can create an economic incentive for their sequencers to create WorkPackages that contain WorkItems of services that often communicate. This enables them to reside in the same core, and in practice, talk to each other as if they were in a synchronous environment.

3.  Access to the DA layer, usable as an ephemeral, yet extremely cheap data layer. Once data is placed in the DA, it is eventually propagated to all cores, but is guaranteed to be available in that same core immediately. Therefore, JAM services, through scheduling themselves into the same core in consecutive blocks, can enjoy a much higher degree of access to data.

It is important to note that while the above is possible in JAM, it is not enforced at the protocol layer. Therefore, it is expected that certain interfaces are asynchronous in theory, but can act synchronously in practice through elegant abstractions and incentives. One such example is CorePlay, discussed in the next section.

### CorePlay

An experimental idea in the context of JAM, CorePlay can be described as a new model for programming smart contracts. CorePlay remains an idea without specific detail. In any case, to understand CorePlay, we need to first introduce JAM's virtual machine of choice, the Polkadot Virtual Machine. This is also known as PolkaVM or plain PVM.

### PolkaVM

An important detail of JAM and CorePlay is [PolkaVM](https://forum.polkadot.network/t/announcing-polkavm-a-new-risc-v-based-vm-for-smart-contracts-and-possibly-more/3811). Low-level details of PolkaVM are beyond the scope of this article and are best described in the Gray Paper by the domain experts. Yet, for the sake of this article, we only have to elaborate on two of its properties:

- Efficient metering
- The ability to pause and resume execution

CorePlay is one example of using JAM's flexible primitives to create a synchronous and scalable smart contract environment with a very flexible programming interface. CorePlay suggests deployment of actor-based smart contracts directly on JAM cores, enabling them to enjoy a synchronous programming interface whereby they can be coded as a normal fn main(), in which they can communicate using let _result = other_coreplay_actor(data).await?

In the case other_coreplay_actor is in the same core in that JAM block, this call is synchronous, and in case in another core, the actor is paused and will be resumed in a later JAM block. This is possible because of JAM services and their flexible scheduling, along with PolkaVM's properties.

### Core Chains Service

Finally, let's wrap up by reminding all readers of the main reason why we mentioned JAM is fully compatible with Polkadot. The main product of Polkadot is parachains in the Agile Coretime fashion, and this product persists in JAM.

The first service that will be deployed in JAM is likely to be one that is called something along the lines of "core chains" or parachains. This is the service that will allow existing Polkadot 2.0-style parachains to be executed on JAM.

Further services can be deployed on JAM, and the existing core chains service can communicate with them, but the existing product offering of Polkadot will remain strong, and only new doors will be opened to existing parachain teams.

We tell the story of Parity's technical roadmap with regular blogs. Read on to find out the latest on major upgrades that are delivering scalability for the Polkadot ecosystem.

Blog

Want to learn more about Polkadot? We don't blame you!

Blog

BlockDeep Labs Takes Over Maintenance of Polkadot JS

Scaling Polkadot: Does it come at a price?

ETHDenver: Good vibes, plus round-the-clock networking

Scalability² - The Stepping Stone to a Web3 Cloud

The JAM experience. What’s it really like?

Polkadot: Closer to the Rollup Model than you Realize

Polkadot XCM: Enabling True Interoperability

A Roadmap to a More Accessible Polkadot

How to Make Meaningful Content in Web3

Demystifying JAM, Polkadot’s game-changer