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.