Author: PolkaWorld

Gavin Wood, co-founder of Ethereum, creator of Polkadot, and proponent of the Web3 vision.

Before we officially begin, let's share some of Gavin's quotes in this section!

What is Ethereum's biggest achievement to date? — Maybe it’s CryptoKitties, I don’t know, I’m actually not sure. I’ve heard that Ethereum created the most millionaires in history.

Is Ethereum a successful project? — What about according to my standards of success? Clearly, not all standards are met, and it may only be a small part that fits. Of course, it is financially successful.

With the introduction of JAM, the direction of Polkadot has changed. It can be viewed as a natively designed Rollup hosting chain, and the technology we develop far surpasses optimistic Rollups and zero-knowledge Rollups on Ethereum.

What is Polkadot's biggest achievement so far? — Achieving a secure sharded blockchain.

What is the biggest challenge facing Polkadot today? — It's sharding.

How to solve these issues? — JAM

Keep reading to see the full content!

What is Ethereum's biggest achievement to date?

Kevin: So you say you co-founded Ethereum in 2014? Why did you join them as a co-founder and CTO?

Gavin: I felt it was a rare opportunity, and I immediately realized I should seize it and devote myself fully to it. Perhaps not necessarily for a lifetime, but at least to pour all my energy into it for a while. It was an innovative project that emerged at the right time, with some exceptionally capable and focused individuals on the team, as well as a small but eager market willing to experiment with new things. To be honest, I was very curious about the project; I felt it had great potential to go far and contribute to the principles of enlightened liberalism as I understood them.

Kevin: What are those?

Gavin: Essentially, it's an optimistic view of society and development, which probably developed in the West about four or five hundred years ago.

Kevin: What is Ethereum's biggest achievement to date?

Gavin: Maybe it's CryptoKitties, I don't know, I'm actually not sure. I've heard that Ethereum created the most millionaires in history. Perhaps this is due to the large number of people participating in the crowdfunding, and the price later rose high enough. So maybe this is its biggest contribution. But to be honest, it's hard to say how much useful stuff it has really achieved. It certainly hasn’t met my expectations of it from ten years ago.

Kevin: So if I ask you whether you think Ethereum is a successful project, is your answer no?

Gavin: My answer is, do I personally think it's successful? What about according to my standards of success? Clearly, not all standards are met, and it may only be a small part that fits. Of course, it is financially successful. I think maybe one or two of the Ethereum founders might have originally expected it to perform better.

Kevin: What standards would make you consider it successful?

Gavin: Utility

Kevin: How do you measure utility?

Gavin: The way to measure utility is to look at how many things people can now do that they couldn't do before.

Kevin: Is this a problem for the entire crypto industry, not just Ethereum?

Gavin: Indeed. This is indeed a problem faced by the entire crypto industry. Back in 2014 and 2015, we proposed many ideas trying to unlock some economic areas that were previously untouchable through 'trustless' means. One example I particularly liked was supply chains. For instance, when you go to the supermarket, every product has a QR code that you can scan to understand all of its components: when, where, and how much, etc. I would like to know where the cotton in a T-shirt comes from.

Currently, it's very difficult to achieve this in a centralized model, and the costs are high. But with a decentralized approach, I think it's possible. However, such applications have not really been deployed. While there are some crypto projects related to supply chains, they are very niche and limited to specific market segments. It hasn't delivered on the promise in this direction.

Moreover, this is not just a supply chain issue; I think the imagination in the crypto industry is rich, but it’s difficult to translate those imaginations into real actions and actual market applications, which is indeed regrettable. I believe the main reason is not a technical issue, even though the technology is indeed lagging behind our concepts, especially the underlying technology needs significant improvements. This is also why I am now working on JAM, trying to improve the underlying technology to support the ideas I think are valuable and help the crypto industry play a bigger role.

But merely improving the technology is not enough. You also need to make people understand its value. And that’s difficult, partly because you are fighting against the attention economy.

Why leave Ethereum?

Kevin: Why did you leave Ethereum in 2016?

Gavin: Actually, it was at the end of 2015. At that time, we decided that Ethereum needed to do many things to be more widely adopted. We were looking for external investment, and one of the most obvious ways was to establish a startup related to Ethereum and seek external funding for it. This was initially a decision made by Vitalik and Jeff (core developer and engineer).

Later, Jeff didn’t adapt well to startup life. In fact, he soon left Ethereum to pursue his video game career. As a result, only Vitalik remained. Vitalik felt it was necessary to continue at the Ethereum Foundation and take on a more academic role, while also acting as an advisor to Ethcore, the branch company we had established at that time.

We raised some funds at the time, bringing about half of the Ethereum Foundation's technical team to Ethcore, where we developed an Ethereum client. I left the Ethereum Foundation at the end of 2015, actually to establish this branch company, aiming to add an entity supported by private funding within the Ethereum ecosystem.

However, I fully left the Ethereum ecosystem at the end of 2017 when I founded Polkadot.

Polkadot is developing a Rollup technology

Kevin: If you had to explain what Polkadot is to your mom, how would you say it?

