Compiled by: PolkaWorld

A few months ago, Gavin was interviewed by Raoul Pal. Although it is not the latest video, some of the views Gavin talked about are still worth knowing! As usual, we will publish it in two parts! This article is the first half of the video! Gavin mainly shared some interesting stories before he started Ethereum, as well as some reflections and lessons from the process from Polkadot 1.0 to JAM.

Let’s enjoy some famous quotes first!

• Ethereum wasn’t just a copy of Bitcoin, it was really trying to push the boundaries. No one was building it at the time, and I knew I could build something new from scratch.

• In a way, Polkadot is my attempt to further contribute to the Web3 space technically. The idea came from my thinking about what Ethereum 2.0 would look like.

• If the system cannot be expanded by improving the performance of a single node, a "horizontal expansion" approach will be required.

• I firmly believe that having a single security umbrella makes the most sense. I feel that a decentralized security model makes no sense.

• The biggest change I made on Polkadot is about the idea of ​​what I call "continuous fragmentation of state." We should not let "continuous fragmentation" become a fixed mode, we should adopt a more flexible and short-term fragmentation method.

• Now the definition of "parallel chain" can be greatly relaxed, and any chain that can be integrated into the JAM model of this universal "world computer" can be regarded as a parachain.

• The core issue we are discussing is actually scalability, which is not only about increasing the input and output of data, but also about improving the efficiency of data processing in the system. Only by increasing these capabilities by several orders of magnitude can we truly support meaningful use cases in the real world and migrate existing Web2 applications to Web3.

• The goal of JAM is to allow you to run almost ordinary computer code directly instead of smart contracts, without the need for complex gas optimization. You can upload the code and run it at very little cost, thereby attracting users.

• Once Web3 becomes a legitimate alternative to Web2, enough of a market will open up that even if the cost of block space approaches zero, there will still be enough value to pay the validators who maintain the network.

• If block space is cheap enough, close to zero cost, then the question is no longer about entry barriers and application scenarios, but about whether they are really useful and whether there are users and markets.

Keep reading to find out more!

Gavin’s story before Ethereum

Raoul Pal: You have a really fascinating personal story, so if you don’t mind, could you take us back in time and share your story, starting from before Ethereum and how you got into this space in the first place?

Gavin: I've always been interested in economics and game theory. I studied computer science at university, but my first exposure to Bitcoin was in February or March 2013, when I read an article about Amir Taaki, a Bitcoin programmer and self-proclaimed cypherpunk and crypto-anarchist. He seemed like a very bright presence, and I thought it would be interesting to meet him and hear his views on the world. I was also interested in contributing to the Bitcoin project at the time, so I wrote him an email, he replied, and then we met in an abandoned building in London, which was my first time to go to an abandoned building. He introduced me to a few people in the Bitcoin community, and the first one was Mihai Alisie and his girlfriend Roxana. She was sitting on a mattress at the time, and the room looked like an office, and the abandoned place was actually an office building. I was a little surprised that the first meeting was in this environment.

But Mihai later became my co-founder at Ethereum, so it was a bit of a strange first meeting, but it was a very meaningful one. He also introduced me to a few other Bitcoin people who were running Bitcoin Cash exchange points in London at the time, and through them I kept in touch with these people, and eventually through them I met Vitalik. I read Vitalik's Ethereum white paper in late 2013 and started writing code.

Raoul Pal: When you first saw the Ethereum white paper and talked to Vitalik, what made you think this would be a breakthrough moment? What made you think Ethereum was more attractive than Bitcoin? Because at that time you could choose to stay in the Bitcoin ecosystem, but you chose Ethereum.

Gavin: I could definitely stay in the Bitcoin ecosystem. Ultimately, when you're building something, you look for where you can add the most value. Bitcoin already has a team, a client, and a community, and it's already a mature system. Ethereum, on the other hand, doesn't look like a simple copy of Bitcoin, it's really trying to push the boundaries. No one was building it at the time, and I knew I could build something new from scratch. At that time, I felt that my expertise and the value I could bring would be greater in helping to build something completely new, and my abilities would be more applicable in such a project.

