Polkadot Core Development Deciphers JAM: You can build applications beyond chain architecture!

Jay: Regarding Core JAM, what do you think? Is it revolutionary or evolutionary change?

Shawn: I believe that this change is revolutionary for our ecosystem because it brings new possibilities and transformations. However, from a technical perspective, this change is an incremental development on Polkadot’s technology stack, meaning it is based on the continuous evolution and improvement of existing technology.

The key point mentioned here is that despite technological advancements, the mission remains consistent. This mission is to create a platform that enables people to easily launch Web3 applications with characteristics such as resilience, decentralization, and censorship resistance. This vision began in the Ethereum era, and Gav has been committed to achieving this goal. Polkadot can be seen as an extension and development of this vision, enhancing the scalability and flexibility of the system through the use of sharding and parallelization technologies.

Currently, the technology provided by Core JAM still forms the foundational layer of blockchain and Web3 ecosystems, enhancing the capabilities of blockchain through sharding and scaling technologies. However, its goal is to reduce reliance on specific technologies and make the system more universal and flexible, allowing users to use this computing platform in multiple ways.

In the current parallel chain V1 model, there are many cores, but each core can only run one application. An improvement brought by Core JAM is questioning why we should limit each core to be used by only one application, given that these cores can perform many tasks. In fact, we can share these cores. Different applications require different resources: some may need more computing power, some may need more data availability, while others may need more storage space. Therefore, we can utilize different parts of the core and pair different applications together so that they can fully utilize all available resources. Our goal is to ensure that no resources are wasted on this chain. The role of Core JAM and core time is to make the entire system more accessible and flexible to achieve this universal blockchain space.

So what’s different? I think the concept of “parallel chains” may gradually disappear. In the traditional blockchain model, each blockchain runs independently on its own core. This idea will become more blurred in the future because we will be running applications, not just blockchains. These applications can be parallel chains, but they can also be more flexible. Gav may have hinted at these changes, stating that any function with a main entry point can run on the system, which means you don’t necessarily need to build a complete blockchain. Your application can simply be a simple program running in Polkadot’s data availability layer, such as a transient application existing only in memory. In summary, the significant change here is that we need to rethink the assumptions about how applications run, and it may no longer be necessary to build complete blockchains, but there can be more flexible ways of operation.

PolkaWorld Note: The views here are very similar to those proposed by Acala CTO Byran regarding chainless applications. You can find more in “Acala Bryan Deciphers JAM: Polkadot 2.0 May Bring Chainless Decentralized Applications, Bringing an Unlimited Potential Future!”

Jay: Do you have any examples of applications running outside of parallel chain architecture?

Shawn: While this may not be the main focus of Core JAM itself, as part of the blockchain space segmentation, the Celestia project is currently receiving a lot of attention. Celestia is working to provide data availability support for various rollup solutions. Polkadot already has a large amount of data availability and has a very powerful technical stack, enough to compete with other specialized solution providers. Therefore, there is no reason why rollup solutions cannot leverage Polkadot’s data availability to achieve their goals. For example, you can use Polkadot’s technical stack and all validators, but you don’t necessarily need to build a complete parallel chain; you can actually just do a rollup, which is a lighter-weight solution focused on processing transactions rather than maintaining a complete blockchain.

Now, if I were to create some basic applications from a developer’s perspective that don’t need to be full parallel chains but rather simple “Hello World” applications, you can imagine the simplest program, like a basic counter application, with just a few lines of code, no underlying storage, not a blockchain, but capable of performing increment and decrement operations. Anyone can call this counter, and its state will be stored in Polkadot’s data availability layer. As long as someone calls it once every 24 hours before data clearing, the state of this counter will be persisted. These simple applications are very similar to smart contracts, but Polkadot does not provide long-term storage, which is a major issue facing blockchains. If you are just building a transient application, such as a simple counter or a “Hello World” application, you don’t need long-term storage, and you don’t need to pay for it either; we just provide an alternative solution. So I think those are some exciting things I’d like to see once the technology is in place, we can show people how easy it is to build this very simple “Hello World”.

Jay: Did you say Polkadot hasn’t committed to providing long-term storage?

Shawn: Scalability is an important aspect of Polkadot’s design. Polkadot has its own storage system and validators running relay chains, but it achieves scalability through data sharding. In this architecture, each parachain is responsible for managing its own data, while collators are entities responsible for this task. Polkadot only stores root hashes, which is a cryptographic technique used to ensure that the data provided to the network matches the data agreed upon by the entire network. If Polkadot were to attempt to provide long-term storage for every user, it would not be able to scale effectively. While there are ways to store data long-term on Polkadot, pushing data directly to the relay chain itself is not the ideal approach. Instead, structures such as system chains can be created specifically for supporting long-term storage, competing with other storage solutions like file storage.

In Polkadot’s development roadmap, the simplest approach is to avoid complex storage requirements and focus on simple applications that use memory. These applications process data only in memory during runtime and do not retain data after execution. For example, a calculator application is such a simple example that does not need to write data to long-term storage during its usage. As Polkadot’s technology evolves, creating such simple, transient applications becomes easier. This applies not only to complex industrial-grade applications but also to simple applications that only need temporary existence. The ability to easily create these simple applications is a powerful feature of Polkadot.

Disclaimer：

1. This article is reprinted from [PolkaWorld], All copyrights belong to the original author [PolkaWorld]. If there are objections to this reprint, please contact the Gate Learn team, and they will handle it promptly.
2. Liability Disclaimer: The views and opinions expressed in this article are solely those of the author and do not constitute any investment advice.
3. Translations of the article into other languages are done by the Gate Learn team. Unless mentioned, copying, distributing, or plagiarizing the translated articles is prohibited.