Gavin Wood: After EVM, JAM will become the new industry consensus!

Following up on yesterday's article, we are sharing the second part of Gavin Wood's latest interview!

Public blockchains can compete with each other, but developers only gather around consensus.

Ten years ago, the EVM invented by Gavin became the consensus; from then on, the entire industry had a common "language."

Ten years later, Gavin has launched JAM, hoping it will become the next "language."

It is not a tool for a specific chain, but a fundamental protocol that enables all chains to achieve elastic scalability, distributed collaboration, and cross-network interoperability.

Any builder can construct their own system on top of it, even allowing different tokens and ecosystems to share the same security network.

For developers, this means one thing:

To build the next generation of blockchains, you don't need to start from scratch—JAM is the new default starting point.

The atmosphere of JAM is something I haven't felt since after 2015

Pala Labs: The global JAM tour is already halfway through. You have personally traveled around the world, meeting JAM's actual developers and enthusiastic supporters. How do you feel about this decentralized building model of JAM?

Gavin: So far, I am very optimistic about JAM's overall progress. The developers of JAM have shown a passion and initiative that was not common during the Polkadot development period—they genuinely love this project and are willing to take real responsibility for their work.

To understand this difference, we need to go back to Polkadot's development model. At that time, development was carried out within a company structure. Although there were also dedicated and responsible people on the team, under the company structure, this "initiative" was somewhat taken for granted—it was your job to take responsibility because you were paid a salary.

But JAM is completely different. The current developers do not have stable salaries; they are investing their own time, energy, and taking on risk. In the future, they may indeed receive funding or rewards, but only if they deliver results first. In contrast, the logic of hiring employees in a company is the opposite—the company pays high salaries upfront, and whether the employee is competent or not, the risk is borne by the company.

JAM's developers are taking on the risk themselves, and this investment speaks for itself. You are facing a team that is truly building for the vision and capable of delivering results. In this environment, you see a rare sense of conviction—something that is hard to find among traditional company employees.

Ultimately, the organizational structure of traditional companies is essentially a top-down power system: the boss holds the highest decision-making power, delegates to executives, who then assign tasks to team leaders, and finally, the leaders assign tasks to the grassroots employees. Everyone has to report to their superiors, act on instructions, and their performance depends on their superiors' evaluations.

But JAM is nothing like this model.

In this project, I am more like a consultant, just answering questions when people need me—sometimes my answers are brief, even a bit direct, but overall still friendly. Besides that, I am responsible for writing the gray paper and doing my best to verify whether the designs in the paper are feasible—at least convincing myself, and hopefully helping others understand the rationale behind these solutions.

However, what truly drives JAM forward is not me, but the teams involved in development. They may be involved because of passion, to gain experience, or because they believe this system will have commercial value in the future. But regardless of their motivation, they are actively and spontaneously building this system.

This atmosphere is something I have felt for the first time since 2015, very much like the early days of Ethereum—everyone was passionate and involved; even though the gray paper was extremely difficult, they were willing to spend a lot of time understanding it and step by step turning it into real, running software.

After EVM, JAM will become the new industry consensus

Pala Labs: It sounds like JAM is not just a traditional blockchain project, but seems to go beyond the scope of blockchain and cryptocurrency, even bigger in scale than Polkadot. If you had to explain JAM to someone unfamiliar with Polkadot, how would you describe it? What exactly is this tool for?

Gavin: Simply put, JAM is a protocol called "Join Accumulate Machine," with its complete specification clearly written in the JAM gray paper. According to the gray paper, JAM combines the core advantages of Polkadot and Ethereum:

• On one hand, it inherits Polkadot's crypto-economic mechanism—which is what supports Polkadot's high scalability;
• On the other hand, it adopts an interface and service model closer to Ethereum, allowing the main chain itself to be programmable.

Unlike traditional architectures that only make high-performance computing modules programmable, JAM goes a step further. Not only does it make the computing units programmable, but it also allows the "collaboration process" and "accumulation effect" between different modules to be controlled by programming—this is the origin of the name "Join Accumulate Machine."

Although JAM was initially proposed as a Polkadot upgrade proposal and received broad support from the community, its design is by no means limited to Polkadot. It is a highly abstract, foundational architecture independent of any specific blockchain, and can be seen as the basic design for the next generation of blockchains.

The core capability of JAM is that it can securely and in a distributed manner schedule and allocate workloads across the entire network, giving applications running on it natural elastic scalability—something no other solution in the industry can currently achieve.

