In the Moonbeam Unified documentation here, it says that Moonbeam natively supports "Ethereum-style address (H160 format), which is 40+2 hex-characters long, in a Substrate based chain" and ECDSA keys.
If I create an a Moonbeam account using Polkadot.js by following their documentation here, by enabling in-browser account generation and storage here, then create a Moonbeam account here, and then select private key instead of mnemonic seed, it generates a Public key (hex) account 0xc_____ that is 40 chars long (formatted as hex with the 0x prefix providing an +2 extra chars), which corresponds to the "40+2 hex-characters long" "Ethereum-style address (H160 format)" address mentioned in the Moonbeam documentation that provides Ethereum compatibility on the Moonbeam Substrate-based parachain. It is accompanied by an associated "ethereum private key" 0xy_____ that is 64 chars long, "which can be used to sign transactions in the Ethereum side of the chain", for Ethereum-side EVM functions like balance and smart contract interactions. This Moonbeam address "is mapped into a storage slot inside the Substrate Balance pallet to a Substrate-style address (H256 format)", however I can only know "the private key of the H160 address, and not of the mapped version. Therefore, she is unable to send transactions with her H256 address and is limited only to do read-only operations through Substrate’s API". So they say I need another Substrate-style address (H256 format) matching a different private key to be able to operate in the Substrate-side of the Moonbeam parachain, to be able to sign transactions for balance interactions, staking, and governance, and it would need to maintain a minimum account balance (existential deposit).
The Moonbeam Unified documentation here then says that the solution for that is with Moonbeam Unified Accounts where I "will only need a single H160 address, with its corresponding private key, to do everything we mentioned above, including both EVM and Substrate functions.", so there is only one associated private key necessary, the account has no existential deposit requirement, and that single account can interact with EVM, non-EVM, and Substrate native assets like Moonbeam's native GLMR token.
Based on reviewing Discord discussions I found Moonbeam admins saying that they achieved that by changing the underlying Substrate layer accounts to be Ethereum-like, so on Moonbeam you only use need to use a single account to make Substrate and web3 RPC queries since they map to the same storage. They say the "unified accounts feature makes accounts and keys Ethereum-like on Moonbeam/Moonriver to reduce friction for EVM compatible projects to deploy on Moonbeam/Moonriver" since they say they are "solely focused towards improving and specializing in an Ethereum compatibility feature set, along with being a developer-centric platform. This includes adding tools like Solidity based smart contracts, Metamask, Truffle, Remix, Hardhat, a fully functional EVM, web3 RPC's".
But I don't understand why when I generate a Moonbeam account with subkey it generates an output like the following example:
docker run -it --pull=always docker.io/parity/subkey:latest generate --network moonbeam --scheme ecdsa
Secret phrase: ___ ___ ___ ___ ___ ___ ___ ___ ___ ___ ___ ___ (default is 12 words)
Network ID: moonbeam
Secret seed: 0xz_____ (64 chars long, formatted as hex)
Public key (hex): 0xb_____ (64 chars long, formatted as hex)
Account ID: 0xb_____ (same key as above)
Public key (SS58): V_____ (49 chars long, formatted as hex)
SS58 Address: V_____ (same key as above)
This doesn't look like a Moonbeam Unified Account since the Public key (hex) would need to be a "40+2 hex-characters long" "Ethereum-style address (H160 format)" address that was mentioned earlier. However, the Public key (hex) is 64 characters long, formatted as hex (+2), so it is still just the Substrate-style address (H256 format), where the Moonbeam SS58 address type prefix is V. If I then run subkey inspect --public 0xb_____ I can view its SS58 address on the default Substrate network that uses Substrate SS58 address prefix of 5.
My first concern was that the private key may only be able to operate on the Substrate-side of the Moonbeam parachain, but not be able to interact with the Ethereum-side of the chain, which would be an inconvenience. So I tried to import the account that was generated with Subkey into Polkadot.js by going to https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Fwss.api.moonbeam.network#/accounts, and clicking "Account", but when I entered the Subkey generated "Secret phrase" into the "mnemonic seed" label input field it returned a different Public key (hex) than was generated by Subkey, and when I entered the Subkey generated "Secret seed" into the "ethereum private key" label input field it also returned a different Public key (hex) than was generated by Subkey. I even tried using Metamask, connecting to Moonbeam, and entering the Subkey generated "Secret phrase" into the "Private key" field", but that also returned a different Public key (hex) than was generated by Subkey. I think that maybe Polkadot.js Apps should be updated so the "mnemonic seed" input field label should say "ethereum mnemonic seed".
For context, in the past I have simply created Moonbeam accounts on the Ethereum Network (Ethereum-style H160 address) and successfully used that for nominating collators on Moonbeam. Let's say for example one of those addresses was 0xa_____, I can go to https://etherscan.io/address/0xa_____ where it shows my balance of ETH, ERC-20 tokens, and ERC-721 NFTs, and in the "Multichain Address" section it says "1 address found via Blockscan", and if I click the link it leads me to https://moonscan.io/address/0xa_____, where it shows my balance in GLMR. I can also import that 0xa_____ address into https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Fwss.api.moonbeam.network#/accounts. And lastly, I can go to https://sub.id/0xa_____/balances and it shows only my GLMR and MOVR balance associated with that account, but not my account balance on other chains that are using the ethereum private key associated with that address, like my ETH balance, and not the balance of my accounts on other Substrate-based chains like DOT.
Also in the Moonbeam documentation here they show numerous options of how to generate an Ethereum address for the Moonbeam network using its unified account system, where they say "if you have an existing Ethereum account AND its associated private key, congrats! You already have a valid Moonbeam address". But Moonbeam doesn't mention Subkey as an option.
Question: So since Subkey is one of my favourite tool for generating keys for Substrate-based chains. My question is, why doesn't Subkey appear to generate a Moonbeam Unified Account when I specify those options in the Subkey CLI, is it because Subkey CLI is only generating Substrate-based private keys instead of ethereum private key that is necessary? And if it doesn't generate a Moonbeam Unified Accounts, what is the purpose generating Moonbeam network accounts using Subkey that aren't Moonbeam Unified Accounts, is it just a legacy option that only worked prior to the introduction of Moonbeam Unified Accounts? And also in that case, shouldn't the subkey generate ... --network moonbeam and --network moonriver options be removed until such time as it supports Moonbeam Unified Accounts?
The reason for the concern is if someone didn't follow the Moonbeam instructions and generated what they thought was a valid Moonbeam account with subkey generate --network moonbeam --scheme ecdsa, and then sent some GLMR tokens to the associated Public key (hex), how would they be able to access those GLMR tokens or wouldn't they be recoverable unless Moonbeam switched back to supporting the Substrate-style address (H256 format), or does the Moonbeam network work similar to the Acala network which automatically binds accounts, if that's the case and GLMR tokens were sent to a Substrate account on the Moonbeam network without an associated H160-format Ethereum EVM address, an EVM address would be automatically generated and bound with that Substrate account. But if that was the case, how would the sender be notified about the automatically generated H160-format Ethereum EVM address that the tokens were sent to, and how would the recipient discover the list of H160-format Ethereum EVM addresses that have been bound to their Substrate account?
