Solidity on Polkadot Course: Revealing the Future Direction of the Chinese Developer Ecosystem

Recently, we collaborated with a training institution to launch a course titled "Solidity on Polkadot." Initially, we only wanted to test developers' interest in the PolkaVM toolchain, but the results were unexpected: a total of 219 people signed up, and the homework completion rate was nearly 38%.

These data are certainly satisfying, but what is even more thought-provoking is that through this course, we unexpectedly gained insight into the future development trends of the Polkadot Chinese developer ecosystem.

This article will delve into the feedback and issues of these real users, while sharing how we gradually built a roadmap towards "ecological construction" from an attempt at a brand new course.

Course Background: Seeking Truth, Not Chasing Trends

Polkadot is advancing its 2.0 upgrade, with the core objectives of achieving cross-chain unification, lowering barriers to entry, and enhancing the developer experience. As an Ethereum-compatible execution environment, PolkaVM is likely to become the preferred entry point for Web2 or EVM developers to engage with the Polkadot ecosystem. However, we must confront a reality: in the Web3 world, technical narratives often become mere surface decorations. The number of those truly willing to engage in practice is often just a minority. Many people’s impressions of Polkadot still linger on aspects like "complex", "difficult to understand", and "high development barriers", let alone attempting to write contracts or deploy DApps.

Therefore, we offer this course not only for promotional purposes, but more importantly, we hope to answer the following key questions through practice:

1. What aspects are developers most concerned about in the new VM environment?
2. Is PolkaVM an opportunity or a challenge for them?
3. Can the existing toolchain support real project development, rather than being limited to demonstration use cases?
4. Which stage of the developer journey is most likely to encounter issues?

The design intention of this course is not to serve as an advanced technical lecture for experienced developers, but rather as a practical hands-on experiment for beginners. We hope to be "guides for newcomers," accompanying them through their first round of development processes and observing the various situations that may arise throughout.

Four Unexpected Discoveries

1. Learners demonstrate strong curiosity and time investment

We originally thought that most people participated in the course to earn rewards or certificates, but that is not the case. 80% of the participants are post-90s, a quarter are students, and most dedicate 1-2 hours a day to self-study. This level of commitment far exceeds merely completing tasks, demonstrating their sincere attitude towards learning.

Some students learn from beginning to end just to deploy a contract by themselves; others say: "At least I can write on my resume that I have successfully deployed a DApp in the PolkaVM environment." In reality, they may not necessarily care about how strong Polkadot's technical capabilities are; what they need more is a friendly environment to validate whether they are suitable for entering the Web3 space.

2. Having rich experience does not equate to being easy to get started; the biggest challenge lies in the shift of cognitive patterns.

Many participants have rich development experience and even practical experience with EVM projects, but after entering the Polkadot ecosystem, they are still troubled by some terminology differences: What is PolkaVM? Is AssetHub a chain or a module? Why is the gas limit different from Ethereum? The contract was successfully deployed, so why did the front-end call fail?

The problem they face is not the difficulty in understanding the code, but rather that the existing cognitive model suddenly becomes invalid, requiring them to relearn a series of concepts, which can easily lead to psychological resistance.

Our course alleviates this cognitive gap to some extent, making participants realize that the development experience of PolkaVM is not complicated; it is just that the concepts and terminology are different. This is crucial because many people give up on an ecosystem not because they cannot write code, but because they feel confused when first encountering the documentation.

This reminds us: development documentation should not just pile up knowledge points, but also help users complete the conversion of their cognitive patterns. In the future, we plan to add a comparison of the key differences between PolkaVM and other mainstream VMs (such as EVM) in the documentation, helping more people reduce detours and increase the "I see" moments.

3. Course participants are not only learners but also potential ecological contributors.

Although most participants are new to contract development, they are brave enough to ask questions, report bugs, and actively test the technical boundaries. For example, someone pointed out that there was no issue with the Remix compilation, but there was a failure in on-chain deployment. This feedback directly prompted us to submit multiple toolchain-related issues to the development team, driving the improvement of documentation and bug fixes.

As experienced developer relations personnel, we may have habitually avoided certain common issues, and many "false alarms" have become second nature. However, newcomers do not have this experience. They have not yet established a complete judgment system, making it easier for them to identify potential problems—this precisely makes the course a valuable problem collector. For participants, the course is a buffer; for us, these real user experiences are the most intuitive indicators for assessing the PolkaVM ecosystem.

4. The key factor in deciding whether developers continue to participate lies in the overall process experience.

Many people leave not because they "can't learn", but because they "encounter mistakes but can't find solutions".

The same code shows errors in different environments; Hardhat, Foundry, and Remix perform inconsistently in their respective environments; issues such as the inability to find the required information in the documentation and unclear error messages may lead developers to give up trying.

We recognize that Developer Experience (DevEx) is not limited to the smoothness of the coding process, but encompasses the entire flow from environment setup, issue feedback to deployment results, and even future upgrades, whether it is smooth and reliable. Any problem in any link may cause developers to lose confidence. Therefore, this is not just a technical issue, but also a design challenge in managing emotions and trust.

Courses as a bridge between tools, users, and expectations

In the early stages of the ecosystem, we realized that the significance of developer courses goes far beyond one-way knowledge transfer, and we do not expect to uncover the next Web3 entrepreneurial star through a single course. Instead, this course achieved three important outcomes:

1. Network Stress Test The Uniswap V2 contract migration exercise conducted in the course, which was originally just a routine operation, unexpectedly revealed a series of issues: gas discrepancies, path bugs, inconsistencies between Remix and Hardhat, etc.

These issues are obstacles for developers, but for us, they are valuable "early warnings". It is very important to identify these issues as early as possible. Now, these issues have been added to the development team's to-do list and are being addressed promptly.

2. User profiling and conversion clue analysis Some people focus on architecture design, some pursue development efficiency, and others ask: "Are the tools I commonly use directly available in the PolkaVM environment?"

Each question reflects the real considerations of the developers, while also revealing the areas where the "PolkaVM User Guide" needs improvement.

3. Establish Product Expectations Our courses can be likened to a series of live demonstrations, showcasing the practicality and value of PolkaVM through hands-on operations rather than verbal promotions. Even if certain features are not yet perfect, as long as there are people using it and others willing to wait, it is a positive signal for the development of the ecosystem.

In the past, there were doubts about Polkadot's lack of user base - this statement is not accurate. Historically, the main users of Polkadot have been teams building underlying infrastructure, rather than DApp developers. With the launch of PolkaVM, contract developers finally have a stage to showcase their talents. Of course, when faced with such a novel VM environment, hesitation is inevitable: "With such a new VM, do I dare to be one of the first testers?", "Is it worth my time to invest in a network that is still in the testing phase?" But it is precisely because it is new that it provides small teams with the opportunity to leapfrog.

In this course, we successfully migrated Uniswap V2 to the PolkaVM environment, sparking extensive discussion within the community. This is not because Uniswap is something novel, but because people are seeing it run in the Polkadot ecosystem for the first time. Although Polkadot has been around for many years, it remains a high market cap ecosystem with a wealth of funded projects and a large number of significant investors holding DOT. Instead of fiercely competing in the Layer 2 space, why not explore a blue ocean market that has yet to be fully developed?

We are preparing the content for the next course. If you are interested in a specific module or project practice, feel free to let us know in the comments.