Gavin: Well... Polkadot has undergone some changes over the years. The original vision was to integrate different blockchain architectures together, allowing them to be compatible with each other and share the same security framework. By sharing such a security framework, significant economic benefits can be realized. For example, if designed properly, you can protect 100 chains simultaneously at the same cost, rather than requiring each chain to be independently secured like in other designs (e.g., Cosmos).

Over the years, Polkadot has tried to differentiate itself from Cosmos in this aspect. Because in the Cosmos model, each chain needs to bear its own security. Polkadot addresses this issue through shared security. But unfortunately, the two actually solve very different problems. In hindsight, I might lean more towards describing Polkadot as a 'sharding system' rather than a 'multi-chain system.' Looking back, this description is very crucial in explaining and communicating Polkadot's core concept. Especially when communicating with others or promoting Polkadot, this distinction helps to describe its technical characteristics more clearly and differentiate it from other projects (like Cosmos).

Now, with the introduction of JAM, this direction has changed somewhat. The technology we develop for Polkadot can be seen as a Rollup technology, and Polkadot itself can be considered a purpose-built Rollup hosting chain. The development and design of this technology is not simple, so it is not surprising that we see other two competing technologies falling far short of the technology we are developing for Polkadot. Specifically, these are optimistic Rollups and zero-knowledge Rollups, both of which are being used on Ethereum. Therefore, we can describe Polkadot as a natively designed Rollup hosting chain — of course, this description may not be suitable for explaining to mom, but it works for those with some understanding of the crypto field.

Through JAM, which is Polkadot's next developmental goal, we are trying to shift Polkadot from a multi-chain model to a more general computational resource model. In the multi-chain model, the different chains of Polkadot (called parachains in the Polkadot system) share the same security framework and can interact with each other. In the new model, our goal is to further expand the applicability of Polkadot, just as Ethereum expanded the basic functionality of Bitcoin into a general computational resource. We hope to remove excessive subjective design constraints to allow Polkadot to support a wider range of use cases.

So what is the future of Polkadot? Fundamentally, it will become a large shared computer that always operates in the way you expect. On this shared computer, you can upload programs to run, and these programs can be services that solve specific problems. Because this is a shared computer, these services can collaborate and coordinate with each other.

The key is that this is a single large shared computer. What we don’t want to do is to split it into different parts that cannot truly interact with each other.

Polkadot's biggest achievement so far is also its biggest problem.

Kevin: I think you might be referring to a fact that has actually caused a lot of confusion in today's Ethereum ecosystem. So, what is Polkadot's biggest achievement so far?

Gavin: Achieving a secure sharded blockchain.

Kevin: What is the biggest challenge facing Polkadot today?

Gavin: It’s sharding.

Kevin: What does that specifically mean?

Gavin: Sharding has long been seen as the 'holy grail' of blockchain scalability, and its concept comes from database design. In a database, you can split a database (essentially a set of records) into multiple shards. Each shard operates independently, and can only interact with other shards under very clear interfaces, such as a record possibly moving from one shard to another.

A simple physical example can help illustrate. Imagine an office from the 1960s, like a doctor's clinic, where patient medical records are stored. These records are usually kept in old-fashioned drawers. If there are only 20 records, one drawer may suffice, and it’s easy to organize them alphabetically. But if the records exceed the capacity of one drawer, such as having more people, you need to spread the records across multiple drawers. If the number of drawers keeps increasing, say to four or five, then you also need multiple filing cabinets.

Each drawer in a filing cabinet can be seen as a shard. They operate independently: you can open one drawer without having to open the others, and you can search within one drawer without checking all the drawers. This contrasts with having only one very long drawer (like a 10-meter-long drawer). If there is only one long drawer, it is obviously impractical, as you need a 10-meter-long room to accommodate it. And when you are looking for a name that starts with 'W,' you might have to pull out the entire drawer and walk down to the 'W' position, which is clearly inefficient.

Thus, from this perspective, the design of sharding makes sense. However, it also brings problems. For example, what if one drawer gets full? You might need to readjust the allocation of records, such as changing the original A to E records to A to D, and moving the E-starting records to the next drawer. But this might lead to the next drawer also being filled, necessitating further adjustments, and each adjustment requires changing the labels outside the drawers. This whole process can become complex and troublesome.

So, sharding brings its own set of problems.

The core issue is that these 'drawers' (shards) operate independently, whether in sharded blockchain design or database design. Essentially, once the data is split, it remains in a sharded state unless you perform a very special operation, which is usually very time-consuming, costly, and resource-intensive to move records or data from one drawer (shard) to another. This means that reorganizing records within a single drawer might be easy, but reorganizing records across different drawers is very difficult. This is precisely the problem with sharding. For data, this issue may not be severe, which is why sharding is widely adopted in database design. But for services, such as smart contracts that require frequent interaction and changes, this approach is not ideal. If smart contracts are viewed as objects placed in drawers, and you want a smart contract in one drawer to interact with a smart contract in another drawer, you need to open both drawers at the same time. This means you need to pull out both drawers, connect them together to perform all the interaction operations needed by the smart contracts, and then separate them and put them back in their respective drawers. This process is complex and inefficient, making it very unsuitable for applications that require frequent interaction.