Furthermore, JAM supports interconnecting multiple network instances, allowing applications to scale beyond the limitations of a single chain. This makes it not just a new chain architecture, but potentially a paradigm for the next generation of scalability solutions.

We can completely look at JAM outside the framework of a "Polkadot upgrade proposal." As I insisted when writing the gray paper: I am better at pioneering work from zero to one, rather than pushing an existing system from one to one hundred. Therefore, JAM's design is not based on gradually expanding an existing framework, but starting from the most basic principles and building a brand new system from a blank slate.

Although JAM has absorbed some of Polkadot's existing technological achievements, it also incorporates many new ideas and mechanisms. I systematically wrote these into the gray paper, hoping to extract them from the context of Polkadot and make them a foundational architecture of broader value—a bit like the x64 instruction set back in the day.

Speaking of which, let's review the history of x64. Intel originally designed the x86 instruction set for its own processors, evolving from the early 8086 to 80286, 80386, and then the Pentium series. This instruction set gradually evolved and eventually became the standard for IBM-compatible machines, dominating the desktop computing field for a long time.

But when the industry was ready to move to the 64-bit era, Intel's self-developed solution was too advanced and failed to gain market acceptance. At that time, AMD, seen as a "follower," instead designed a simpler and more feasible 64-bit extension—AMD64—based on Intel's 32-bit instruction set. As a result, the market chose AMD's route, and Intel had to abandon its own solution and adopt AMD's extension. Since then, the roles of leader and follower were reversed.

This history is meaningful. Although Intel later adopted AMD's technology, it was unwilling to use the name "AMD64," and the industry eventually formed a neutral term—"x64." Today, both companies build products based on this unified instruction set architecture.

The reason I mention this case is to illustrate: I believe JAM is likely to become the "x64 technology" of the blockchain field. It is seen as the rational evolutionary direction for blockchain development, especially fitting for public chains that value resilience and decentralization, in line with Web3 principles. The protocol deliberately maintains openness in many aspects such as governance models, token issuance mechanisms, and staking systems. This means that different blockchain projects can customize the implementation of these modules when adopting the JAM protocol, and can even choose their own programming language.

The PVM used by JAM is a highly general-purpose instruction set architecture. Chains that adopt this architecture can gain the scalability and composability advantages provided by JAM, and may also achieve collaboration and integration between different chains through JAM in the future.

Recently, I've been thinking about a direction—which I hope to organize and publish soon—exploring how two blockchain networks based on JAM but using different tokens can achieve further integration: sharing the same security network while retaining their own token systems. I believe that even if this technical path is not the ultimate form of the blockchain industry, it will be an important breakthrough that can change the industry landscape.

From a broader perspective, JAM is likely to become, like early Ethereum technology, a universal foundation for the industry. The EVM of Ethereum has already been adopted or partially adopted by many public chains, and its transaction format and execution logic have become the de facto industry reference standard. JAM also has this kind of neutral technical potential across tokens and networks.

As I have repeatedly emphasized, JAM should be a neutral underlying technology. I firmly believe that its design is sufficient to support the stable development of the blockchain industry for the next five to ten years, or even longer. Of course, the entire system will continue to evolve in the future. If zero-knowledge proofs (ZK) become economically feasible, some modules of JAM may also be replaced. But overall, as a reasonable system innovation, JAM's application scope will by no means be limited to the Polkadot ecosystem; any chain that recognizes its value can choose to adopt it within its own governance framework.

In addition, JAM has adhered to the principles of decentralization and "specification first" from the very beginning: first publishing the protocol specification, then organizing implementation, and promoting the participation of more than 35 independent teams worldwide in development, so that knowledge and control are naturally distributed. This approach will help JAM develop into a truly neutral and widely adopted core underlying technology in the Web3 world.

In the "post-trust era," Gavin tells young developers: Web3 is not a choice, but a responsibility

Pala Labs: We have met many passionate JAM developers this time, many of whom are very young, possibly still students, and represent new forces in the industry. If you were to say something to these people—they may be very much like you 20 years ago, loving to create and longing for a free society and world—what would you want to say to them?

Gavin: Get involved as early as possible and keep digging deeper. You must follow your own value judgment. If you agree with the core ideas of the Enlightenment, such as free will and personal sovereignty, then you should act on them yourself—because no one else can take on this responsibility for you.

