Following Decoded 2024 in Brussels, and after several discussions in the past weeks, we’ve heard voices in the community requesting Decentralized Applications (DApps) education, so at this point we are exploring, potentially creating more DApps related content, in the upcoming cohorts of Polkadot Blockchain Academy.
As we are researching this aspect, we believe it is essential to collaborate closely with the community and to ensure that we will receive your insights, suggestions and opinions on what this program should encompass.
From the essential tools and frameworks to the latest industry trends and practical hands-on projects, your input will help us consider a comprehensive and impactful learning journey for future developers, based on the current needs of Polkadot.
We want to invite you, to share your ideas on the key components, learning outcomes, and resources that would make this DApps track program truly exceptional. Whether you have thoughts on specific modules, innovative teaching methods, or the latest tools and technologies, your feedback will be instrumental in shaping the decision and the next steps that we are willing to take.
Thank you in advance for your support and feedback
Perhaps ZKPs would be a good addition. Only a little in covered in cryptography, but it is big enough to be a separate module. Maybe an optional module of sorts for people who are interested. ZKPs and how to integrate them with a Substrate chain.
Thank you all for the - so far - feedback.
It feels that there is a misunderstanding of what I meant by saying “Dapp content” so I will try in a few sentences to explain what we have in mind.
In just a few words - what we thinking is not to teach the students how to write in React, or associate types, or how to execute specific actions (XCM with PAPI/polkadotJS).
The idea of a Dapp is an application which is fully decentralized and what is the process to build that, test and deploy etc etc - what are the missing pieces and how we can make the connection between frontend/tooling → backend. Of course it has its front end AND backend (on-chain) parts, but some of the latter is already been taught during Polkadot-SDK (Substrate/Frame/XCM) module.
A good example of teaching material could be to teach extensively processes that are almost standarized in the ecosystem on testing tools (Chopstics/Zombienet).
Another example is to introduce existing tooling (PAPI, PolkadotJS, SubXT) and how these tools can be used, or dive deeper on explanations on when a smart contract should be used or when is the good time to build a parachain.
Just a few sentences to bring as on the same page.
The idea that a frontend can solely rely on an on-chain backend (smart contracts or pallets) is an oversimplification that might apply for very niche cases. Look at Uniswap or any successful dApp for reference, all of them require a lot of off-chain data processing.
Something that could be helpful for students is identifying which parts of a real-world app need on-chain access (and the degree of decentralization) and which parts can be done off-chain. Blockchain provides essential features but can’t handle all backend needs because of its own nature.
I heard some strong feedback when I was at Polkadot Decoded about the PBA. Obviously, everyone loves the program, but they are also concerned we are not focused on the primary problems of Polkadot today.
The feedback I heard from others was:
“If I could wave a magic wand, I would have the PBA focus now on Polkadot application development rather than Polkadot/Parachain core development.”
It seems that Polkadot application development (mobile, web, contracts, etc.) offers greater opportunities for:
Hiring students into jobs after the academy.
Students to start new successful teams in the ecosystem.
When we think about what Polkadot needs the most, it is probably NOT another Parachain. We need way more beautiful end-to-end user experiences and onboarding stories for users into our ecosystem.
When we started the PBA, there was a huge need for Core Developers and Runtime Engineers within Parity and the various Parachain ecosystems.
Over these last 2 years, the PBA successfully taught 400+ students and placed 200+ of those students into roles in our ecosystem. We have likely satisfied the core developer need, but actually created an even bigger need in the next natural step of the product development cycle: Applications.
Fortunately, application development is likely a much easier topic to cover than core development given the vast amount of existing content and experience, but I think it might be a mistake not to treat it as a first-class citizen and high-priority need. I hope we can look at an application development course like we did when we first started the academy.
What we need:
We need a revamped and high-quality focus on Smart Contracts to bootstrap the Plaza vision.
We need a similarly in-depth look into mobile development.
We need a similarly in-depth look into web development, establishing PAPI as the future development library for Polkadot.
Perhaps something more commercially related, such as what type of dApps and protocols are necessary for the coming years in the Polkadot ecosystem, analyzing success stories, so new developers and founders already have clarity on how they can contribute to the ecosystem from their experiences.
Based on the last (5) cohort, some thoughts that I have:
The Smart Contracts Module can be made longer and better. To keep the timeline in check, either one of the things can be done:
Offer smaller tracks within the developer track to either go deeper into the core/runtime stuff or the dApp way.
Reduce the time spent on XCM (and maybe even Cryptography).
More content can be pushed as a pre-requisite to be completed before coming to the Academy asynchronously. Things that are already established and more readily available/easier to grasp.
For me the number one learning outcome has to be a mindset shift in how people present blockchain-based applications and it needs to be away from chains. Every Polkadot-based app that I have tried makes no effort to abstract away the underlying chain architecture (and in fact, they often try to highlight it). This really needs to change.
I think part of the problem is that we pushed “parachains” as the main “product” of Polkadot, but perhaps failed to tell the whole story. Yes, parachains are the main product for developers who want to build complex/upgradeable protocols that are difficult/impractical (technically or economically) to express in smart contracts, but that doesn’t mean these should be exposed to end-users at the application level.
Much like a Web2 app might use EC2 for compute, S3 for blob file storage, a relational database, an account/identity management service, and many more components, end users don’t see any of this. Parachains should be thought of as analogous to these components.
The great part of Web3 is that users can look under the hood and verify how things are working. But applications should not force them to.
I am certain that Polkadot is missing some APIs and tools to make this possible, but I’d rather see people trying to build with this mindset and exposing demand for these APIs/tools rather than continuing down this “show parachains to the user” approach. Polkadot was designed with shared security precisely so that users need not worry about which chain they are on, so it’s little wonder that Polkadot has “bad UX” when applications present that to them.
Thank you, @wirednkod , for starting this discussion post.
I think what Polkadot needs today are many more end-user applications to onboard users into the ecosystem. In both Hong Kong and Singapore, I remember devs mentioning that they wanted to learn more about building dApps / write smart contracts. I think having a more extensive smart contracts module, along with more dApp development content at future PBA cohorts would be a good idea.
I think that it would be more appropriate to give feedbacks on the issues you face or get the users themselves to push their problems. Rather than us, as a sub community deciding what we hear say or think should be done.
As an engineer and a recent graduate, i think indeed frontier could have been covered, As they would be more relevant in today’s market.
But i disagree to the point that “I would have the PBA focus now on Polkadot application development rather than Polkadot/Parachain core development.” I do not think these crowds would have understood the course and especially how powerful the Development Tools around Parachain could be. I love the contents as they are rn, frontier or an EVM compatible hands on would’ve been perfect. This cannot be blame as almost the entire industry is so much focussed on DeFi, that no one can see anything else.
I think the beauty that most lack to see is the real innovative capabilities built around Parachain Development Tools.
Not sure where this was mentioned - but my approch is defenitely not following this. As mentioned above, a decentralized application (Dapp) is one that is unstoppable, that no matter what will happen to any related components for the dApp to run - it will still be unstoppable (one of the main reasons why we need light clients more than ever is dApps).
Each dApp though can and shoul dhave off-chain parts that will process information, gather reports etc etc - but that should not be crucial for the application to run.
A good example could be a Swap app if EVERYTHING centralized and/or off-chain goes down, the decentralized nature of the app will still function:
everything that works in a decentralized manner (IPFS, blockchain etc: User will still be able to swap
No statistics will be saved in the app’s centralized database
No information would arrive concerning Fiat/blockchain exchange (external app)
etc etc…
This could be an interesting lecture - but we should be very careful not to be too opinionated.
This is an amazing write @shawntabrizi and thank you for the feedback.
I could not agree more - that when PBA started the needs of Polkadot ecosystem were different than what they are today. As, very correctly you mentioned:
and I can verify that the curriculum back then was designed around that need.
It is now 2 years later, and the needs have changed and they will keep changing and evolving. The next big step is Applications and thus this call for feedback.
Following the feedback from previous academies and looking at the upcoming next-steps of Polkadot (e.g. Plaza vision ) I agree with what you mention:
Smart contracts module should be heavily revamped and converted to an intro/helpful chapter of Dapps content and intro to “Plaza”. Along with it the rest of the existing tools should be introduced (PAPi as main dev library for dApps, mobile development, best practices etc etc).
I understand the dilema you placed:
But I am sure that there is more than enough space, and there should not be a choice between Applications or Parachains core dev. Both should co-exist and fit in the curriculum content.
I find these 2 quotes very aligned to my self-brainstorming around the content:
and
I could not agree more! So far an application is concentrated mainly into “presenting” a parachain or a functionality.
Maybe we need more opinionated applications that will serve information from multiple parachains without the need of knowing what comes from where.
In my opinion the user should not care at all “where” is located…
An application-on-steroids should allow the user to connect his wallet and have no need to switch between networks/parachains etc etc…
Should contain click-options that will combine information based on the action that user requests/needs etc etc.
Opinion of ecosystem and its needs, matter a lot and at this point we try to gather those. Placing a potential solution and “issues we face” is not the initial right way to go in my opinion. We need to hear the voice of the community and the ecosystem - understand the needs and then propose a solution.
I am not sure why you refer to this forum as a “sub-community”. I think this is THE community of Polkadot and all matters are and should be discussed in the forum.
In my opinion, it’s important to distinguish between decentralization and “unstoppability”.
“Unstoppability” exists at the protocol and network level, provided that the blockchain network is full byzantine, decentralized and big enough.
In contrast, IPFS does not guarantee content availability. Availability depends on nodes storing and sharing data, and if these nodes go offline or stop pinning content, the data can become inaccessible. Thus, IPFS is decentralized but not unstoppable.
Additionally, an app itself, even if uses decentralized systems and is offline-first, is not unstoppable. It needs to be installed on a host and can be lost or corrupted. While a light client can access an unstoppable blockchain, the client nodes are not unstoppable. “Unstoppability” is a property of the network and its protocols, not of the user-facing apps.
In any case, it is worth to make the end-user apps as resilient as possible or as needed.
Agreed. As educators it is more important to guide students in exploring and understanding the problem-space to work towards practical solutions.
“The feedback I heard from others was:”
“When we think about what Polkadot needs the most, it is probably NOT another Parachain. We need way more beautiful end-to-end user experiences and onboarding stories for users into our ecosystem.”
“for developers who want to build complex/upgradeable protocols that are difficult/impractical (technically or economically) to express in smart contracts, but that doesn’t mean these should be exposed to end-users at the application level.”
"I remember devs mentioning that they wanted to learn more about building dApps / write smart contracts. "
Above the quotes, what i am saying is that the post should be structured directly at what you, as an individual is facing. THE Community has to presenting their individual ideas and pain points individually, so that data is accurate. There’s no point in mentioning what an individual thinks others are facing. Otherwise its just a sub-committee pathing the way.
How credible is the “others” ? next,
How credible are you that you’re presenting accurately their ideas? I mean, you don’t even get me through a forum post, is a good example.
It should be straightforward, your pain point, and your idea.
@DarkArtistry , I will try to provide some answers below, in order to cover your concerns:
the post should be structured directly at what you, as an individual is facing
I - as an individual, and member of PBA team - am asking a question towards whoever reads this forum - to provide feedback and opinion based on discussions/experiences that one had with the rest of the ecosystem/people/“others” in the past months - in order to shape, if needed, a potential DApps content, for future cohorts - in order to help future students enter the ecosystem.
How credible is the “others” ?
Does it matter? The “others” that @shawntabrizi mentioned are obviously people from the Polkadot ecosystem - and in an ecosystem everyone’s opinion matter, even more when it comes from a very credible source as @shawntabrizi . Keep in mind that these “others” and many that have already provided feedbackin this forum post, are some of the persons that through the past 2 years shaped the content, which you followed in latest cohort, as a student.
How credible are you that you’re presenting accurately their ideas?
All quotes you mention are coming from very credible persons, that have shaped multiple phases of polkadot and care a lot about the ecosystem and the future. So I would not question that.
I mean, you don’t even get me through a forum post, is a good example.
I did “get” you and I “got” what you are saying - I mention though, that I do not see any value added on my question, through your post;
It should be straightforward, your pain point, and your idea.
This is your opinion - and even though I hear you - it does not mean that I agree with it
Since I am interested through this post to collect feedback about Dapps and potential content/lectures, I will strive away from answering basic questions of why I ask this and who I should listen to, and concentratemy attention, and conversation, mainly on fruitful feedback that can help us in PBA understand the needs of the ecosystem.
Mainly it reminds me of an additional issue. So in totality here are my honest feedbacks:
I think generally all contents are great.
Frontier should have been covered since it’s a pain when i really need the EVM compatibility because 892713782163 projects out there are looking for it.
Having practical approaches to build The community in the PBA, such as really spending time on getting the class involved in this forum would have been equally important if not more important then anything else in the entire schedule.
I love the product, really love it, Multi-Chain is obviously the way to go. But there are times where i do feel like the community is a “sub-community” where power lies in a handful of people. very contradicting to the idea of decentralization.
I would use I here because i would speak for only myself and not for others. If I wanted to rely on credibility, i would have just stick to JP Morgan, rather than building and slogging on blockchain. “We don’t trust, we verify” is a very strong message that describes a majority of the blockchain community today.
The credible people can guide the community based on their own evaluation and concrete train of thoughts, but should avoid trying to consolidate voices. Would some voices be left out? the voices they tried to represent how honest or valid are they?
