Adds SDK method suggestions and addresses suggestions from hendrikebb…

…ers and IvanKavaldzhiev

Signed-off-by: Nana Essilfie-Conduah <nana@swirldslabs.com>

HIP/hip-1082.md

@@ -11,16 +11,17 @@ needs-council-approval: Yes
 status: Draft
 created: 11-18-24
 discussions-to: https://github.com/hashgraph/hedera-improvement-proposal/discussions/1070
-updated: 12-06-24
+updated: 12-16-24
 replaces: 631
 requires: 583
 ---
 
 ## Abstract
 
-HIP 583 opened the doors for greater account compatibility with EVM flows by utilizing the account alias to encompass
+[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
+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
@@ -110,8 +111,8 @@ message CryptoUpdateTransactionBody {
 ```
 
 Additionally, `ContractCreate` and `ContractCall` EVM transactions will need to support the ability to specify the
-a Hedera Num Alias alias EVM address to use on the transaction. This is because on the HAPI side all aliases are
-applicable and thus the flexibility of the API is important to maintain.
+Hedera Num Alias address to use on the transaction. This is because on the HAPI side all aliases are applicable and
+thus the flexibility of the API is important to maintain.
 Also, accounts that previously had no ECDSA derived EVM address were likely created via the HAPI flow and it may
 be important for an EOA to utilize the long zero address even after setting a new ECDSA derived EVM address.
 For transactions that utilize the `EthereumTransaction` a compliant ECDSA derived EVM address is provided by default
@@ -149,6 +150,15 @@ SDKs will need to update the `AccountUpdateTransaction` to support the `setAlias
 `ContractCreateTransaction` and `ContractExecuteTransaction` will need to support a new `setEVmAddressOverride()`
 function to set the `evm_address_override` property on the respective `ContractCreate` and `ContractCall` transactions. 
 
+In addition to updated `AccountUpdateTransaction` functionality the SDK will want to add new methods to streamline
+account key specifications by developers with considerations for alias
+
+- `setKeyWithAlias(ECDSAKey)` - Explicitly calls out the alias set and converts public key to address in the background
+- `setKeyWithAlias(Key, ECDSAKey)` - Allows for setting the account key and a separate key that the evmAddress should
+    be derived from. A user must sign the transaction with both keys for this flow to be successful.
+- `setKeyWithoutAlias(Key)` - Explicitly calls out that the alias is not set. This is useful for wallets that create
+    accounts with default keys and rotate keys later.
+
 ### Mirror Node
 
 Mirror Nodes should be sure to support the setting of the evm address value on an account when processing a