HIP 631 Lite: Support setting ECDSA derived alias on account with no alias

[Nana-EC]

HIP 631: Account Virtual Addresses lays out the challenges faced by accounts without an ECDSA derived EVM address that want to interact with the EVM in a way that complies with the Hedera native model and the EVM model.

However, HIP 631 offers feature rich complexity that may be difficult for DApps, wallets and users to follow completely.

Instead of the full HIP 631, an intermediate approach (HIP 631 Lite) that would allow users without an EVM address to add one may be possible to enable that account to interact with the EVM in a compliant manner regardless of the public key on its account.

Foundational Concepts

• Every account on the network has 1 or 2 evm addresses. Either only the Hedera num alias (long zero) or the Hedera num alias (long zero) and an EVM address alias (standard ECDSA derived EVM address).
• When a user interacts with the EVM the network will utilize the ECDSA derived EVM address alias on an account if present. If not it will utilize the long zero
• Accounts with an ECDSA derived EVM address are fully compatible with expectations of contracts that utilize the ecrecover precompile.
• Accounts without an ECDSA derived EVM address alias will not match the expectation of the ecrecover precompile calculations. This has effects on certain DApp behaviour
• Smart contracts can and do cache the evm address of an account and often use it to assign attributes such as access and ownership. As a result it was important to maintain a static alias to avoid unintended differences in expectation
• Account key rotation has no impact on the evm address utilized when an account interact with teh EVM

Suggested Changes

• CryptoUpdate transaction should support the addition of an ECDSA derived address alias to an account that doesn't have one in a manner that proves ownership of the associated ECDSA private key. Currently this is not supported as we make alias static even when unset. This change should be minor as we'll only support the setting if no alias is set in account state. This allows all accounts without an evm address to morph their account into a fully EVM compatible account. With this wallets have a predictable set of address options to utilize for user transaction submissions

message CryptoUpdateTransactionBody {
    ...

    /**
    * EOA 20-byte address to create that is derived from the keccak-256 hash of a ECDSA_SECP256K1 primitive key.
    */
    bytes evm_address = 19;
}

• ContractCreate and ContractCall must support the ability to designate the desired evm address to use

message ContractCreateTransactionBody {
    ...
    /**
    * The 20-byte EVM address to use for the given transaction. This address must be the Hedera num alias of the account.
    */
    bytes evm_address_override = 21;
}

message ContractCallTransactionBody {
	...
    /**
    * The 20-byte EVM address to use for the given transaction. This address must be the Hedera num alias of the account.
    */
    bytes evm_address_override = 5;
}

• Add a setEvmAddressAlias() HAS system contract proxy function that would allow accounts with an ECDSA key but no alias to set their alias via an EVM wallet/tool. This would expose the CryptoUpdate HAPI transaction using the evm address provided by the EVM wallet/tool and verifying using the provided ECDSA based transaction signature.

User Flow Impacts

• When submitting an EVM transaction (ContractCreate or ContractCall) a user could specify in their wallet which EVM address is intended in the transaction. If the ECDSA derived address they must sign the transaction with the associated private key
• Key rotation will continue to be supported but wallets are encouraged to discourage rotation once an ECDSA derived evm address is set
• A user may have to manage an additional cryptographic offline key if they add an ECDSA derived alias without also rotating keys
• Once an account sets a valid non-null alias it cannot change it. This is consistent with current network behaviour

Wallet Flow Impacts

• Wallets are encouraged to create accounts with an ECDSA derived address alias
• Wallets are encouraged to support the ability for users to an ECDSA derived alias in the future