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

[sourabhniyogi]

@sorpaas @Cyrill I think the EVM vs WASM debate you are having is going to become meaningless because Polkadot 2.0 is undergoing a “virtualization” transformation in CoreJam:

• Polkadot is headed in the direction of CoreJam through @gavofyork et al.
• CoreJam will interface with EVM+WASM compiled Smart Contracts by interpreting EVM+WASM Code blobs in Work Packages/Classes. This is the future and collectively we have to figure out a road map for this.
• PolkaVM is a serious contender from @koute, with ink! WASM PoCs already in place – see this
• PolkaVM could have Solidity compile into it from solc => PolkaVM. (Anyone doing this?)
• Many other languages (vyper, Fe) could compile into in any number of old and new VMs in new CoreJam work classes
• Performance matters, developer experience matters, learning curves matter, end user costs matter, etc. to developers
• But CoreJam can support them all and should! There is no need to have a “which is better?” argument – real devs will just pick one and with CoreJam, Polkadot shouldn’t even care – it just “sells” CoreTime at the end of the day.

It seems clear that because the vast majority of smart contract devs know Solidity and target EVM chains, I think its an extremely important and timely topic to try to:
(a) build a solc compiler for PolkaVM
(b) chart a course for Frontier => CoreJam

If Polkadot has a tiny 1 man army attacking the above, its insufficiently resourced to this problem. Is this a debate?

If its because of a “WASM > EVM”, we need to shut that belief down now and change course immediately. Is this a debate?

Instead of a EVM vs WASM debate, we should be debating how to allocate resources (W3F grants) amongst different resources so that we get the CoreJam / Polkadot 2.0 future we want.

We’re very far from the misinformed alarmist topic thread, but I suspect the moderators are letting us get away with it because the topic is actually very important.

Please open a new topic “Polkadot 2.0: CoreJam + Smart Contracts” (or Frontier, ink!, EVM, WASM, solc, Solidity) so you can lead the way in charting a future together for EVM, WASM, PolkaVM, CairoVM, etc. in Polkadot 2.0?

[Cyrill]

Yes, I may, eventually, consider implementing a CorePlay (or CoreJam for that matter) compilation target in Hyperledger Solang. However, the relevant RFCs are still being worked on.

[Peter]

@sodazone

Polkadot, with its shared security model, holds significant value for these projects

What’s the combined activity figures in the projects you’ve mentioned? Every single one of the examples are relatively new parachains, which acquired their slots for amounts which are magnitude lower than the cost of initial slots, exception being Centrifuge. Yet, all of Centrifuge products and pools are EVM based, what exactly do they do in Polkadot?

@sodazone

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?

I didn’t quite get this part, so ultimately who is the end user of all the stuff/projects you mention?

@sodazone

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).

AFAIK, TON is pushing @wallet and TG as a super-app among its tremendous user-base. What model are you referring to?

[cpiccard]

@Peter

what exactly do they do in Polkadot?

Their business logic is running on Polkadot. That is similar to Phala and Crust network, I think. The users are usually on Ethereum.

Here is an interview of Centrifuge conducted by Kryptoschain:

Centrifuge UNLOCKED! | Real World Assets to Polkadot!

[WilliamFreude]

As a core developer of the Centrifuge protocol, I’d like to chime in with my personal take on this:

Our protocol operates as multi-chain, and we’ve chosen Polkadot as our home base for some pretty solid reasons. Polkadot offers a range of inherent advantages, including cost-effectiveness, high-performance capabilities, and a high degree of customizability. However, we’ve noticed a bit of an imbalance when it comes to liquidity and the DeFi userbase - they seem to be more concentrated on EVM chains compared to Polkadot.

That’s where our strategy comes into play. By opening our doors to EVM chains, we’re aiming to blend the best of both worlds. We want to harness the strengths of Polkadot’s ecosystem while also tapping into the larger DeFi userbase on EVM chains. It’s all about making Polkadot a more attractive destination for users from both sides of the fence.

Our flagship product, “Liquidity Pools,” is designed to be accessible in a couple of different ways. You can find it natively, either on our own parachain or remotely through XCM. We’re also making it available to bridged EVM chains, ensuring that users have multiple pathways to access our offering. It’s all about bringing people together and expanding the horizons of what Polkadot can offer.

I highly recommend to watch my colleagues @mustermeiszer 's Sub0 2023 presentation about this topic:

Centrifuge: Transforming into a Cross-Consensus Application Protocol | Sub0 2023

[SFX-1]

@sodazone

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.

Brilliant awareness, this shows how much clarity of (long-term) vision is present in our ecosystem.

[SFX-1]

@sourabhniyogi

We’re very far from the misinformed alarmist topic thread, but I suspect the moderators are letting us get away with it because the topic is actually very important

Wonderful seeing one of my own main favourite dwellable mental conditions so eloquently described