Surprised by Ethereum’s success?

Raoul Pal: Were you surprised by its success or did you always think it was the next big breakthrough? Because there were so many other blockchains emerging at the time, did the success of Ethereum surprise you?

Gavin: If I was really surprised, I probably wouldn't be so committed to it. You can never completely predict the outcome because it depends on many factors besides whether an item is slightly or significantly better, but also whether it adds specific functionality. However, I did have a hunch. The real reason why I had this premonition was that I went to Miami in January 2014, met several co-founders, and experienced the atmosphere of the Bitcoin community for the first time. The event was a large Bitcoin conference in Miami, Florida, and it was a very lively, party-filled event. At that time, Vitalik invited me to a hackathon in Miami and said we would complete coding work there. So I flew to Miami thinking I would work with the development team for a week, but it turned out to be more like a party house and I ended up just coding. Nonetheless, this experience made me feel the excitement and enthusiasm from everyone.

There were other projects at the time, if you remember, like Mastercoin, which was hot at the time, and the main idea was "This is Bitcoin, but you can do financial instruments on it." There was Counterparty, which was similar to Mastercoin, but for different applications. There was NXT, which was a proof-of-stake version of Bitcoin. To me, it was clear at the time that Ethereum offered more possibilities than these blockchain projects that were just starting out.

Add to that the excitement and I can see that the other co-founders are also important driving forces. I think Ethereum really has a big chance and could become very big.

Why create Polkadot?

Raoul Pal: So, what made you decide to create your own blockchain? I remember someone mentioned that I have been involved in this space since 2012 or 2013. At that time, someone introduced Polkadot to one of my roundtables, which should have been before your official launch. They said this project is very important, but I didn't understand what "interoperability" was at all at the time. I was thinking to myself, this sounds good, but I really don't know what you are talking about. So, can you tell me the story of founding Polkadot? How did this idea come to your mind? We can talk about this journey, where you feel you have been right, where you feel you have been wrong, and the direction of the future.

Gavin: In a way, Polkadot is my attempt to further contribute to this field technically. The idea came from my thinking about what Ethereum 2.0 would look like, or how the system that is the successor to Ethereum should work. I have always thought that it is likely to be a multi-chain architecture with many different chains. However, before the concept of Polkadot was formed, I imagined that these chains would perform the same functions, like Ethereum, they are all EVM chains, similar to the operation mode of Ethereum 1.0.

At the time, I imagined that there would be something like Ethereum's "Beacon Chain", which is called the "Relaychain" in Polkadot. This top-level chain will ensure that all sub-chains are running correctly. But then I thought that maybe these chains don't have to do the same thing, and it might even be simpler for them not to do the same thing. These chains can be different chains that focus on different areas, such as application chains - this is a term commonly used now.

Even though they function differently, they share the same security so that they can easily interact and interoperate. Interoperability can have a few different meanings here, so it can sometimes cause confusion. But in this context, when I say interoperability, I actually mean that these chains can interact securely under the same security framework and can interact directly with each other for causal relationships.

Of course, we learned a lot of lessons along the way. Ultimately, this is an experiment. We are not sure how much practical value this level of interoperability will have compared to Ethereum's synchronous composable interoperability - that is, contracts can call each other and respond instantly. However, if you trace the origins of Polkadot, its core idea is to bring a group of different chains under the same security framework, each chain focusing on its own specific field.

Raoul Pal: In fact, you had foreseen it long before everyone realized that we were going to enter a multi-chain world. This concept has been questioned a lot because many people think that there will only be one EVM world or one Bitcoin world in the future, but you considered at the time that there may be multiple different chains coexisting in the future.

