Hybrid system chains make Polkadot permissionless

I was thinking a bit about the concept of hybrid chains again. We expect our parachains to adopt that pattern; what does stop us from integrating the contracts pallets with core protocol functionality like assets, staking or governance? By factoring out core functionality like staking and governance into their own chains, this becomes feasible and I advocate for those chains to have the contracts pallet on board.

Let me share some exemplary ideas I’ve accumulated over time that would benefit a lot from contracts on our system chains. Please note that they’re just ideas and shower thoughts to spark motivation. Maybe I made shortcuts, oversee things, or they don’t even make sense.

Staking chain

I’m thinking about “restaking” à la EigenLayer, which was discussed here before. I understand that designing such a mechanism comes with challenges. However, contract accounts on the staking chain would consequently enable restaking comparable to EigenLayer, given the contract runtime does provide the relevant APIs? What would be the implications of it? I don’t think this is as important or as useful as on Ethereum because shared security is intrinsic to Polkadot. Regardless I see it potentially viable as an alternative and for other use cases people come up with.

Governance chain

I’d like to see contract accounts vote. OpenGov but directly programmable in a permissionless way.

Private voting is to be favored over pseudonymous voting in a democratic system because participants potentially knowing about the other participants decisions will inherently influence their decisions. I could imagine something like an “unspent vote output” model; a design inspired by privacy protocols like tornado core, adapted for votes. Or using some other means of obfuscation, naivly, ring signatures come to mind too as they’re used in a particular privacy focussed chain. In reality this shouldn’t be trivial to get designed right, so lowering the barrier on the implementation side by providing contracts should help people innovate.

On the flip side, controversial use cases also get easier: For example “incentivized voting” where voters delegate to a contract and get rewarded with respect to delegated voting power. A contract could try to buy 1mil $DOT voting power by spending 100k $DOT and paying delegatees out by a factor of 0.1 per 1 $DOT of successfully casted vote. This is very controversial and straight illegal in democracies. In reality, nothing really prevents anyone from doing something like this today already via indirect means anyways. What are we gonna do, declare it illegal and call the OpenGov police, slashing accounts that can be proven to have participated in such a scheme? When the payment secretly happens off-chain or via some custody unwilling to comply?

Asset Hub

Take an airdrop contract with some claiming functionality. Spend 10 $DOT to create a Token on asset hub and endow that contract with some allowance. People proof their eligibility to claim and nullify their allocation with the contract. This costs creators way less than a badge transfer to millions addresses to distribute the token or fostering liquidity pools. At current market conditions, costs should be around 100 $USD for the issuer while transaction fees are outsource to the claimers. Very nice for community owned meme coins and such.

Except: Where to deploy that contract? There are contract parachains and they provide the necessary APIs to interact with Asset Hub. However, depending on a parachain instead of just using contracts on asset hub unnecessarily increases the complexity of developing and testing the contract. Claiming transactions are likely to be more expensive and the user experience is affected too because claimers need to interact with yet another parachain (and possibly buy the chains token first to pay the transaction). My perception is that in a space as competitive as web3 this is already enough to scare projects away.

Summary

I’d love to see contracts added to core protocol chain runtimes. Technically, anything that contracts can do, the parachain runtime (or a parathread for that matter) can do too. Permissionless deployments of code (contracts can be written in Rust, Solidity or Typescript) however remove entry barriers like writing a full runtime or going through OpenGov. Reducing the complexity makes innovating on and adding functionality to the core protocol more accessible. I think that low entry barriers inviting everyone to experiment with their craziest ideas is part of what made Ethereum very successful in the beginning.

Security-wise I argue that we’d only add opt-in functionality. Contract accounts are no different from other accounts apart from that they are governed by code. But maybe there’s more to consider?

If I understand correctly, JAM will address this anyways, but why not make the most out of the relay / parachains model in the meantime, testing the waters on Kusama first?

9 Likes

Hey Cyrill!

This is a great topic, thanks for bringing it up. The ability to deploy contracts on different system chains definitely open the doors for easier implementation of certain use cases, lowering the entry barriers and offering more options to the existing devs and the potential new ones.

Although, I think it is also important to mention that including those VMs to these runtimes brings overhead to their maintenance, and the new scenarios are to be taken into account into their threat models. This comment mostly originates from the point of view of our work on Pop Network, an “extension” to Polkadot where developers can deploy their contracts using DOT, and leverage Pop Network runtime as well as other parachain features through the pop-api. It would be difficult for me to imagine a devex similar to what pop-api offers being crafted for system chains runtimes, making contract developers continue to live in a world where they aren’t abstracted enough from the complex infrastructure they are trying to use when the moment of reaching features outside of the host runtime comes. **

This said, evolving these chains into hybrid chains might be attractive for use cases localized on functionalities these specific chains have, whereas bigger applications needing composability might benefit from a parachain focused on offering runtime features to contract developers in the nicest and most appealing way possible. All in all, the examples given here are very exciting, some of them definitely part our roadmap for pop-api, and I am personally looking forward to see what the community can create on top of them!

** I am thinking about who is gonna do and maintain integrations with other parachains if it makes sense to have them. The fellowship ? The parachain teams themselves would contribute their integrations to system chains ?
My concern is that contract developers might soon start requesting features that maybe are not that straight forward to provide.

EDIT: Typo + adding clarifications.

4 Likes

I am thinking in a similar direction as @Cyrill lately. The two opposing ways of thinking seem to be:

Hybrid Chain

Add contracts to existing chains to augment them with user programmability. Adding it to Asset Hub would be what comes to mind first as it will allow users to synchronously interact in their contracts with the assets there. I think this is something that would be of immediate use for many people I think.

The counter arguments are usually security and performance concerns as brought up by @alejandro. As well as that it contradicts the “one chain one task” idea of Polkadot. Which is, to be fair, mostly a performance concern because having more chains is the easiest way to scale as of right now.

Contracts Chain

Have a dedicated chain which doesn’t have any specific purpose except hosting contracts. Having all contracts in one place is beneficial because they can interact with each other synchronously. Having them in a separate chain also reduces the risk for an integral part as AssetHub to get congested or attacked by the broadened attack surface. However, I don’t see the performance benefits since having all contracts on a single chain will suffer the same performance benefits as putting it directly on AssetHub. Additionally, AssetHub could just confine contract execution time to a fixed part of its block.

What I think we should do

To me it is really not an either or. Short term allowing contracts on AssetHub is the most useful solution. Centralizing assets and contracts will no doubt provide the most value and lowest switching costs for Ethereum builders. It is most likely that this is the move that will give us the most traction in the short time. We should not be afraid of success (“AssetHub gets congested”). It if gets congested people can migrate their contracts to dedicated contracts chain in order to reduce costs. Which will be easy because they are running the same environment and assets can easily be transferred over via XCM. People will do that in order to save costs. Like they do switch to Ethereum L2’s.

But only if there is already a worth while ecosystem anyone would even care. We can’t expect them to go to a third party chain first. That is completely backwards. We have to put our horses behind a first party solution first (system chain) so that anybody even cares enough to look for third party scaling solutions. I firmly believe that the best candidate for a first party solution is a system chain. And more specifically AssetHub. We should not fragment the ecosystem more than we have to.

3 Likes