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

Recently, we collaborated with an educational platform to launch the "Solidity on Polkadot" course, originally intended to explore the popularity of the PolkaVM development toolchain. The results were surprising, with a total of 219 participants signing up, and the homework completion rate nearing 38%. This data is not only encouraging but, more importantly, we unexpectedly gained insights into the future development trends of the Polkadot Chinese developer ecosystem from this course.

This article will share our observations and reflections from this new course, as well as how to explore a roadmap towards "ecological construction."

Course Background: Explore Real Needs, Not Just Follow Trends

Polkadot is advancing its 2.0 upgrade, with core goals including cross-chain unification, lowering barriers, and enhancing developer experience. PolkaVM, as an Ethereum-compatible execution environment, is likely to become the entry point for Web2 or EVM developers to engage with Polkadot. However, we must face a reality: in the Web3 world, technical narratives often reduce to mere surface decoration. The truly willing practitioners are often a minority. Many people's impressions of Polkadot still linger at the stage of "complex", "difficult to understand", and "high development barriers", not to mention trying to write contracts or deploy applications.

We offer this course not only for publicity but, more importantly, to explore the following questions:

1. What are developers most concerned about in the new virtual machine environment?
2. Is PolkaVM an opportunity or a barrier for them?
3. Can the toolchain support the development of real projects, rather than just demonstrations?
4. In the entire development process, which stage is the most likely to encounter problems?

Therefore, this course is not a deep technical lecture aimed at experts, but rather a real developer experience experiment. We hope to be a guide for beginners, accompanying them through their first attempt and observing the various situations that may arise during the process.

Four Unexpected Discoveries

1. Learners demonstrate a strong curiosity and engagement.

We originally thought that most people participated in the course to obtain rewards or certificates, but that is not the case. 80% of the participants are post-90s, a quarter are students, and most people voluntarily invest 1-2 hours per day in learning. This intensity of study indicates that they are not just trying to get by in the course, but genuinely want to try and master the relevant skills.

Some learners study from start to finish just to personally deploy a contract; others say: "At least I can put 'successfully deployed applications in the PolkaVM environment' on my resume." This reflects that they may not necessarily care about how strong Polkadot's technical capabilities are, but rather need a friendly environment to validate whether they are suitable for entering the Web3 field.

2. Being experienced does not equal being easy to handle; the biggest challenge lies in changing the mindset.

Many participants have extensive development experience and even practical experience with EVM projects. However, when they enter 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 deployed successfully, but the front end cannot call it?

Their confusion does not stem from not understanding the code, but rather from the sudden failure of familiar cognitive models. Faced with a bunch of concepts that need to be re-understood, many people directly developed a withdrawal mentality.

Our course alleviates this cognitive gap to some extent, at least making participants aware that the development experience of PolkaVM is actually not complex; it mainly differs in terminology and practices. This is crucial because many people abandon an ecosystem not because they cannot program, but because they give up after not understanding the documentation at first glance.

This also reminds us that development documentation should not just be a pile of knowledge but should also help users complete cognitive transitions. In the future, we plan to add key comparisons between PolkaVM and other mainstream virtual machines (such as EVM) in the documentation to help more people reduce detours and increase "I see" moments.

3. Course participants are not only learners but also "invisible contributors".

Although most participants are beginners in contract development, they are brave enough to ask questions, eager to report bugs, and willing to test the boundaries of technology. For example, someone pointed out that there were no issues with the Remix compilation, but there were failures in on-chain deployment. This feedback directly led us to submit multiple toolchain issues to the relevant teams, facilitating documentation additions and bug fixes.

As an experienced developer relations team, we have become accustomed to bypassing some minor pitfalls, and many "error warnings" have become second nature. But newcomers don't. They have not yet developed this judgment system, making them more likely to encounter problems—this, in turn, makes the course a very valuable problem collector. For participants, the course serves as a buffer zone; for us, these "real pitfall" experiences are the most intuitive thermometer of the PolkaVM ecosystem experience.

4. The key to determining whether developers will "revisit" lies in the overall process experience.

Many people leave not because they "can't learn," but because "when they encounter mistakes, there's no one to guide them on how to solve them."

The same code may produce errors in different environments; the results of Hardhat, Foundry, and Remix may be inconsistent in their respective environments; the required information cannot be found in the documentation, and error messages do not directly display results, all of which may lead developers to give up in frustration.

We realize that developer experience (DevEx) is not just about the smoothness of the coding process, but about the entire process from environment setup, issue feedback, to deployment results, and even future upgrades being smooth and reliable. If there is a problem in any part of the process, it can easily lead to developers losing patience. Therefore, this is not only a technical issue but also a design issue regarding emotions and trust.

Courses as a bridge between tools, users, and expectations

In the early stages of ecological development, we realized that the significance of the developer courses is not just a one-way transfer of knowledge, nor is it an expectation to discover the next Web3 entrepreneurial star through a single course. Instead, we achieved three valuable outcomes through the courses:

1. Chain Pressure Test

For example, when we were practicing the Uniswap V2 contract migration in the course, we thought it was just an ordinary exercise, but unexpectedly discovered a series of issues: gas errors, path bugs, and inconsistencies between Remix and Hardhat.

These issues are obstacles for developers, but for us, they are "early symptoms"; the sooner they are discovered, the better. Now, these issues have been transformed into a checklist of pending items for the relevant teams and have been addressed quickly.

2. User Profiles and Conversion Leads

Some people focus on architectural design, some pursue development efficiency, and others ask: "Can the tools I commonly use be directly used on PolkaVM?"

Each question reflects the real considerations of developers, while also revealing how the "user manual" for PolkaVM needs to be improved.

3. Establish product expectations

Our course is somewhat like a multi-episode series presentation, not relying on empty talk, but demonstrating the actual usage experience and value of PolkaVM through live demonstrations. Even if certain features are not yet perfect, as long as there are people using it and willing to wait, it is a positive signal for the development of the ecosystem.

In the past, there have often been criticisms that Polkadot lacks users—does no one really use it? In fact, it has primarily been used by infrastructure development teams rather than application developers. Now that PolkaVM is live, developers writing smart contracts finally have a stage to showcase their work. Of course, hesitation is inevitable: "With such a new virtual machine environment, should I dare to be among the first to try it?", "The network is still in the testing phase, is it worth my time to invest?" But precisely because it is new, it provides small teams with the opportunity to overtake in a curve.

In this course, we will migrate Uniswap V2 to PolkaVM, which has attracted widespread attention from the community. This is not because people have never seen Uniswap, but because it is the first time to see it running in the Polkadot ecosystem. Although Polkadot has developed for many years, it is still a high market value ecosystem with a rich funding program, and there are quite a few large holders of DOT. Instead of fiercely competing in the Layer2 field, why not explore an undeveloped blue ocean market?

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