Gavin: For me, it wasn't out of some ideological standpoint, it was just a necessary need for scalability at the time. At the time, everyone was talking about how to scale, because Ethereum was great, but it didn't scale. So the question became: How do you make the system scale? The answer is, you need to parallelize processing. You can scale synchronously, which is what Solana is trying to do, by using faster and faster validators and making them more connected. However, you will eventually hit a bottleneck, especially if you want to keep the characteristics of Web3, the barrier to entry will become higher and higher, and it will become more and more difficult to participate. Validators need very powerful hardware, and the barrier to entry will make it difficult for many people to enter.

If you can’t scale the system by improving the performance of a single node, you need to adopt a “horizontal expansion” approach. This is a classic Silicon Valley way of thinking. The key to expansion is to share the workload across multiple nodes. The specific approach is to process the workload in parallel, split it into small tasks, and let different nodes complete them. This is exactly the core concept of Polkadot.

My original idea was that when you split the workload, you don’t need to keep each part in its own chain and state for a long time. In fact, tasks can be distributed and processed in a shorter time and with more flexibility. However, the basic idea of ​​splitting and distributing the workload to scale the entire network is inevitable.

What did Gavin think about during the process from Polkadot 1.0 to JAM?

Raoul Pal: How did your assumptions change? What prompted you to take new actions? Because you have also been building a whole new world for Polkadot, what made you feel that it is okay to push the boundaries again?

Gavin: The biggest change is about what I call the continued fragmentation of state. I firmly believe that having a single security umbrella makes the most sense. I think decentralized security models make no sense. Like the Cosmos model, although now the Cosmos people are also starting to try to do shared security, it's not really done. The original Cosmos model, and the current Cosmos model, are based on decentralized security. I don't think this is wise. I believe in the Ethereum and Polkadot model, which is to have a single security umbrella and parallelize under this framework.

The change in attitude is mainly reflected in the way and structure of parallelization. The main difference between my view on Polkadot 1.0 and JAM, which was recently introduced in the gray paper, is that the model of Polkadot 1.0 is "continuous fragmentation", that is, we will have multiple blockchains, each with its own state, they operate in an isolated state, and although their security is uniformly guaranteed, they operate independently, and each chain has a different set of collectors and state transition rules, etc. However, they can send messages to each other, so we have XCM messages, which is a relatively coarse-grained way of interaction, which is far less detailed than the interaction between smart contracts on Ethereum. I realize that this greatly limits the combination you can achieve and the block space usage model you can exploit. Therefore, the conclusion is that we should not make "continuous fragmentation" a fixed mode, at least don't assume that it must work this way. Instead, we should adopt a more flexible and short-term fragmentation.

So basically the fragmentation of state is one big overall state, rather than having persistent, long-term fragmentation at the boundaries of the blockchain. Instead, we arbitrarily repartition the state about every six seconds. Of course, arbitrary fragmentation brings up the question of "how to do it", and we are considering some possible solutions. But our approach is not to fix this fragmentation at the protocol level, but to repartition it based on new use case requirements and do it on a per-block basis.

So what we are doing is transforming the Polkadot relay chain, which was originally designed for a specific purpose (originally to provide security and pass messages between different blockchain ecosystems), into something like a "world computer", which is like a ubiquitous multi-core virtual machine that can host programs. Our goal is to enable these programs to not only process large amounts of data, but also perform large amounts of computational tasks.

Raoul Pal: For those who may not understand the point you just made, can you explain it with a specific use case? Because when you think about solving a problem or a future state, you must have a model in your mind. This model will help you think about: how can this technology be used? What changes can it bring to people? How can it open up new use cases for blockchain technology? How do you think about these issues?

Gavin: I can give you a very simple example, which is an idea that has been discussed in the Polkadot ecosystem. This idea has been around for a while, and it was first called SPREE, and later I named this general approach Accords. You can think of "Accord" as a smart contract that manages how two independent blockchains interact with each other. Basically, although different parts of "Accord" may run on different blockchains, they all know that they belong to the same system. This is a bit like international law. Once a blockchain commits to abide by this agreement, it cannot withdraw at will. They cannot choose not to execute this agreement in certain circumstances, either comply or withdraw from the agreement. As long as they comply with the agreement, they will be able to interact with other blockchains that also comply with the agreement.