If you are only operating between two drawers, it’s already challenging, but if you want multiple drawers to interact simultaneously, it becomes very complex and difficult. One problem with doing this is that you obstruct free interaction between the drawers, which means that other smart contracts in the drawers can only follow this single interaction model. The entire system can quickly become complex, difficult, and inefficient.

Another approach is to have the drawers communicate by sending messages. One drawer (shard) can publish a message, and later this message will be delivered to another drawer. This is exactly what Polkadot does using XCM (Cross-Consensus Messaging). While this method can be used, the problem is that it can't achieve that close, efficient, and flexible interaction, far less smooth than when everything operates in the same space or 'playground.'

For example, imagine a school with four different playgrounds, corresponding to four different blockchains. If you play 'hide and seek' in one playground, that's perfectly fine; the game can proceed smoothly. But if you want to play 'hide and seek' across two playgrounds, it becomes very challenging. You need to send a message to the other playground, like 'I am the seeker now, if you enter this area, I will catch you.' And the players in the other playground need to know this but cannot fully understand, causing the game to quickly become chaotic.

So, hide and seek is a game that can only be played within the same playground. This is precisely the problem with interactions between shards; cross-shard interactions are like trying to play games across playgrounds, making it difficult to proceed efficiently.

If certain solutions must operate in a very asynchronous manner, it becomes very challenging to make them work properly. Just like trying to play a game only through messages. If it’s a game like chess, it may not be too difficult; but if it’s a game like hide and seek, it’s basically impossible.

The same situation exists with smart contracts. Some smart contracts may not be too difficult to operate in this model, perhaps just a bit slower than normal, but not a big issue. And some application scenarios, like identity verification (KYC), are relatively simple. For example, you might have one chain dedicated to identity verification, while another chain handles transfers. The transfer chain may need to confirm whether the target address has passed KYC and AML verification before executing the transfer. It can send a message asking, 'Has this address passed KYC and AML verification?' The identity verification chain replies, 'Yes,' and then the transfer chain executes the transfer. The whole process may take a few extra seconds, but that's not a big deal.

However, there are other use cases, such as decentralized exchanges (DEX), that are much more complex. For example, you need to inquire about the current price and then decide whether to trade. At that point, you may need to send a message to another chain, and that chain replies, 'The current price is this, and the trade can be done like this.' Then the message returns to the original chain, which confirms, 'I accept this price, please execute the trade.' But just as the trade is about to be executed, the other chain might say, 'The price has changed, now it’s this price.' The messages will bounce back and forth quickly, making the whole process very inefficient, even impossible to complete effectively.

So, in such cases, the trade must be completed almost simultaneously, or it cannot proceed. This phenomenon is akin to playing games in a playground. Certain games, like hide and seek, can only be completed within the same space; asynchronous interactions will make the game completely unplayable.

The solution is JAM.

Kevin: What feasible solutions are there?

Gavin: Well, JAM is my proposal, which stands for Join Accumulate Machine.

Kevin: What is JAM?

Gavin: JAM is a flexible way that can gather players from different 'playgrounds' to create a temporary playground where they can play hide and seek. Here’s an improvised example (which may be a bit crazy, sorry). Continuing with the hide-and-seek example: Suppose there are originally four fixed playgrounds; in the design of JAM, there are no longer such fixed playgrounds.

The playgrounds are no longer fixed, and players are no longer bound to a single playground, and the cost of moving between different playgrounds will not be so high. Instead, we have a vast play area where playgrounds can quickly form and disappear. In this case, we focus on the players in the game, temporarily gathering those players who are close to each other and may 'catch' one another into a temporary playground where they can continue playing hide and seek.

When some of these players run out of this temporary playground, we readjust the position of the playground, redefining the new playground area based on those players who are still close to each other. If some players are far apart, we know they won’t 'catch' each other in the short term, so they don’t need to be included in this playground. They will be temporarily 'out of the game' until they get closer to other players and need to participate when they are included in the new playground.

If we realize the system in this more flexible way, we can imagine a system that is both scalable and supports synchronous combinations. Its core is that it won’t permanently split the so-called 'state.' In other words, players won’t be permanently bound to a specific playground but will be dynamically grouped in real time as needed. The system will classify players into different groups based on actual needs and advance the game according to these groupings.

In the context of smart contracts, the realization of this concept is similar to placing all smart contracts in a large shared 'melting pot,' but this melting pot does not keep all contracts constantly interacting with each other, but can dynamically partition. For example, the system can extract 10, 50, or 2 smart contracts from this melting pot, combine them together, enable them to interact and run synchronously, and then separate them. Then reassess, pick another different set of smart contracts, combine them again, and then separate them.

This approach allows us to handle multiple parallel smart contract groups simultaneously, rather than only allowing one smart contract group to perform synchronous combinations and runs. Through this parallel processing method, we can significantly increase the system's interaction processing capacity, supporting hundreds of times more interactions than traditional methods, thus achieving true scalability.

#ETH