Chaos kills. Last week, Polkadot lost over 16,000 new users as one of its best projects, Subsquid, left for Arbitrum

Governance
25

I would appreciate if you prove me wrong, however I believe that this is a dangerous misconception in the current position of the ecosystem. Arriving slowly and naturally to the democracy is fine, but on my opinion we risk to get to the empty state before the right processes are figured out by the community.

Based on what I have heard from the other members of the eco and noticed already, the teams who tend to use Gov2 “as intended” (which means applying, getting feedback, then reapplying again and again) are the ones who are either already deep in development and long in the eco, or did some job already and are requesting retro funding to cover the costs. Even for them getting a pushback is stressful.
The new teams however quit after the first pushback because it just makes no sense for them, especially considering how easy it is to get funded by other ecosystems. And with the current trend when AI&ML are on the hype for VCs and funds, teams who want to build on blockchains eco are becoming smaller, so we are basically operating on a shrinking market already.

The first solution that comes to my mind is easy obtainable bounties for new teams, enough to cover initial MVP and research (I can elaborate on it in case anyone is interested),and if that is successful and the team decides to continue - then let them dive deep into Gov2 with all of its struggles. I have seen a couple of proposals in the making, suggesting the same idea, so I guess some part of the eco is ready to implement this. The general mood of “let’s put devx first” is related to this sentiment as well, on my opinion.

On the same note, would be extremely interesting to find out how successful the PBA alumni teams are doing with their projects.

2 Likes
26

This. Right here - is the issue with Polkadot right now. It is a hard truth, but in my opinion, the Polkadot community should accept that without an EVM-centric roadmap and seamless cross-chain bridging to Ethereum + major EVM chains it risks exacerbating the negative feedback loop: less liquidity → less interest → less developers → less investments → less liquidity.
There is no one putting money into DOT right now. In fact they are taking it out because there is money to be made elsewhere. The money is in ETH. Everyone knows this so it seems snobby for DOT not to play ball. If DOT really is “Better tech” then as people use it that will become apparent and the DOT protocol will grow. Simple. But just waiting around for people to see DOT as better so ‘I will build on that’ is crazy imo and its just not how it works. People. Follow. Money. Always have, always will. This is because they need to. People need to get paid. Ask yourself do you want the DOT price to reach its ATH again? At the moment its a pipe-dream.

27

The EVM has first mover advantage, which easily distorts many causations from reality.

You have to remember that the EVM was originally designed by @gavofyork (see the yellow paper), the same original architect as Polkadot. As much as it could have been the right choice at the time, it is certainly not the right choice for the future of the decentralized web, or he would have not iterated on that idea.

Perhaps EVM will always be the place for DeFi just due to its historical footprints, similar to how Wall Street probably still uses ancient technologies for some of their back-end systems.

Thankfully, Web3 does not end at DeFi.

DeFi probably isn’t even in the top 5 most interesting things you can do with a decentralized web.

We instead should focus on building a technology which powers what we envision the Web3 future to be. Not another bank and trading system, but perhaps:

  • the backbone of new governance systems
  • the medium for decentralized social networks
  • the home of reliable oracles and prediction markets
  • the platform for disseminating truth
  • the facilitator for open source development

It seems people like you are more interested in building the next “JP Morgan Chase”, rather than helping build the Web3 Googles, Microsofts, Apples, etc… Perhaps then, it would be worth revisiting the book Zero to One.

Monopolies enjoy such strong profits and market dominance because they have discovered a genuinely valuable product or service for consumers, one that no one else has yet developed.

I would challenge anyone to show how Polkadot has made any decisions which are sub-optimal for being the worlds next “ubiquitous computer”. In fact, if you have been paying attention, you would know that was always the plan…

You have been paying attention, right?

11 Likes
28

Yep great. Love the vision. I guess the point is also about keeping the ecosystem thriving as the vision is pursued. Would it hurt to play ball with the other contenders in the space for the sake of keeping the money going around and gaining users? Nobody wants to be another bank, I don’t think that is the idea at all, its just while you develop the vision why not get loyal people on board, in whatever way that is currently going. DOT needs users so play the game but as you say play it better, smarter then drag people along with the vision to Web 3 paradise. People like me have put resources into DOT and sometimes seeing the vision isn’t as exciting as seeing the ecosystem thrive. IYKWIM. :wink: Peace to you though and thanks for even bothering to answer.

29

I’ll double @faultcore and @shawntabrizi.

Don’t just criticize - suggest what’s better.

