Allow Setting of EVM Address by EOA

[Nana-EC]

Description:
HIP 583 opened the doors for greater account compatibility with EVM flows by utilizing the account alias to encompass
the EVM address. However, given the static nature of the alias and concerns of complexity, existing accounts were not
allowed to update their alias and set one if it was null. This HIP aims to rectify this by allowing EOAs who have no
alias set to set it to an ECDSA key derived evm address value they own.

This HIP also replaces the need for HIP 631: Account Virtual Addresses as it
aimed to resolve this issue as well as provide even greater functionality. A form of HIP 631 could be revisited in the
future but not with the goal of providing address equivalence with the EVM.

Related issue(s):

Fixes #1070

Notes for reviewer:
1st draft, need to add a clarifying image and touch up

Checklist

• Documented (Code comments, README, etc.)
• Tested (unit, integration, etc.)

[netlify]

✅ Deploy Preview for hedera-hips ready!

Name	Link
🔨 Latest commit	6ab73e0
🔍 Latest deploy log	https://app.netlify.com/sites/hedera-hips/deploys/67608ccd4471f400080cc6b9
😎 Deploy Preview	https://deploy-preview-1082--hedera-hips.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[gregscullard]

Maybe add a suggestion that such accounts should first transfer all contract assets to the EVM address, then update the account's EVM address ?

[Nana-EC]

Updated

[ty-swirldslabs]

Great work! I added some clarifying questions to user stories section

[ty-swirldslabs]

In this user story, wouldn't the user have to update the ED key to the new ECDSA key that corresponds with the EVM address for 'ecrecover' to function? Maybe I'm misunderstanding the phrase 'correct ecrecover functionality', or is the implication that the key is being updated as well

[Nana-EC]

No, the user would just use their ECDSA key in a wallet to sign. So far as the EVM address can be extracted from the signature the ecercover flow would work

[ty-swirldslabs]

Same concern here as user story 1. Maybe we add the caveat to the stories, that the ECDSA signature that corresponds with the EVM address for ecrecover to function would need to be utilized on signatures for EVM of those transactions and not the key associated with the account on the hedera network.

[Nana-EC]

I'll add a clarifying user story so we aren't mixing these up

[Nana-EC]

Resolved

[ty-swirldslabs]

Is this out of scope / too complex for this HIPs user story?
As an existing account with an ED key but no EVM address alias, I would like to update my key to an ECDSA key and set my EVM address to be derived from the new ECDSA key.

[Nana-EC]

Out of scope, not too complex build would be enabled by this HIP and current network functionality.
Such a user could rotate their keys before or after setting the EVM address.
The could actually do it in one single CryptoUpdate also.
Key rotation is not tied to alias value

[rbair23]

I didn't think it was out of scope, but explicitly in scope. Key rotation is already supported as you said, and setting the alias if it was null is also in scope. So what @ty-swirldslabs is asking for should be a natural consequence of this HIP?

[rbair23]

I have made various suggestions for clarity and grammar. One material change: I have removed the ContractCreateTransaction from the list. I did not see any reason why we should support evm_address_override when creating transaction, only when calling them.

[rbair23]