Pala Labs: Will artificial intelligence also bring problems of identity forgery?

Gavin: Today's social trust system is rapidly collapsing. Around 2014 or 2015, a term became popular—"post-truth era," meaning that people no longer believe in the existence of objective truth. Although this statement has some observational value, it is not philosophically valid. I have always insisted: truth exists, and humans have an obligation to pursue it. If a decision is not based on the most reasonable and reliable facts at the time, it is bound to be wrong.

Nevertheless, we have indeed entered a "post-trust era": people either remain skeptical of everything or place their trust recklessly in dangerous demagogues. Both extremes are eroding social rationality. In this context, artificial intelligence will only further amplify the problem.

Of course, AI has positive significance in many fields, such as enhancing communication and enriching artistic creation. I myself often use it when DJing or creating music. But at the level of social economy, political systems, and geopolitics, the risks brought by AI cannot be underestimated.

We cannot place our hopes on regulation. Regulation often only restricts law-abiding individuals in free societies from using AI, but cannot stop malicious organizations, nor can it prevent unfree countries from using AI to attack free societies. Therefore, regulation alone is not the solution.

What is truly necessary is: to use a stronger and more solid technical foundation to limit the destructive impact that artificial intelligence may bring—whether to deal with internal abuse or to resist external malicious threats.

In my opinion (though perhaps a bit biased), only Web3 technology can truly solve this problem. The reason is not complicated: the essence of AI is "weakening truth, strengthening trust." When we rely on artificial intelligence, we are actually relying on the organizations that provide the models and services behind it—whether it is the institutions that train large models or the service providers that run models on closed servers and return results.

But we cannot audit the training data of the models, nor can we confirm why it gives a certain answer; even the trainers themselves may not truly understand the internal mechanisms of the models. In contrast, letting individuals rely on their own abilities to verify facts is actually more reliable. However, as society becomes more dependent on AI and trusts it more easily, people will gradually fall into a situation of "seemingly objective, but actually blind trust."

Since the logic of AI is "less truth, more trust," we must use Web3 technology, which is "less trust, more truth," to balance it.

In a free society, what really should be done is not to further strengthen regulation of Web3, but to take action as soon as possible: reduce unnecessary restrictions and provide real support and funding for those building Web3 infrastructure.

Pala Labs: Now that many new developers are joining the JAM project, can you give an outlook for the next five or six years?

Gavin: Predicting the future is always difficult, but I can share my own experience. At the end of November 2013, I was living in London. At that time, I had a friend called "Johnny Bitcoin," who was also a friend of Vitalik. We would go to the pub every month for a beer and a chat. During that meeting, he told me that his friend Vitalik was working on a new project based on bitcoin, called Ethereum, and was looking for someone to handle the code development. I half-jokingly said, "Sure, leave it to me." After all, I always thought I was pretty good at programming, so he suggested, "If you're so good, why don't you develop Ethereum?" That's how I became one of Ethereum's developers. At that time, the Ethereum white paper was somewhere between a vision document and a clear formal specification. Although not entirely unambiguous, it contained enough technical detail to be feasible. Over the next four or five months, everyone worked on developing compatible versions, which eventually led to the Ethereum yellow paper—the formal protocol specification document. At that time, I was the independent developer responsible for this protocol, of course along with Vitalik, and also Jeff, who was responsible for the Go version of Ethereum. Later, I became a co-founder of Ethereum, founded Parity, and continued to develop more related products.

My journey in blockchain started just like this—as an independent developer, relying entirely on myself and my spare time, developing a protocol from scratch.

So I'm not sure whether the JAM development team will enjoy this development journey as much as I did. But for me, this was truly the starting point of my life. At that time, I had no other choice but to start here, and as it turned out, the potential of this path far exceeded my imagination.

Of course, this requires not only writing code but also learning to communicate: connecting with potential investors, giving project presentations, designing application scenarios based on the protocol, even writing smart contracts, promoting the project, giving advice to others, and so on. Besides writing code, there are many other things to do, but coding is the starting point of everything and the core throughout.

In the past 11 years, I have hardly ever stopped programming for long. In fact, this experience goes back even further—since I was eight or nine years old, I have hardly stopped—the longest break was a three-month hiking trip in Central America.

This is the path I took. If these new developers have enough passion and ability, in my view, nothing can stop them from stepping onto this road—except this time, the goal is JAM, not Ethereum!