Based on that, we have a great tech foundation and an active community, as well as community growing efforts that were proved working. Given the market and hype vibes, the people are leaving, but it would be very unusual otherwise. Interestingly, we’ve all gotten used to the unusual trends here, but it seems like that’s coming to an end.

Yes, opengov is a sandbox (very much like akin Raft or Rust survival games). And the major problem there is that the sandbox lacks good guidelines. You either have to wing it or have a friend explaining them, but it’s really hard and not much interesting to play alone - the chance is high that one looses the interest in the beginning, before actually gets to the entertaining part.

From the perspective of Systems Thinking it lacks well-defined Roles and roles’ Interests. Actors don’t understand when they have to play several roles, their attention splits and suddenly it becomes overwhelming. Together with some certain Roles not being incentivised, this becomes discouraging to do as it takes too much effort. And here many complain. And these complaints, if you follow, are often not very constructive. And this proves the point.

Now, we have these new-ish Political Parties, like Chaos DAO and Ivy. Which are essentially, the habitual way of tackling the democratic challenges, and one of the planned ways of how this situation will be resolved. How to counterbalance some crazy whales votes, etc. It’s way easier, resource-effective and fun for many actors to join such party rather than winging alone.

I invite you to have a look on how the Events Grant effort has self-organised. Community Events Wiki and Overview of received proposals. They have curators, they assign participants to review, research and deliver feedback about each of the proposal they get. They step down in the case of an conflict of interests. By far admittedly it’s not optimal, but hey, it’s good enough, it’s effective!

3 Likes
30

As for the newcomers, sadly the opengov trend is that the good ideas are being downvoted or not voted for, often with very silly motivations such as bad UI or not enough content on the stage of an MVP.

Also, the ecosystem is a bloody mess when it comes to the “I want to consider Polkadot for my new project, let’s see what they have to offer” scenario. And there’s no single point of entry. And no, it shouldn’t be a Parity-maintained website. In my view, it should be something like this: Polkadot Candy Store.

To add to the problem of inviting new users in, the biggest community events (organised by Parity) over the last few years have been nice as usual, but misplaced. Sub0 is deeply technical, so that’s fine, but a Decoded-like event must take place close to x-city blockchain week. And the Web3 Summit also needs to be resurrected. Thankfully, the organisers of ProtocolBerg actually did it this year, and placed it very well, it was a huge success. This will also (partially) solve another ecosystem-wide problem of marketing.

I encourage you to give it a thought from this perspective. We need more of the Political Parties. And the ones that exist should consider using the methods like the one in the Events Grant.

2 Likes
31

While I may agree with certain other things you’ve wrote in that comment, Polkadot indeed has made many sub-optimal technical choices for being the world’s next “ubiquitous computer”.

  • We should have used binary trie instead of hex trie. We’ve known for a long time (actually, since the day when I was still doing in Ethereum hard forks in Parity Ethereum) that hex trie has certain performance problems. Our state size is rather small at this moment so nothing’s apparent. But when Polkadot state grows big, we’ll be rediscovering them as it was on Ethereum.
  • EVM is certainly not the optimal solution for smart contracts, but WebAssembly is also not the silver bullet. It does have its problems. The optimal VM for a smart contract is probably closer to RISC-V or eBPF (but we may soon discover issues there as well).

I would argue that for many decisions we made in Polkadot, it’s “marginally” better than Ethereum, but not “magnificently” better. If you compare it with the actual “optimal” solutions, it’s still sub-optimal. The question is then, for anyone thinking about using Polkadot vs Ethereum, whether the technical trade-off is worth it compared with the lose of ecosystem.

In Polkadot, I’ve seen many times that the debate, especially on things that Polkadot thought to be “superior”, ended up being an ideology battle, rather than what it should be – a technical battle. This happens in the debate of on-chain governance system, of WebAssembly vs EVM, and of parachains vs Ethereum roll-ups. I don’t think this helps us at all. It just makes us blind of the development on the other side.

2 Likes
32

We want to share our view. Polkadot has a great first mover advantage in the mechanics needed to capitalize some problem spaces with potential value: data availability, tailored shared security models or dynamic validator sets as a service (consider eigen layer, decentralized oracle networks, etc.), network-native societies and citizen commons (e.g. following the needs of dark matter labs in the EU). All of this is embedded in a shared resources model, through system parachains and horizontal and vertical interoperability protocols. In our opinion (that of course might be wrong and we are happy to expand, revisit and so on) the focus on dapps of mass adoption is heading to the wrong battleground.

