@alice_und_bob has raised a very good discussion here:
However, as a parachain team, I’d like to add the other side of the coin: Not only the developer experience, but also the cost matters. I didn’t see any significant discussion in the Polkadot forum, so I’d like to open a new thread to talk about it. Actually I have shared my idea with Parity before as a follow up for the developer experience survey, but never get a response. So let me publish it.
I’m building on Phala Network and would like to point out some real problems not addressed in DX survey.
First of all, the real cost to develop on Polkadot is unmatched high. Compared with developing on Ethereum, parachain developers need to pay for the blockchain explorer, indexer, hardware wallet, and RPC providers monthly. Recently the OpenGov has rejected most of the initiatives to cover those costs by the relay chain treasury. So the parachain team has to pay. Otherwise each team must maintain a large DevOps and RD team to maintain those infrastructure. And don’t forget, running a network is already costly.
Secondly, the lack of standard results in very limited composability and consequently the ecosystem becomes further and further away from the “mainstream” users.
Although Polkadot is advertised as the interoperability solution, its deliverables are actually slower than the competitors. There are a bunch of reasons: the slow development progress of XCMP, the high barrier to open HRMP channel (governance is expensive), and the lack of XCM documentation, and the complexity of the three versions of XCM (compared with competitors like Axelar). We can name more reasons, but as a result, the XCM ecosystem evolves too slowly.
Currently the only way to compose two projects (parachains) is to use XCM. Given it’s hard to learn, develop, and maintain, it’s natural that the parachains evolved their ecosystem so slowly.
And let’s see how does the “mainstream” ecosystem performs. We know that’s the EVM ecosystem. In there, the projects are smart contracts, and they can interact with each other seamlessly. Contract calls are way easier than XCM and it doesn’t require any governance process. On the other hand, in the parachain ecosystem, a new team can only build their own parachain and compose with another by XCM, or they contribute to the parachain codebase by writing a pallet. The both process involve governance and thus a lot of resources to establish the trust in the community.
Each reason adds the cost to the parachain startup, and eventually the ROI of building a parachain becomes a questionable value.
I see the Polkadot 2.0 is a start point trying to address part of the problem I’ve pointed out, but at this stage, unless we take very straightforward measures, I’m not optimistic about the future, as a parachain. My suggestion:
- Shift the ecosystem focus from pallet development to smart contract development. This removes most of the costs: auctions, infra, experience to learn XCM, etc. this means we shouldn’t all in XCM as the only way to build composable projects.
- Strong support of the infrastructure like blockchain explorers, indexers, RPC, etc. It should be funded by the relay chain treasury if we want be competitive to attract any innovative developers.
- Focus on standardization to further encourage composability between the projects. By standard, we should not only think from the Polkadot’s view, but also the “mainstream” users’ view. In other words, deploy the practical interoperability solution to the EVM world as soon as possible.
I really want to see the success of Polkadot. Hope my suggestion can help.