Hybrid system chains make Polkadot permissionless

Tech Talk
1

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?

11 Likes
2

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
3

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.

5 Likes
4

@Alex I put together this RFC #66 – but since @burdges says Contracts Update: Solidity on PolkaVM supersedes this RFC and polkavm contracts should definitely work, there might even be consensus on this. However, I think its best if you + @Cyrill put an RFC together to crystalize it your way this month?

What is the hold up if not?

5

Yes I agree that this supersedes your RFC. We should not deploy pallet_evm as it does not improve enough on the status quo. We have this potentially much better solution on our hand that barely drops any compatibility when compared to frontier while offering orders of magnitude speedup for computation heavy benchmarks.

The RFC should look something like this:

  1. pallet_contracts
  2. Ethereum RPCs
  3. EVM (YUL) → PolkaVM recompiler

I am up for writing this RFC.

We are in the middle of checking for the technical feasability. Improving the recompiler, PolkaVM and benchmarking all of that. For example, we are still lacking 64bit support in PolkaVM which is crucial for efficient code when recompiling from a 256bit machine like EVM. We are expecting a certain improvement but can’t benchmark it, yet. But I think we are sufficiently confident that we can defeat EVM in each use case. Large contracts that barely execute any code (think getters) were a problem. But now with the lazy interpreter of PolkaVM we are even winning there in most cases. 64bit support will be the final nail in the coffin. In computation we are already seeing 100x speedups vs. native EVM execution with 32bit PolkaVM. But we also must not regress in those other cases.

But when writing the RFC it is important that we have all the data to make a good case.

3 Likes
6

May I recommend you conceive of your RFC of setting a direction for system chains similar to RFC #32 and presenting your initial benchmarks rather than collecting everything you want?

This is a “perfect is the enemy of the good” type pragmatic request: Its not necessary to get 100x to 120x, but to merely chart a course for others to participate and accelerate the process. It is understandable to want proper 64bit/256int support to cover like “basic” EVM cases behind ERC20/721 (and then Uniswap v2, Curve, etc.). But I believe a first RFC draft will allow many others to come together to develop a very wide range of garden variety [probably defi-centric] test cases, and deploying a v0.01 on AssetHub for Paseo may accelerate.

Many other stakeholders will have questions quite outside benchmarking, from how Frontier smart contract chains could participate (Moonbeam/Astar => POP/Magnet) to how PVM contract-pallets relate to logs, traces, etc. and then how JAM’s Services architecture relate to this.

I hope you don’t see the magnum opus of the Gray paper as the standard to get started, it only has to be “semi-coherent” =)!

1 Like
7

I am strongly in favor of adding smart contract functionality to system chains, and wherever possible, limiting the quantity of system chains.

We should not be afraid of success (“AssetHub gets congested”)

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.

This basically sums up my feeling on the topic: would we rather be “right” (in a vacuum) or have activity? The practical scaling limits of a single parachain post-asynchronous-backing are in the thousands of transactions per second. That’s more than enough to handle all of the current activity on Polkadot, Ethereum, all Ethereum L2s, most of Cosmos, in a single chain, and coupled with a much better user and developer experience. AssetHub reaching its limit would be an excellent problem to have, and this would create organic pressures to grow.

“Decentralization is a symptom of degeneration and decay only if it leaves a vacuum behind. Where decentralization is the product of centripetal forces, it is healthy.”
- Richard Ratcliff, as quoted in The Death and Life of Great American Cities

8 Likes
8

We decided to go the route of a public referendum instead of an RFC to check if there is token holder support for the plan: Should we allow EVM compatible contracts on Asset Hub? | Polkassembly

3 Likes
9

@Alex Thank you!

I can’t help but ask: if there was a substantial investment to help this effort succeed, like 100K vs 300K vs 1MM DOT, what would you (@alex but also @Cyrill @koute) want use it for to accelerate progress, both before “end of 2024” and through early 2025?

You enumerated how the community could help the effort

  • Tooling and Integration
  • Marketing
  • Communication
  • Education
  • Liquidity from Ethereum

but it probably will help if you led the way in diving in with more specific details.

10

This is a great initiative! It’s inspiring to see such things pushed forward for the good of the ecosystem.

On the technical side, how do you envision solving the problem of different crypto primitives and account address formats? While on a custom parachain one could have Ethereum standards of these implemented (the path taken by Moonbeam), AssetHub will definitely stay on Substrate-flavored crypto.

In Acala, this is solved via account binding. Do you want to implement a similar mechanics, or do you have any other solution in mind?

11

I am not in expert in most of these fields. This is why I had to leave it vague for now. However, there is one thing where I have a more refined opinion: We need developer tooling support. At least a Remix and a Hardhat plugin. Due to the different bytecode (PolkaVM instead of EVM) they won’t work out of the box. The plugins would handle at least compilation (by using our compiler) and deployment (works differently than on EVM).

So if you ask me right now I would say: I would fund two teams (or one team doing both) to develop those two plugins. zksync has written those plugins [1][2] for their product which is very simillar to what we are doing (they recompile to a zk circuit instead of RISC-V). This makes me optimistic that it will also work for us.

There is a proposal to develop a new IDE similar to Remix. I am not against a custom solution if it can improve over existing ones. However, I still think we need the plugins so people can use a development environment they are used too.

