Author: Bryan; Source: PolkaWorld
On March 12, Gavin shared the JAM architecture for the first time at the sub0 conference in Bangkok! What is JAM? How does this impact Polkadot? What kind of innovation will it bring? Acala CTO Bryan made his unique interpretation on X for the first time. The following is the version compiled by PolkaWorld, take a quick look!
If you want to learn more about JAM, here is a draft RFC for CoreJam, the predecessor to JAM. Please note that this is an initial draft and many technical details have changed. There will be a new draft RFC for JAM. https://github.com/polkadot-fellows/RFCs/pull/31
JAM: Reorganize Polkadot relay chain components, beyond the relay chain Architecture
An important feature of JAM is its ability to abstract the blockchain part of the decentralized technology stack. strong>. It provides a concept similar to a world computer, with multiple cores capable of executing any program or service.
The Polkadot relay chain is composed of different components, and JAM actuallyreconstructs this architecture, the basic components can also be exposed, so that developers can use these basic components to build a variety of services, including general DA services, instead of just building parachains now.
By using JAM, we can run parachain services to build a decentralized and secure blockchain. But building a decentralized blockchain is just one of many applications of JAM. There are many more interesting applications we can develop with JAM, Data Availability (DA) is one useful example, but it is not a game-changing innovation.
Developers can deploy a variety of services on JAM, one of which can be Parachain Service, that is, a parallel chain or blockchain can be built through JAM ; But developers can also deploy a Chainless EVM Service on JAM, which is a service without a chain. An example is a contract wallet.
JAM brings serverless applications
Bryan shared One change that JAM may bring is Chainless Dapp, that is, chainless decentralized application.
What does this mean? In the current scenario, every decentralized application (dApps) that requires computing power runs on a blockchain or similar platform. However, with the introduction of JAM, decentralized applications can perform computing tasks without relying on traditional blockchains, that is, Chainless Dapps.
In Web2 terms, Ethereum, or most independent blockchain networks, is like a server hosted in someone's basement. Polkadot provides a cloud computing-like solution where people can rent an instance for a period of time to run their own blockchain while enjoying the shared security provided by the Polkadot network. This means that users can use Polkadot’s infrastructure to run and maintain their own blockchains without the need to build and manage servers themselves.
And Polkadot 2.0 goes one step further, providing a serverless solution. Developers no longer need to worry about servers. Applications can be run somewhere in the cloud upon request. Again, protected by shared security.
Serverless Before, cloud services were very simple, just renting machines and deploying services on them. Then he is responsible for maintaining the machine, upgrading the system, and applying patches, but there is a relatively high maintenance cost. The same is true for current parallel chain development. We have to spend a lot of energy on maintaining the chain and upgrading Polkadot-sdk, etc., which is relatively expensive.
The concept of Serverless is that as a developer, I only need to write my business logic. I don’t need to maintain the machine, and I don’t want to think about load balancing, scale up/down, etc. thing. JAM allows protocol developers to develop a function similar to AWS lambda, reducing maintenance costs for application developers. For developers, there is no concept of a server.
AWS lambda is a Serverless service. Developers can write code, throw it to AWS lambda, and then make some configurations. When users access this service, aws will A certain machine executes code and processes user requests. AWS lambda will be responsible for the maintenance, system upgrades, security, etc. of all machines.
Many of the advantages brought by serverless applications also apply to decentralized applications that do not rely on the blockchain (chainless decentralized applications ). These applications are highly scalable because multiple copies of the application can be run simultaneously on multiple processing cores. Additionally, such an application can be very economical because it only consumes resources while being used rather than running continuously, thus reducing costs. It can significantly reduce operating costs since there is no longer a need to maintain servers (blockchain). The maintainer that executes the runtime (i.e., the JAM service) handles all operational work, such as upgrading and implementing new features.
Serverless technology has revolutionized the way some cloud applications are developed. JAM will bring about similar changes. However, it should be noted that not all modern cloud applications adopt serverless architecture, and traditional servers still have a place in today's technology environment. This also applies to parachain technology, which still has its own advantages and application scenarios.
Imagine that developers may have a JAM Service called EVM contract in the future. This may be maintained by a community project and be responsible for upgrading the EVM version. Add features and more. Users can use this JAM Service to directly deploy and execute EVM contracts.
The future of unlimited potential that JAM will bring
JAM’s growth doesn’t stop here. JAM provides a very interesting model and many primitiveswith great potential. I believe we will discover more modern decentralized applications of different models. Essentially, JAM aims to remove some of the existing limitations and provide developers with more freedom and flexibility than Polkadot 1.0.
I haven't mentioned here the ability to synchronous messaging between different JAM applications. This is something Web2 apps cannot do, as they typically rely on the server to handle messaging rather than direct synchronous communication between apps. This feature provides more possibilities for interaction and collaboration among decentralized applications.
In Web2 technology, asynchronous requests (i.e. requests that can continue to perform other tasks while waiting for a response) are basically a solved problem. However, we must admit that asynchronous requests add a lot of complexity and introduce many errors. Some common problems include "callback hell" (where multiple levels of nested callback functions make code difficult to understand and maintain) and "race conditions" (where multiple concurrent operations lead to unpredictable results) . We are starting to observe these issues in today’s cross-chain messaging protocols. But that may no longer be an issue.
JAM is still in its very early stages and a lot of work needs to be done to get it ready for use. If you want to learn about the JAM RFC as soon as it is released, please pay attention to the Fellowship RFC repository: https://github.com/polkadot-fellows/RFCs
JinseFinance
Bernice
Edmund
Weiliang
Xu Lin
Clement
Olive