You can think of Accord as an example of a token agreement. This agreement ensures that when I want to send you a token, I will make sure that you will mint a new token only after you destroy the corresponding token. Similarly, I also know that you will mint a new token after I destroy the token. This means that two blockchains can interact directly through this bilateral message without having to trust the blockchain itself to handle these transactions.

Raoul Pal: Is this limited to the Polkadot ecosystem, or can it be applied to any chain?

Gavin: It only applies to chains secured by Polkadot and are part of the Polkadot ecosystem. However, the definition of "parachain" can now be greatly relaxed, and any chain that can fit into this general "world computer" model can be considered a parachain. Therefore, we can further imagine - and now we can understand more clearly - that Polkadot was not originally designed to handle chains like ZK Rollup, but its architecture is general enough that it can be barely implemented, but this model really makes Polkadot's computing power more general.

But this makes us start thinking: if it is not a traditional parachain, but a ZK Rollup chain, can Polkadot still check all the transactions of these chains to ensure their correctness? Then, it can do more things, such as sorting these transactions correctly, or making them follow Accord, or even ensuring that their messages can be delivered correctly.

How does JAM drive adoption, growth and usage?

Raoul Pal: In terms of real-world use cases, how does this capability drive adoption and usage in the Web3 world?

Gavin: I look at this problem from a more basic perspective and don't think too much about specific applications. For example, I can tell you what supply chain management can achieve, but the specific application is not that important. The key is whether it can support an application of a certain scale. Suppose you want to track all the supply chains in the world and record all the shipping information, which involves a lot of data. For example, there may be thousands of ships and millions or even tens of millions of shipping containers in the world. You need to be able to input all this data into a large state machine and perform enough calculations on this data to ensure that this application makes sense in reality.

The core issue we are discussing is actually scalability, and the current blockchain cannot handle such requirements well. We need to increase the amount of data and computing power that the blockchain can handle, not only to increase the input and output of data, but also to improve the efficiency of data processing in the system. Only by increasing these capabilities by several orders of magnitude can we truly support meaningful use cases in the real world and migrate existing Web2 applications to Web3.

That’s the goal of this new design, JAM, which is a blueprint designed to handle transaction data at a global level.

When will JAM be available?

Raoul Pal: When will JAM be released? I know this is usually a difficult question to answer, but what is your implementation strategy in mind? How long will this process take?

Gavin: It's always hard to tell. For example, I reserved a Tesla Roadster in October 2017. I saw it and I reserved it immediately. I thought "take my money, it will be delivered in two years!" However, six years later, I heard nothing. I thought I would get the car before Polkadot was released, but obviously I was wrong. Now, I hope to get the Tesla before JAM is released, but who knows.

I was actually setting goals roughly based on the Ethereum timeline. I published the Ethereum yellow paper about 10 years ago, and it took about six or seven months from then until the Ethereum protocol was finalized and released. The Ethereum protocol was audited and modified slightly, and then it was finally released in the summer of 2015, which was probably July or August. So, I thought we could try to set the JAM release target on a similar timeline.

At present, the main part of the Jam protocol is almost complete. I am now working on some additional content that needs to be added to the gray paper, which is expected to be completed in the next week or two. Next is the community review, research team review, prototyping, and audit process. However, I think the big problems about JAM have been basically solved.

How to compete for users?

Raoul Pal: Once JAM is released, the main challenge facing blockchain will be how to expand user adoption. How do you plan to address this issue? Because there are many blockchain projects currently competing for user attention and even using paid methods to increase on-chain activity. How do you deal with this challenge, because it is not just about expanding technology, but also expanding at the business level.