You are right: We need to support blockchains with a different address format than what Ethereum uses as we can’t migrate AssetHub. So it is clear that we will support Eth keys in addition to the currently in use ed25519.

I am trying to think of a solution that avoids the manual mapping process that Acala uses. Instead, I just want that one private key represents two addresses. This is the same case as when you don’t specify a manual mapping on Acala.

Why do we need the manual mapping: It is a solution for the problem that different Dapps use different libraries (eth3.js vs Polkadot.js). Those require different wallets (Metamask vs. Subwallet) which in turn use different private keys. In order to use both Dapps with one account Acala allows you to change the mapping so you have two keys controlling the same account. Otherwise you can either use Dapps written for Ethereum or Polkadot.js Apps depending on the private key you are using.

I think we can avoid the manual mapping. Let’s think about it as user stories. I mean this literally. It is not about developers but actual end users of the block chain:

An Ethereum user who who just wants to use a Solidity Dapp on AssetHub

Those will have Metamask installed and can just use the Dapp as if it was on Ethereum with their existing private key or a new one. This is a friction less experience for them as it works exactly the same as on Ethereum. This is very important as those users don’t care about Polkadot and asking them to install another wallet or plugin will probably don’t go well. It also requires no changes to Metamask which is important as we have little control over it.

An Ethereum user that gets interested in using Polkadot features

They have Metamask and already used some Solidity Dapps on AssetHub. Now they want to use that same account with Dapps written using Polkadot.js. Like for example in order participate in staking or governance. Those users are already pretty much engaged and we can probably ask them to install a Metamask Plugin or a Substrate native Wallet. The key inside here is that we can allow all transactions to be signed with an Ethereum private key instead of the native key. Even those delivered through native Polkadot RPCs as opposed only those coming through the Ethereum RPC compat layer.

This will require some changes to Polkadot Wallets namely injecting Eth accounts into Polkadot.js Dapps and supporting this additional transaction format. But this is okay as those changes are small and it is realistic that Polkadot wallets will implement them. For example, Subwallet already supports Ethereum keys. So it is probably not a giant task to also inject them into Polkadot.js dapps.

Existing AssetHub users or Polkadot Enthusiasts who want to use a Solidity Dapp

Those will have a wallet like Subwallet installed and have an existing account using the existing AsetHub native address format. The problem is that Solidity dapps are using web3.js which requires an Ethereum private key. My idea here is to make a change to Polkadot Wallets: Subwallet would inject Polkadot keys for web3.js Dapps. It would look like an Eth address to the Dapp. Subwallet will then sign the Eth transaction with a Polkadot key.

tl;dr

We can probably avoid a manual stateful mapping by accepting Eth transactions with Polkadot signatures and Polkadot transactions with eth signatures.

3 Likes
12

Alright, on developer tooling support, as part of the ink!ubator bounty last summer we did a ChainIDE+Polkaholic integration:

Because of Astar focus changes, we weren’t sure where to take it next, but what do you think of adapting ChainIDE to support AssetHub’s contracts-pallet? Basically if you have the Solidity-to-PVM compiler ready (ready enough), we can totally get the ChainIDE integration for Paseo/Kusama/Polkadot Asset Hub (instead of Astar/Shiden/Shibuya) in the same way this summer/fall, complete with Solidity-to-PVM templates.

This can prep us to do the same for JAM PVM code in early 2025 (with authorization/refine/accumulate/ontransfer PVM invocations, work packages/items/judgements/…). We would support by getting Polkaholic.io [currently turned off] in a AssetHub-with-PVM-centric way [in Q3/Q4 2024] + then a JAM explorer [in 2025], where we imagine people need a JAM Services IDE.

I suspect you likely strongly prefer Remix + Hardhat plugins, but would this be useful to execute on? Will follow through with it if so.

13

Yes I think those plugins are basically a requirement. If we want to make this attractive to Solidity Devs we need to support their tools. Luckily they allow for extension. I can understand that it is more exciting to create a new tool. But I think it will forever play catchup with existing tooling as they just have more resources. Remix and HardHat have more users and more resources and will get better faster than we can built. We should tap into this.

Block explorer support would of course be great but it will be much easier to add support to a Eth centric explorer. Substrate centric ones like Polkaholic do not decode inputs to contracts. Contract verification is needed to show the source code and decode inputs to a contract. This is a big feature. It will be much easier to add support to for example Blockscout and host an instance of that.

Just minor changes need to be done in order to support PolkaVM:

  1. The contract source code verification needs to use our compiler for verification. We need to make sure it is deterministic :slight_smile:
  2. We use a different transaction for contract deployment. This needs to be supported.

Those are very minor changes. Eventually, it is also probably worth exploring to contract the Etherscan people to support AssetHub: Etherscan Explorer Services

1 Like
14

Alright, will do – I believe its best to skip blockscout and just go for the industry standard, anything less looks too scrappy for the Solidity devs, 10x more so than the Remix/Hardhat plugin since its “user facing”. When does { Paseo, Kusama, Polkadot } Asset Hub (all 3 of them) get contracts-pallet so we can follow through with it?

When will the “standard” RPC calls (logs/receipts + traces) be ready on Paseo Asset Hub?

Can you all present your results @ DevCon 7 in November:

Would be great to have a JAM implementers workshop that week.

15

@alex @Cyrill @koute

Applications due July 30.

16

Congrats @Alex ! #885 passed =)