Accounts, Signature Verification & Keys (ECDSA vs. ED25519)
Overview
Migrating to Hedera’s EVM implementation involves understanding key differences in account models, signature verification, and key types. On Ethereum, addresses are derived from ECDSA public keys, and ECRECOVER
is commonly used to validate signatures. Hedera, however, supports both ECDSA and ED25519 (Hedera-native account) keys, with dynamic key rotation and aliases that may not directly align with Ethereum’s static address model.
This section helps you navigate ECDSA and ED25519 signature workflows, introduces the isAuthorized
function from the system contract from HIP-632, and clarify how different account key scenarios map onto Hedera’s environment.
Understanding Account Models and Aliases
Hedera’s account model supports both ED25519 and ECDSA keys by identifying accounts by aliases instead of static addresses. This allows dynamic key rotation without changing an account’s ID, unlike EVM's static ECDSA-only approach. Signature validation varies accordingly: ED25519 keys use isAuthorized
or isAuthorizedRaw
, while Hedera's ECDSA accounts with aliases can still rely on ECRECOVER
.
Clarifying Account Number Alias vs. EVM Address Alias
Hedera accounts can have both a native "Hedera account number alias" (e.g., 0.0.xxxx
) and a derived EVM address alias (a 20-byte address similar to Ethereum). The EVM alias makes the account compatible with ECRECOVER
and other familiar EVM tools. For more details, see the Smart Contract Addresses page.
Working With ECDSA Account Aliases in Testing
If you are writing an Ethereum smart contract and need to interact with an ECDSA Hedera account—particularly one identified by a Hedera account number alias—you must convert that alias into a format compatible with EVM tools. This ensures that when you call functions like ECRECOVER
, you reference the correct account. Here are some considerations:
During testing, confirm that your test scripts and configuration files convert the Hedera account number alias (e.g.,
0.0.xxxx
) into the corresponding 20-byte alias derived fromKeccak-256(publicKey)
. Doing so allows your EVM testing environment (Hardhat, Truffle) to interact with Hedera accounts like standard EVM addresses.Including this conversion step in your test setup saves time and confusion, ensuring your EVM-style smart contracts can reliably work with Hedera’s ECDSA accounts.
Key Permutations & Scenarios on Hedera
ECDSA Accounts:
Behave similarly to standard EVM accounts.
Allow validation of ECDSA signatures with
ECRECOVER
.Provide smooth interoperability with EVM tools and dApps.
ED25519 Accounts:
Require
isAuthorized
orisAuthorizedRaw
for signature validation.Support complex configurations like multi-key or threshold-based approval.
Enhance security and adaptability, but differ from EVM's static address.
This flexibility enables interoperability and more robust security models than standard EVM environments.
Using ECRECOVER for ECDSA Accounts on Hedera
Hedera supports ECDSA accounts, allowing EVM developers to validate ECDSA signatures using familiar tools like ECRECOVER
. ECDSA accounts on Hedera use aliases derived from Keccak-256(publicKey)
, ensuring compatibility with Ethereum’s signature workflows.
Example: Verifying ECDSA Signatures Using ECRECOVER
Key Considerations:
ECDSA accounts on Hedera behave just like EVM accounts when validating signatures with
ECRECOVER
.Use ECDSA accounts when interacting with EVM-compatible dApps, wallets, or bridges for minimal friction.
Using System Contract Functions for ED25519 Accounts
Hedera’s native key type is ED25519, which is not compatible with ECRECOVER
. To accommodate ED25519 (Hedera-native) accounts and more complex configurations, HIP-632 introduces Hedera Account Service system contract functions:
isAuthorized: Validates multiple signatures, supporting threshold or multi-key accounts.
isAuthorizedRaw: Validates a single raw ED25519 signature, analogous to
ECRECOVER
but for ED25519 keys.
Example: Validating ED25519 Signatures
Why This Matters for EVM Developers:
Hedera-Native Accounts: Most Hedera accounts use ED25519 keys, so
isAuthorizedRaw
is essential for verifying their signatures.Multi-Key and Threshold Accounts: Use
isAuthorized
for scenarios requiring multiple signatures, ensuring only properly authorized actions occur.
Note: For detailed parameter formats, consult the HIP-632 specification and the Hedera Account Service documentation. Ensure that accountAlias
, messageHash
, and signatureBlob
adhere to the required formats outlined there.
Practical Use Case: Multi-Key Verification
Hedera supports advanced account configurations like multi-sig and threshold accounts, which may include both ECDSA and ED25519 keys. Using isAuthorized
, you can enforce complex signing requirements, such as requiring multiple parties to sign before executing a contract operation.
Example: DAO Governance Using Multi-Sig
This example demonstrates how you might require multiple signatures to approve a DAO proposal, enhancing the security and trustworthiness of your governance mechanisms.
Key Rotation: Adapting to Hedera’s Dynamic Model
Standard EVM addresses are static since they are derived from a public key hash. Hedera, by contrast, supports dynamic key rotation, letting you update the keys controlling an account without changing the account’s address.
Why This Matters for EVM Developers:
Your applications must dynamically validate the current set of keys each time rather than relying on a static key-to-address mapping.
By rotating keys, you can enhance security without migrating to a new address.
Example: Key Rotation in Smart Contracts
This simple pattern allows you to change the trusted signer as needed, reflecting real-world operational needs such as periodic key rotation to mitigate security risks.
Additional References and Resources
Last updated