Gavin: My basic view is that the current blockchain does not provide high-quality decentralized block space to meet the needs of most real-world applications. Generally speaking, you need to pay high fees or even buy ETH on exchanges to use the Ethereum network. I know they are working hard to change this situation with some new infrastructure, but the reality is that this is not going to change much in the short term. One of the main reasons is that it is not scalable enough and block space is not cheap enough.

Block space needs to be almost free, and scalability needs to be so high that you can run programs that are almost like normal computer code on the chain. And JAM is designed to achieve this. The goal of JAM is to allow you to run almost normal computer code directly, not smart contracts, without complex gas optimization, and at a very low cost, you can upload code and run it, which will attract users. Therefore, the focus of JAM is to promote the realization of this vision.

How do networks accumulate value?

Raoul Pal: So it's like the evolution of cloud computing, where everything digital eventually becomes almost cost-free over time. Cloud computing is a good example, it used to be expensive, but now it's very cheap unless you use it at scale. However, if everything becomes close to zero cost, how does value accrue in the ecosystem? Unless you have a large number of transactions, like AWS does in cloud computing. How do you think about this?

Gavin: My view is that as the cost of block space approaches zero, new applications and markets will open up. Applications that were previously unreasonable now become reasonable because the transaction cost is almost zero. Of course, my goal is to get to a stage where you no longer need to buy cryptocurrency on an exchange to conduct blockchain transactions. Currently, basically any operation on the blockchain requires cryptocurrency first, which greatly limits the expansion of markets and use cases. I hope to get rid of this limitation eventually, but to achieve this, we need to greatly improve scalability, and JAM is the first step towards this great scalability.

I think once Web3 becomes a legitimate alternative to Web2, enough of a market will open up that even with blockspace cost approaching zero, there will still be enough value to pay validators to maintain the network. Therefore, the ultimate scale will ensure that the network's blockspace is valuable enough to support the entire ecosystem.

How many new people can enter this field?

Raoul Pal: One of the things I've been thinking about is that when we look at the expansion of all infrastructure layer technologies, like 3G, fiber, and so on, there will eventually be a lot of excess capacity at some point, and then there will be consolidation, and then the industry will find a clear direction to move forward. How do you see this happening in the blockchain space? Because there are a lot of problems that we haven't solved yet, and blockchain is not a perfect system that can solve all problems. When do you think we will reach that stage of excess capacity?

Gavin: I think we may be in a situation similar to the energy industry, and I'm not sure we really have excess capacity for energy. It seems to me that humanity is still struggling for energy. It's easy to make low-quality block space, such as setting up an isolated, insecure private chain, and you get it immediately. But it's not that simple to build high-quality, well-connected block space.

Raoul Pal: I'm also thinking about the ability of new entrants to enter the space, not that we will have a surplus of block space. I agree with you that the cheaper and faster the block space, the more use cases there will be, and eventually the entire Internet will rely on it. So no problem at that point. But the key is, how much more innovation or new people can enter the space? Or does this stop at some point, such as new projects can no longer be funded?

Gavin: I mean, if block space is cheap enough, close to zero cost, then the question is no longer about barriers to entry and use cases, but about whether they are actually useful, whether there are users and a market. If there is a market, just like building a website and using AWS to run the server, if the cost of running the server is low enough, such as you can easily serve the first hundred users, and users are very eager to use your new service, then even if the energy problem still exists, or AWS becomes very expensive when serving hundreds of millions of users, it doesn't matter, because the market is there and users are willing to pay.

So I don't think new entrants will have too much trouble with application scenarios and use cases, as long as there are no similar restrictions. Of course, one problem with the Polkadot 1.0 model is that there are currently 50 parachain slots, and these slots are limited. Once the 50 slots are full, no matter how good your use case is, you can only wait for the next slot, or participate in Crowdloan to fight for the slot, which is a difficult process. This is a lesson we learned from Polkadot - the barrier to entry needs to be lowered, not only for new applications, but also for new users. This is exactly the problem we are trying to solve with JAM.