Suggested change

	[HIP 583](https://hips.hedera.com/hip/hip-583) opened the doors for greater account compatibility with EVM flows by
	utilizing the account alias to encompass
	the EVM address. However, given the static nature of the alias and concerns of complexity, existing accounts were not
	allowed to update their alias and set one if it was `null`. This HIP aims to rectify this by allowing EOAs who have no
	alias set to set it to an ECDSA key derived evm address value they own.
	This HIP also replaces the need for [HIP 631: Account Virtual Addresses](https://hips.hedera.com/hip/hip-631) as it
	aimed to resolve this issue as well as provide even greater functionality. A form of HIP 631 could be revisited in the
	future but not with the goal of providing address equivalence with the EVM.
	Permits accounts without an alias to set one.

[rbair23]

Suggested change

	The EVM address alias introduced in HIP 583 allowed for ECDSA based accounts to interact with the EVM in the same way
	other EVM chains do. Particularly, functionality like the `ecrecover` that relies on the relationship between key and
	address (pivotal to many DEXs) was unblocked and allowed greater EVM equivalence on the Hedera network.
	However, HIP 583 intentionally provided no solution for accounts with no alias regardless of key type (ED, EC or
	complex keys). Though these accounts were afforded the hedera num account alias (long zero), this format would not
	allow accounts to utilize the `ecrecover` precompile in the expected manner.
	This continued incompatibility has remained and inhibited web3 EVM tooling support.
	Providing a solution to this gap is a necessity to make it easy for EVM dApps in the web3 community to come to
	Hedera without needing to change their smart contracts.
	On Ethereum, every account is addressed by an address which is derived from an ECDSA public key. The
	EVM also has a specific instruction, `ecrecover`, that given an ECDSA signature can extract the public key
	and convert that public key into an address. This allows an EVM program to figure out the address of
	transaction signers.
	Hiero accounts are not limited to ECDSA keys, and Hiero accounts can rotate their keys. Both of these
	features are not found in Ethereum Externally Owned Accounts (EOA), and present some conflict with the
	`ecrecover` operation. The EVM address alias introduced in [HIP-583](https://hips.hedera.com/hip/hip-583)
	was added so that accounts could be created that augmented their account administration key (typically
	referred to simply as the "account key" or "key"), with an EVM compatible "alias". This alias could match
	exactly what an address would be on Ethereum. The user could call a smart contract, signed with the
	private key associated with their alias, and the smart contract could use `ecrecover` to recover the public
	key, derive the alias, and lookup the account.
	However, not all accounts on Hedera use ECDSA keys or were created after HIP-583 was defined. This HIP
	adds support for specifying an alias on an account, even if it already exists, so long as that account does
	not already have an alias. [HIP-631]((https://hips.hedera.com/hip/hip-631) defines a more complex set of
	rules that would allow multiple aliases to be defined for any given account. This HIP differs from HIP-631 in
	that it supports only a single alias. HIP-631 could be implemented compatibly at a later date if desired.

[rbair23]

Suggested change

	[HIP 631: Account Virtual Addresses](https://hips.hedera.com/hip/hip-631) 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 offered feature rich complexity that may be difficult for DApps, wallets and
	users to follow completely.
	Instead of the full HIP 631, an intermediate approach i.e. a HIP 631 Lite (this HIP) could unblock users without an
	EVM address. It would enable accounts to interact with the EVM in a compliant manner regardless of the public key on
	its account.
	In a sense the current network already supports the ability to set the evm address, it just requires the logic to be
	done on account creation. Thus by lifting the limit of not being able to set the alias after account creation, whiles
	still requiring that the current alias be unset this HIP ushers in the ability for those previously blocked accounts to
	interact with the EVM as expected.
	[HIP-631: Account Virtual Addresses](https://hips.hedera.com/hip/hip-631) lays out the challenges faced by
	accounts without an ECDSA derived EVM address that want to interact with the EVM in a compatible way while still
	supporting key rotation and complex keys. While HIP-631 may be a comprehensive solution to the problem, it
	requires complex user flows in wallets that may cause more pain than it resolves.
	Instead, an intermediate approach i.e. a HIP 631 Lite (this HIP) could help users without an EVM address. It would
	enable accounts to interact with the EVM, even contracts using `ecrecover`, regardless of the public key on its account.
	In a sense, the current network already supports the ability to set the EVM address, it just only works during account creation. Thus, this HIP allows those previously created accounts to be updated and interact with the
	EVM as one would expect.

[rbair23]

Suggested change

	The following are some clarifying concepts to increase clarity around aliases
	- 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 interacts with the EVM
	Every account in Hiero has a 20-byte EVM alias by default. It is created **not** by using the key on the account,
	which may change, but by computing a "long-zero" alias by taking the account ID (such as 0.0.1234) and
	converting it into a 20-byte representation.
	Given any account, you can send HBAR, or Tokens, to any other account by using either its Account ID, or by using
	its built-in long-zero alias.
	A user may specify an alias **in addition to** the long-zero alias. This additional alias is typically based on an
	ECDSA key, exactly the same way as it is done in Ethereum. This key may, or may not, be the admin key on the
	account. But to use this alias, the user must assert they own the key by signing the transaction that sets the alias
	with the corresponding private key of that alias, to prevent "alias squatting" by malicious actors.
	When a user interacts with a smart contract, if a user-defined alias based on ECDSA is present, it will be used as
	the address by which the smart contract interacts with the account. The smart contract will not be able to use
	the long-zero address. If the account does not have a user-defined alias based on ECDSA, then the long-zero
	alias will be used to represent the account in the smart contract system.
	Accounts with user-defined aliases based on ECDSA work with smart contracts that make use of `ecrecover`.
	Accounts that work with smart contracts using their long-zero address will not work with smart contracts that
	use `ecrecover`.
	Smart contracts can, and frequently do, store in state the EVM address of accounts that use the smart contract.
	For this reason, smart contracts **will not work** with accounts whose EVM address changes. This is why
	the user-defined alias cannot be changed after it has been set, since this has become the address by which
	contracts will refer to the account.
	Due to this fact, the user must always sign contract calls with the key associated with the user-defined ECDSA
	alias, and must never lose that key. If for any reason the key must be rotated, all value in the account must be
	transferred to a new account, possibly incurring custom fees for HTS tokens. This is the same as how it works
	on Ethereum.

[rbair23]

I didn't think it was out of scope, but explicitly in scope. Key rotation is already supported as you said, and setting the alias if it was null is also in scope. So what @ty-swirldslabs is asking for should be a natural consequence of this HIP?

[rbair23]

Suggested change

	Smart contracts have their logic self contained in byte code. Therefore, the implications of address changes are
	dictated by each smart contract and not the network. A smart contract may cache an EOA address on first interaction and
	utilize that to identify them in future. The cached address could dictate balance access or other privileged access.
	As such, an EOA that has interacted with a smart contract using their long zero address and then sets an ECDSA derived
	EVM address after will be responsible for any unexpected interactions with the smart contract.
	It is advised that an EOA in this case first transfer all in contract storage assets to the EVM address prior to
	setting their alias.
	None.

[rbair23]

Suggested change

	SDK examples, blogs and tutorials on docs.hedera.com
	SDK examples, blogs and tutorials on docs.hedera.com. We recommend updating all samples and tutorials to use
	ECDSA derived aliases in all cases with the matching ECDSA key being used as the account admin key, as this is
	the expected normal flow. We strongly recommend only **advanced** users set the alias on existing accounts,
	and only once their wallets support it. Otherwise, we recommend setting an alias on an existing account only be
	undertaken by wallets or dapps that pre-create accounts but never use them, until given to a user where the alias
	and key are then set.

[rbair23]

Is this true? I thought 631 allowed having multiple aliases, and thus would support going from null to an alias as well. The only problem with 631 was that it was complicated by having multiple aliases, and we decided to try a simpler approach with just 1 alias (in addition to the long-zero).

[Nana-EC]

HIP 631 specifically reserved a different space in state for the multiple virtual addresses but maintained a single account.alias field as immutable

With Virtual Addresses, keys remain the signing permission authority and can be changed but Virtual Addresses (not tied to the alias) provide the value for a transactions EVM address.

Pulled from HIP 631, also the account diagram notes virtual addresses as a different field altogether. We never stated the ability to set a the null alias, so even with multiple virtual addresses an account could still have a null alias

[rbair23]

Either we should remove this or list the open issues.

[rbair23]

It would be good to add the references to the other HIPs.

[stoqnkpL]

Its important to consider two things:

1. From an ecosystem perspective, having a single real-world user appear as multiple distinct participants can break the expected user flows. DApps, wallets, and explorers might show contradictory data about the user’s “identity,” transaction history, or holdings. For example, if I own some amount of token X as my long-zero address, and some amounts of token Y (or even the same token X) as my newly-set alias, my wallet should be able to detect those and display both, then know how to generate transactions that operate with those balances. Explorers should index events from both addresses and associate them to the same account.
2. The EVM should handle edge-case scenarios that will now be possible where for example I attempt to transfer HBAR from my long-zero address to my new alias address, both pointing to the same hedera account.

[Nana-EC]

Its important to consider two things:

1. From an ecosystem perspective, having a single real-world user appear as multiple distinct participants can break the expected user flows. DApps, wallets, and explorers might show contradictory data about the user’s “identity,” transaction history, or holdings. For example, if I own some amount of token X as my long-zero address, and some amounts of token Y (or even the same token X) as my newly-set alias, my wallet should be able to detect those and display both, then know how to generate transactions that operate with those balances. Explorers should index events from both addresses and associate them to the same account.
2. The EVM should handle edge-case scenarios that will now be possible where for example I attempt to transfer HBAR from my long-zero address to my new alias address, both pointing to the same hedera account.

Fair points. I think these are all handles by existing logic

For example, if I own some amount of token X as my long-zero address, and some amounts of token Y (or even the same token X) as my newly-set alias, my wallet should be able to detect those and display both, then know how to generate transactions that operate with those balances. Explorers should index events from both addresses and associate them to the same account.

Agreed, a wallet would have knowledge that an account has a long zero and evm address and it would also be avle to query the contract state for both addresses e.g. balanceOf fro ERC20's in both cases

2. The EVM should handle edge-case scenarios that will now be possible where for example I attempt to transfer HBAR from my long-zero address to my new alias address, both pointing to the same hedera account.

Good point, the node should handle self transfer in the same way it does today

[Perseverance]

I agree with this HIP's proposed solution and believe it is the right way to address many possible issues.

However, I would like to highlight that the rationale and, therefore, the impact of this change are likely less severe than they appear.

Firstly, I strongly believe that the ecrecover precompile should not be modified and its behaviour should be kept the same as Ethereum. ecrecover is meant to be a pure cryptographic function - a stateless black-box one. The rationale mentions that this HIP will enable ecrecover to "work". I believe that ecrecover works exactly as intended right now.

The real reasoning behind this HIP, for me, comes from the use-cases of ecrecover rather than the inner workings of ecrecover. Many Ethereum applications use "signed-message"-based authorization - Based on a signed message by the user, the dapps enable certain actions to be authorized on the behalf of the signing user. The most famous example is the ERC20 add-on - ERC-2612 - commonly known as "permits". In this use-case the owner of certain amount of tokens, signs a message authorizing another user to use them.

This HIP solution will help enable this use case, but it is not because ecrecover is somehow broken, but because it will enable our users with non-ecdsa keys to set their ecdsa representing addresses, therefore be eligible to use this authorization scheme.

In respect of fairness, it is important to highlight the negative side-effects of this change. As @rbair23 pointed, this change, and our aim to support the "signed-message"-based authorization is in fact leading to hard-coupling between user and their ECDSA keys. This disables the much desired key rotation.

[Ferparishuertas]

From an evm perspective, this is the most compatible version, and allows the signed message schemes at smart contract level. That said as @rbair23 and @Perseverance mention, this intermediate HIP is a step forward, but we need to keep an eye on HIP -631, to enable alias rotation, or multiple evm adressess alias to identity/account mappings.

Apologizes in forehand for next comments, if there is anything out of context.

As a newbie, I want to suggest some extra adds to the context to make the HIP more comprehensive, added to a question

• Make it clear, that the alias (derived evm address) is unique and cannot be used within more than 1 account
• Separate the concepts of key rotating and alias. Documentation indicates the following:

"If an alias is set during account creation, it becomes immutable, meaning it cannot be changed. If you plan to update or rotate keys in the future, do not set the alias at the time of initial account creation. The alias can be set after finalizing all key updates."

[steven-sheehy]

Should stay on one line so github doesn't complain about invalid yaml when rendering.

[steven-sheehy]

null is a bit of tech speak

Suggested change

	allowed to update their alias and set one if it was `null`. This HIP aims to rectify this by allowing EOAs who have no
	allowed to update their alias and set one if it was missing. This HIP aims to rectify this by allowing EOAs who have no

[steven-sheehy]

This name seems ambiguous to me. It could be the address of the contract or the sender. What about from like in eth_call? Or other alternatives like from_address or sender?

[steven-sheehy]

This doesn't mention changes around processing contract call and create.

[steven-sheehy]

I still don't understand why the HIP allows them to set an ECDSA derived EVM address on their existing account but then it doesn't allow them to use this new value on contract calls and instead requires the long zero form.

And even if Hedera Num Alias is required, why would they specify it as long zero bytes instead of just using AccountID in shard.realm.num?

[steven-sheehy]

Can we detail any API changes? My assumption that there's no new fields but that existing fields in /api/v1/accounts/{id} will show the updated evm_address and the existing from in contract result APIs will show the override?