NOTE: This was a thread which took place in the internal Parity Forum on July 12, 2022, and would like to now migrate to this public forum now that it exists. I will try to copy and paste relevant parts of the conversation, and would love for us to continue the conversation here.
In a conversation here at the Polkadot Blockchain Academy in Cambridge it became more clear to me how to describe how XCMP / Polkadot can be used effectively versus some of the misunderstandings other have about it in our ecosystem.
I am of course not an expert on all things here, so maybe some of this is wrong, would love to hear from experts like @rob and @gav
Polkadotâs bet is quite simple:
- Scale by parallelizing transactions to multiple blockchains. (sharding)
- Scale by having those multiple blockchains be specialized and optimized for a particular use case. (heterogeneous)
However, these choices also come at costs:
- Technical overhead and complexity of building these systems safely and securely. Mostly on Polkadot protocol development side, presumably why something like this takes 5+ years to develop, and many more to come. Something we can overcome.
- Sending messages across blockchain shards is slow. Like WAY slower than you can expect for any âcross contractâ communication that people have become use to with defi and all that. Something which I argue cannot be solved.
It seems to me that people want to duplicate multi-contract scenarios with parachains, but if we do this, Polkadot will look bad, because Polkadot (or anyone else) simply cannot do this. It is literally beyond what physics allows.
Polkadot instead makes the bet that a user will not actually move assets across Parachains that much, and when they do, the advantages of a specialized chain will be worth it.
Letâs imagine two dapps: a DEX and and a privacy layer like Tornado cash.
Letâs assume a DEX contract on Ethereum can perform a swap in .2 seconds.
While a dedicated DEX parachain can perform a swap in .1 seconds.
Letâs assume a tornado cash contract can perform a privacy operation in 1 second.
While a dedicated privacy parachain can perform the same operation in .5 seconds.
NOTE: I think this is a vast underestimate. I think there is evidence that parachains are hundreds or thousands of times faster than their contract counterparts.
Now letâs assume that on Ethereum, moving a dex swap token into a privacy layer is basically 0 overhead.
While on Polkadot, we should expect at least 12 seconds for an XCMP transfer between the two parachains.
This means, if we are trying to highlight scenarios where a user can quickly transfer some token to a dex, swap some token, then move it to a privacy layer to hide their trades, and then back to some final account, we will be so far behind Ethereum it is not even reasonable.
Instead, the scenario which highlights Polkadotâs advantage is when you are doing 10,000 dex swaps, then a single transfer to a privacy layer to hide all those operations. Here, you would actually save much more time, because each of those dex operations have been optimized on a dedicated blockchain, and the overhead of XCMP is shadowed by all of the time (and fees) saved by doing it in a more optimized environment.
What does this imply about how users and products will be built on Polkadot?
Well, Parachains wonât actually be THAT focused, at least, they will all likely provide âgood enoughâ solutions to common operations like DEX (if they manage multiple tokens), smart contracts to a certain extent (for extending funtionality on their chain), etcâŚ
These parachains will have these applications as secondary features compared to their main product. And they can achieve these features quite simply thanks to Substrate and our modular pallet system. Adding a dex to any parachain will be as simple as adding a new pallet to their runtime.
However, this does not mean the death of DEX parachains, since we all know that systems like a DEX are optimized where there is high liquidity, lots of different available assets, and only a dedicated DEX chain will be able to provide that as a primary feature. If you are doing a small conversion for some scenario, probably you donât mind too much about a super optimized dex trade, but if you are doing big trades, probably you will want to eat the time cost of transferring the asset to an appropriately competitive DEX parachain. Same with contract parachains.
This also implies that users will probably end up having a âusableâ amount of assets on each chain they care about. It will not be a normal scenario that a user wants to perform one action on a parachain, so they start with their tokens on DOT, initiate a transfer with âjust enoughâ, and perform that one operation. Instead, they will probably predict how much they will use another parachain over a long period of time, transfer enough assets to that chain to handle all of those operations (and more), and just manage that balance on the other parachain.
This means we probably should be directing teams to build less UIs which execute operations across multiple parachains, and instead focus on dedicated UIs for all the operations on a single parachain, and a really amazing UI for managing your assets across multiple chains, and making that one time transfer.
Does this mean that all of the programmability of XCM is useless? No, since XCM is also targeting contracts where all of these cross contract calls are free (our initial assumption), but likely XCMP and cross parachain programmability will be minimal, since the amount of âactionsâ you can take on either side of the XCMP operation wonât be that large, and thus does not really outweigh the large overhead of the transfer itself.
There are probably a lot more that we can derive about behaviors and what will actually be successful on Polkadot if we continue to think down this path.
Is there anything here which I am getting wrong?
Are there any bets we are making which would change if this is right?
