In a broad sense, I agree with the some of the thesis share in this post.
- Development Experience is suboptimal, Development cost is high.
- More emphasis on smart contract is a promising way forward.
- More standardization helps.
However, I want to push back on the type of thinking that is being used to lead to these conclusions.
Compared with developing on Ethereum, parachain developers need to pay for the blockchain explorer, indexer, hardware wallet, and RPC providers monthly
Comparing the development and maintenance cost of a parachain to a smart contract is similar to comparing the development cost of a bicycle and a car. Of course, one is more expensive than the other one, but one can also do many more things.
I don’t deny that better standardization and tooling can improve the parachain development cost. A good recent example of this is to finally have a proper multi-parachian ledger app (see Polkadot Generic Ledger App). But, I highly doubt if it will ever be as simple as deploying your application as a smart contract.
A similar conclusion can be drawn about XCM as well:
Although Polkadot is advertised as the interoperability solution, its deliverables are actually slower than the competitors
I don’t want to go into too much detail, but I am sure it is reasonable to acknowledge that the tools and measures needed to let two blockchains talk to each other is significantly more complicated than two contracts in the same blockchain talk.
I think these complications about the true cost of running a parachain were discovered somewhat late, and more importantly, not educated in our ecosystem fast enough. Nonetheless, it is better late than never.
So, the problem is really not JUST that parachains are too complicated. Part of the problem is also that the use cases that were fitted to be a parachains were too simple and therefor not worthwhile the cost of running in.
What I personally hope to see is a first-principles debate around this topic, one tries to find the right fitting for “what application should actually be single parachain?”.
That is all not to say that we should not try and improve the situation, or try and help the existing teams survive and re-evaluate. We should, but we should also look back and objectively look at what we have done wrong in order to improve.
I think @alice_und_bob pointed out the underlying crux of all of this fairly well:
If you don’t know if you should build smart contracts or a chain, you SHOULD build smart contracts, because you haven’t understood your problem well enough yet and therefore should walk the simpler path.
Teams should be encouraged by the ecosystem to prefer building a contract (be it ink! or Solidity) if they are not sure how much scaling they want, or how much funding they have. Hopefully in the next year, with on-demand/agile-coretime a team can have a smooth transition from building with ink! → deploying on a parachain → partially migrate to a hybrid chain that is their contract + some pallets, and be on on-demand parachain. Finally, if needed, they can upgrade to a bulk parachain.
Taking the analogy above, if you are not sure how far you want to go, you should choose the bicycle and not the car.