I am starting this thread as a follow-up to a comment that I posted elsewhere:
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.
I want to discuss and learn about applications in which it is (theoretically) worthwhile to launch your own chain, because it is not possible to implement that system as a smart contract. In other words, these are applications that can ONLY be built as a runtime/chain.
Over the years, I have heard multiple examples of existing parachain teams and how they are tapping into specific features of FRAME/Substrate/Polkadot to do something that was not possible in a smart contract. But, I will abstain from naming any, because I am not sure if my information is up-to-date. I am sure parachain teams who read this can chime in.
From ta technical standpoint, I want to share a few high level data-points that I find relevant:
Having a fee/token less runtime is very much a possibility, and a non-starter in a smart contract environment.
An extension of this is using unsigned transaction/Inherents.
Having (semi) automated processes (on_idle, on_initialize etc) is something that you can not trivially.
(possibly more FRAME features that you cannot get in a contract)
You get way more efficiency (through weighing and lack of metering) and dedicated bandwidth in a Runtime, but you have to deal with asynchronous communication with other chains.
Deploying a runtime is more difficult.
Polkadot uniquely allows the mix and match of runtimes and contracts , through the novel design of having pallet-contract/pallet-evm to your runtime, and having your application logic be partially in a smart contract where you don’t need the bandwidth and prefer the flexibility/ease, and be a pallet where you prefer the speed. aka. hybrid chains.
Agile coretime and a simple deployment scheme (like the one being developed by Tanssi) are crucial parts of this design.
But all of this is still comments on the technology side. What applications are very well suited for this?
What I expect to get out of this conversation:
if the initial quote in the thread is something that you resonate with, it means we need to spend more time thinking about what are the unique applications that can be best done in Polkadot, and not at all feasible elsewhere. This is a big part of our success.
If we have a few of these examples, I want to build tutorials around these examples, showcasing the exact way in which you can achieve a unique
Note:the cells are created according the number of devices they contain.The layers represent different physical electric grids connected in a redundant way.
Like the diagram is demonstrating, in theory we could just have a blockspace per smart contract. But in order to do that that we would have to build a sharding solution (Sharding divides the blockchain into smaller pieces, each of which is responsible for processing a subset of transactions. Each shard could then be dedicated to a different smart contract. This would be more efficient than having each smart contract run on its own blockchain, but it would still be more complex than simply having a shared blockspace for all smart contracts.).
Which leads to fragmentation,( Fragmentation occurs when the overall blockchain is divided into too many small pieces. This can make it difficult for transactions to be processed quickly and efficiently.) besides security,cost and privacy.
How you would do that in a secure/cost/privacy efficient way knowing the hard link between blockspace- parachain/parathread in the Kusama/Polkadot world ?
changing underlying systems (e.g. the consensus protocol)
writing the runtime in another language that compiles to wasm (even though it is an exotic example I could see this being relevant for non-rust devs in the future)
Can you clarify what you are counting as a smart contract? For example, it’s not possible to build a smart contract that does heavy computation without exceeding the block limits. However, there are workarounds, such as Phala and Integritee, that offer secure computation and could potentially fit the mould of “Smart contract based dapp”. The alternative without these TEEs would be executing the computation in a parachain pallet / chain extension.
If I have understood correctly, your main proposition is that fragmentation, for example, of data, is an issue when it comes to any sharing solution.
Polkadot is no different in this regard, at first glance. If you have two parachains, those parachains will be on different cores and, in principle, do not share any state. There might be a way to enable the collators of the two chains to access each other’s state while collating, but ultimately, you have to remember that these two parachains are separate applications with two distinct state roots.
For that reason, I don’t think that blindly going to the direction of using multiple cores of Polkadot simultaneously is a good idea. One should instead consider a more flexible scheduling method, eg. agile coretime and asynchronous backing.
What seems to me an unexplored avenue in this regard is the idea of storing all shared data on a single storage parachain, and then having your actual parachains or smart contracts interface with it. This approach would likely make the application more complex to write, but much more scalable.
indeed, although I would actually mention things like on_idle or upcoming #[pallet::task] as they are more specific to a chain. Offchain worker is somewhat of a poorly understood concept and sometimes misleading. But indeed it is also unique to a runtime.
indeed, if you want to change anything in the system itself, you need a chain. Very similar to VPS vs dedicated hardware.
I do think you can have any language to also transpile to Solidity or compile to EVM byte code, so I don’t find this one unique to runtimes/chains/FRAME.
What I mean by smart contract is code that is executed in a shared environment by a platform such as Ethereum. Crucially, that code is still executed onchain (eg. directly in Ethereum main net) or indirectly (eg. settled on Ethereum, assuming the roll-up is safe and sound).
In that sense, I actually would not count something like Phala as a typical smart contract platform, as it seems to have different trust/security assumptions than a typical smart contract platform. Granted, I am not very familiar with the trust model of executing contracts in a TEE, but it seems fundamentally different from normal contract platforms and their scaling solutions.
indeed, although I would actually mention things like on_idle or upcoming #[pallet::task] as they are more specific to a chain. Offchain worker is somewhat of a poorly understood concept and sometimes misleading. But indeed it is also unique to a runtime.
thanks for pointing that out, ill make sure to read up on that topic!
I do think you can have any language to also transpile to Solidity or compile to EVM byte code, so I don’t find this one unique to runtimes/chains/FRAME.
Agreed, however I think there is no current possibility to do so for most of the major languages (and I believe this is not going to happen in the (near) future as compiling - lets say javascript - to evm-bytecode is an extreme niche whereas wasm is more general in that matter).
In a non-rural setup, could easily contain above 500.000 devices per cell.
We would like to have a blockspace per cell.
So, right now the only available choice: -is to have a parachain/parathread per cell with a “master storage” parachain/parathread. Which means for our uses cases a “zillion” of parachains/parathreads for one small country of 15 millions people for instance and then using xcmp
We’re developing a competitor to existing bot detection products that works in a decentralised manner. This involves securely analysing user behaviour data and reporting the results on-chain. We can’t do the analysis in a smart contract as there is too much data involved and it is sensitive.
We can’t rely on individual nodes to report individually on the analysis due to trust issues. Therefore, we need some form of pallet / coretime model where nodes are rewarded for reaching consensus on user risk scores. We could achieve this by writing everything to smart contracts but we’d effectively be re-implementing the consensus mechanics included in substrate.
We don’t require a full parachain to do this work, just space on someone else’s chain and nodes with the appropriate software to do the analysis.
Apologies if this seems vague, we’re very much still in product development and would appreciate any feedback!
I’m experimenting on a sharded layer 1 where the shards are in TEEs like Integritee sidechains but the subcores will be run by the same validators, so they will run multiple cores in parallel (thus need more powerful computers while allowing for parallel scalability at the protocol level). The network will ideally also have TEE enclave OCWs that have the capabilities of Crust (simple storage) and Phala (compute cloud). The system is very complex and requires a custom consensus mechanism which I’m also experimenting on. It could be a good place for your use cases, but an MVP is a long shot. But it will be nice to share the idea get some feedback.
There are a couple of issues that comes with this and the level of complexity, but its somewhere to start from, and the issues are all resolvable. Nodes will be more expensive to run so I introduced pooling similar to that of Phala and a couple of incentive mechanisms. Mostly in the idea stage, but a good start.
The system would look like this:
The compute similar to Phala, and the Storage works similar to Crust but with a different order and incentive models.
It will be nice to share some ideas to improve this, looking forward to getting some feedback and I’d like to see how this could be tweaked and adjusted for use cases like yours.
Hi @alfellati , Thank your your response. Very good points.
Regrading On-Chain Workflows (OCW) they are expensive, but a must on our world.
We have study the Phala Network very closely. We were “afraid” mainly of these two points:
Phala Network is designed to be scalable, its ability to handle large-scale workloads remains to be fully tested.
Phala Network’s security and privacy hinge on the integrity of TEEs(Trusted Execution Environments). Any vulnerabilities or flaws in TEEs could compromise the network’s security and expose user data.