The future is open and better if we choose our battles wisely, considering position and movement.

33

I think it’s important to take into the account that at the time Polkadot was created WASM was probably the best practical choice, simply because there weren’t really any other good alternatives (besides maybe going fully custom, but that’d be orders of magnitude more complex and expensive), and WASM’s downsides (in the context of a blockchain) weren’t really apparent then.

Fortunately I don’t see why we can’t just evolve and eventually migrate. Even the trie format (and all of the rest of technical debt which we have) could be fixed once we decide to rebase the chain on top of a new genesis (which AFAIK we would like to do eventually).

Also, regarding eBPF - while WASM might not be entirely optimal eBPF is way worse in my opinion, so I think we dodged a bullet there. I’d take WASM over eBPF any time of the week.

2 Likes
34

The point is, you can say the same thing about Ethereum. At the time Ethereum was created, EVM was indeed also the best practical choice. It is probably still the best practical choice, compared with WASM (which we know its downsides now, and consider the issue of technical superiority vs ecosystem development), RISC-V (which is better than WASM, but hasn’t yet been developed), and all others.

In Polkadot, we often talk about EVM in the context of WASM vs EVM. Then we discuss why we made the right choice because WASM is the future. However:

  • EVM is still a perfectly valid choice for a smart contract VM. It’s reasonably performant as long as you optimize the engine. And practically we learned that the bottleneck is rather storage, than CPU.
  • Certain choices we thought that was wrong in EVM, are actually rather trade-offs. For example, if we’d need to deal with primarily 256-bit integers, then EVM’s choice is rather okay, and it makes the contract size shorter. In Wasm, those primitive operations are usually compiled inline, which affects the contract size (1 byte vs 4 byte, for every integer operation).
  • We thought that WASM being able to compile and applying a lot of optimizations is a significant advantage. It turned out only to be a marginal advantage because we are limited by compilation time, and can probably only do one-pass.

Besides all the above, and again, while I agree Wasm is marginally better than EVM, we might also be arguing the wrong thing there. No one interacts with EVM directly, only the programming languages. It’s rather a hidden implementation detail that contract developer usually does not see. The engine just has to be there, doing its own things. And this considered, we should probably instead compare Solidity vs Rust, as those are the actual things to write smart contracts. In this sense, Solidity/EVM is actually better than ink/Rust/Wasm at this moment:

  • The language was specifically designed with smart contracts in mind. Rust unfortunately isn’t, so we need to ask all dapp developers to be mindful of no_std, and not use certain APIs. This is always a confusion point.
  • Solidity has been polished for a really long time. This is especially the case for its documentation and educational materials.
  • There’s a mature industry and open source toolchain for security audit in Solidity. This part they are way superior than us.

If we compare the practical points, and compare the entire smart contract development toolchain, instead of just the VM, then the competition quickly reverse. Of course, all of those can be fixed in Polkadot – there’s no technical difficulty. However, so can Ethereum. Since Ethereum 2.0, their architectural separation of the consensus engine and the execution engine makes development a whole a lot easier. They are also ahead of us in terms of dealing with merkle tries and storages. We’ll one day figure out that we don’t need to store all intermediate trie nodes on disk, because hashing is cheap, just like they have already done. Ethereum also made the conscious decision not to go full into on-chain governance – while they don’t have anything better yet, their hesitation does have a point – they pointed out several years ago about the worry of non-representativeness, game theoritical attacks, etc, which we’re experiencing in OpenGov at this moment.

The point is, we should probably stop assuming that our architectural choice is the best. In certain parts, our architecture turned out to be only marginally better (Wasm). In certain parts, we are rather worse (Solidity/EVM ecosystem, merkle trie). It’s important that we don’t continue with those ideology-like battle (“Wasm is certainly better than EVM!”) and keep an open mind of everything that’s being developed elsewhere.

6 Likes
35

Yeah, for sure, I agree. We certainly made some mistakes along the way, so we should objectively evaluate where those mistakes are exactly and work to fix them.

2 Likes
36

What are some regular things dApp developers can do in Solidity and want to do in ink!, but can’t just because of no_std?

Solidity has been polished for a really long time. This is especially the case for its documentation and educational materials.

As a maintainer of a Solidity compiler, I have to disagree respectfully.

In my opinion, the Solidity language is unfinished and doesn’t look very polished. People got used to deal with it.

