# Hybrid system chains make Polkadot permissionless **URL:** \ **Category:** Tech Talk\ **Created:** [March 29, 2024, 11:39am UTC](https://forum.polkadot.network/t/hybrid-system-chains-make-polkadot-permissionless/7089 "2024-03-29T11:39:52Z")\ **Posts on this page:** 1\ **Showing post:** 11
**Author:** ![Alex](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/alex/32/765_2.png) [@Alex](https://forum.polkadot.network/u/Alex)\ **Post date:** [June 21, 2024, 6:56pm UTC](https://forum.polkadot.network/t/hybrid-system-chains-make-polkadot-permissionless/7089/11 "2024-06-21T18:56:57Z")
> [@sourabhniyogi](#): > > 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? 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](https://github.com/matter-labs/hardhat-zksync)][[2](https://github.com/NethermindEth/zksync-remix-plugin)] 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](https://forum.polkadot.network/t/polkavm-solidity-ide-project-proposal/8657) 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. > [@sasha](#): > > On the technical side, how do you envision solving [the problem](https://forum.polkadot.network/t/ethereum-rpc-compatibility-for-polkadot-smart-contracts/7375#chain-layer-5) 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](https://guide.acalaapps.wiki/general/address-binding). Do you want to implement a similar mechanics, or do you have any other solution in mind? 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. --- _[View the full topic](https://forum.polkadot.network/t/hybrid-system-chains-make-polkadot-permissionless/7089)._