Just some examples immediately coming to mind: Error handling is incomplete, Solidity introduced custom errors (only after 0.8) but you can’t catch them. They want to add generics since many years now but it’s not happening so far. They added user defined types but only for elementary types. Array types are implemented unlike in any other relevant Language and feel very counterintuitive to work with. Not having a stable 1.0 release and instead kicking the can down the road with version pragmas doesn’t make the language feel very “polished” neither.

Add to that, many contracts resort to using inline assembly because what they want to do can’t be expressed in Solidity.

The Solidity lang documentation is incomplete and definitively not a contender to something like the rust book.

Further you could argue that, if Solidity (in it’s current state) was indeed the perfect and polished solution for dApp development, the Ethereum Foundation wouldn’t be venturing in building another solution.

There’s a mature industry and open source toolchain for security audit in Solidity. This part they are way superior than us.

I agree to this point. And it stems from, in my opinion, only one reason why you are perceiving Solidity as the practical choice: First mover advantage.

3 Likes
37

You could make the same argument why someone would prefer Ethereum over Polkadot/Solana – there are no regular things dApp developers can’t do in Ethereum and want to do in Polkadot/Solana, because of all those pitfalls we’ve discussed about Ethereum. There are just workarounds and drawbacks.

Even, for some contracts, you could argue that no_std is actually a hard blocker, because some crates are just not designed with no_std in mind and you just can’t use it. This is rather a pitfall in Rust, that we had no choice but inherit it into ink.

I don’t want to comment too much on Solidity’s language design issue. All the drawbacks you mentioned seem to be common knowledge which everyone agrees, and it is missing the point.

The point is not that Solidity is a 100/100 language. Everyone knows that Solidity is 50/100. The point is that we should stop considering our own solutions (ink/Rust) to be 100/100. My argument is that our own solutions are only marginally better, and it has it’s own problems. If Solidity is a 50/100 language, then ink/Rust is probably only 60/100. We do not have the best solutions, either. A superior solution attracts a community by itself, but a marginally better solution requires its own dedicated work to build a community, because everyone will still be considering the ecosystem first.

38

Care to provide concrete examples on what can be done in Solidity, but can’t be done in ink! (or other Rust smart contracts) because no_std isn’t available in contracts?

So far, I have never ever heard anyone considering ink!, or Rust, or Polkadots tech stack in general to be flawless.

I’m not sure how you made up those numbers to back up that argument.

However I’d nonetheless be very happy to hear about what you are missing from ink! or a Rust based smart contract language in general to make it “100/100”. :slightly_smiling_face:

39

Note that my post was responding to Shawn’s comment:

I think the rest of your questions are either answered by the above context you missed, or I have already answered.

40

No. I am aware of the context. Since the EVM runs fine on a Polkadot parachain. Polkadot supports both, Wasm and EVM contracts. Rust and Solidity contracts. Yes, it’s always a trade-of.

I agree with you in that Solidity + EVM isn’t perfect, nor Rust + Wasm contracts are perfect. However you made some claims that I can just not follow. I am genuinely curious as to how no_std in Rust smart contracts regularly hinders dApp devs to do things possible in EVM / Solidity. I’m also genuinely curious to know what you are missing from Rust based smart contract languages and alternative contract runtimes to make them even better. We’d love to improve on everything we can :slightly_smiling_face:

41

This sounds like a complete missalignment between what most of the parachains did (DeFi and dapps of mass adoption) and what your vision is. Why a regular end-user would care about anything you mention? Is Polkadot a B2B chain? What businesses has it onboarded? What sane business would hire a team of rust engineers to build something on Polkadot? What value and to whom stuff like dynamic validator sets brings? SO many questions…

Also, interoperability protocol has very apparent issues: its very complicated and 99% of stuff that’s there won’t be ever used. Most of the XCM instructions are useless, most parachains use Withdraw, ClearOrigin, BuyExecution, Deposit and that’s it. No unified multiplication rules, no single way to send a token, there are like 3 or 4 options and several chains use several of them interchangeably. Its anything but interoperability out of the box.

42

Thank you for the response, Peter. We’re pleased that our vision surprises you.

We believe that the current adoption is confined to specific end-users seeking profits, such as trading enthusiasts and dollar-cost averagers. The upper limit of this user base has already been reached and taken advantage of by other networks during the DeFi hype of 2021.

We observe a shift in the blockchain space from dApps to chains or similar constructs, exemplified by stacks like Optimism and Polygon’s zkEVM. Polkadot holds a distinct advantage here with its secure ubiquitous computing concept, which it has had since its inception, and should leverage this position.

In this context, revenue is expected to come from services provided to other networks, including their settlement layers. Services like dynamic validator sets are crucial for decentralized oracle networks, data availability, shared sequencers, etc. (refer to https://www.eigenlayer.xyz/ for use cases).

Concerning businesses, Polkadot has on-boarded several parachains that aren’t primarily focused on mass end-user adoption:

  • Energy Web for decarbonization solutions
  • Watr for commodities
  • Peaq for IoT
  • Hashed Network for digitally-native business on Polkadot
  • Polimec for decentralized community funding
  • Aventus for enterprise solutions (with partnerships with Vodafone and Beatport)
  • Centrifuge for tokenized debt products

These are just a few examples off the top of our heads. Polkadot, with its shared security model, holds significant value for these projects. We also see a realistic possibility of high adoption in citizen commons aligned with the Sustainable Development Goals. Ultimately, the most compelling blockchain use cases lie in digital-native governance, trustless relationships, and transparency.

Considering this from a different perspective, why would retail users be interested in lower-yield opportunities or token-gated social apps with significant volatility? We fail to see how or why users would migrate from existing social platforms to blockchain-based counterparts. Do dynamic validator sets bring value in this context?

This doesn’t imply that DeFi or other dApps have no place, but their use cases should be evaluated with rationality (the TON model as an example).

Hope that this fosters a fruitful exchange of points of view. We are not entrenched in any maxima, we are happy to listen to other positions.

3 Likes
43

It seems to me that you’re rather backtracking a lot, which makes the debate rather confusing. You tried to counter my initial argument that “Polkadot has also made sub-optimal choices in merkle trie and ink/Rust” by arguing that “Solidity is worse”. Then you backtracked to “no one said Polkadot is flawless”, and then to “Polkadot supports both EVM and Wasm”.

I have a feeling that we’re just heading into the ideology battle of Wasm vs EVM, which was specifically the point I argued against. That’s why I refuse to engage too much with you on this. Let me give you a counter-question so that you can understand what I’m talking about – instead of asking, what are things that devs can do in Solidity that they can’t do in ink, because of ink/Rust pitfalls, we ask the reverse – what are the things that devs can do in ink that they can’t do in Solidity, because of EVM’s pitfalls? To both questions, the answer is not really much. If we just talk about smart contracts, then the feature sets of both are mostly equivalent. It’s just that ink/Rust is nicer. In the future, when we developed RISCV VM, they’ll also be slightly nicer than ink/Rust.

I have made my points that EVM can also be performant, and we might be optimizing for the wrong problem – smart contracts are usually storage-bound, not CPU-bound. Wasm has its own problem of compilation complexity and an evolving specification. We also lag behind Ethereum in our storage optimization work, and we made the wrong choice in using hex markle trie instead of binary. This is why I say, if EVM/Solidity is 50/100, then ink/Rust is only marginally better at 60/100. None of Ethereum or Polkadot are superior compared with each other. It follows that you’ll need to join the fair battle of ecosystem competition vs Ethereum, as we don’t have technical superiority.

Regarding your question about no_std, I think I have made myself clear and I won’t repeat myself here.

3 Likes
44

My apologies if I was confusing.

I’m not trying to counter your arguments or anything; Also I’m certainly not after Wasm vs EVM ideology battle neither. I’m just trying to make sense of what you are saying, to distill something productive out of this discussion. So far I conclude that you are of the opinion that:

  • For Rust + Wasm contracts to find broader adoption, they need a healthy ecosystem of blockchain specific toolings, libraries, standards and security auditing firms. The point is to compete on the ecosystem level, not on the technical.
  • For Rust + Wasm contracts to find broader adoption, their bytecode needs to consume less storage
  • It would be nice to have std in smart contracts. While I agree, it’s unclear how this should ever work. You completely failed to provide any concrete examplatory use cases. If you can please provide some example crates you wanted to use in your contracts, but couldn’t because of std. It would give us valuable insight in what people are trying to build, but face difficulties. Unfortunately, so far, you didn’t, instead saying I’m missing context, I’m backtracking the discussion and instead asking me to provide examples about “things that devs can do in ink that they can’t do in Solidity” :confused:
  • In general, smart contracts (including EVM) on Polkadot will always have a drawback against other protocols because how storage in Polkadot works

Thanks for all your input, it is valuable to me. Please let me know if you still think that I am missing something.

1 Like