Understanding Hedera for EVM Developers
Last updated
Last updated
While Hedera strives for EVM equivalence, it's important to recognize certain unique aspects and fundamental differences in its network architecture and operations, such as the handling of state data structures, hashing algorithms, and the management of accounts and transactions. These distinctions in network behaviors are intentional design choices made to align with EVM standards, thereby achieving EVM compatibility. This approach ensures that while Hedera aligns closely with Ethereum, it also maintains its distinctive features and optimization.
Function | Hedera | Ethereum |
---|---|---|
*Note: Hedera'a EVM supports Keccak-256. Transactions received through EthereumTransaction
(via the JSON-RPC relay) are hashed using Keccak-256. Only transactions using ED25519 keys through the Hedera API (HAPI) are hashed using SHA-384.
Function | Hedera | Ethereum |
---|---|---|
Function | Hedera | Ethereum |
---|---|---|
Note: Hedera Consensus and mirror nodes do not provide Ethereum RPC API endpoints.
**Note: Token Association only applies to native HTS tokens and does not affect ERC-20/721 tokens.
Function | Hedera | Ethereum |
---|---|---|
Function | Hedera | Ethereum |
---|---|---|
Function | Hedera | Ethereum |
---|---|---|
Function | Hedera | Ethereum |
---|---|---|
Network State Data Structure
Virtual Merkle Tree
Merkle Patricia Trie
Hashing Algorithm
SHA-384
Keccak-256*
Security
High security with aBFT
Secure with decentralized PoS network
Authorization Signatures
Used for transaction authorization outside of smart contracts
Typically used within smart contracts
Special System Accounts
Available with unique properties
Not available
Non-ECDSA Accounts
Non-ECDSA accounts (such as ED or multi-key) are supported by Hedera and
ECDSA accounts are fully compatible
ECDSA accounts are supported by Ethereum and non-ECDSA accounts are not supported/compatible
Account Deletion
Possible
Not possible
Data Return on Static Calls
Data retrieval must be done through the relay
Data returned directly
Gas Fees
Charges at least 80% of gas fees regardless of transaction outcome
Gas fees depend on transaction outcome but typically 100% of the gas fees are charged and the unused portion is credited back
Contract Lifecycle
Contract entities can expire, rent fees may apply
No expiration or rent fees
Transaction Size Limit
6kb
No limit
Transaction Throttling
Transactions pending until future submission
Query Costs
Not free, can use mirror node for free queries
Free read-only calls
Mempools
No mempools
Mempools available
Cost
Low, predictable fees (fraction of a cent)
Variable, often high gas fees
RPC Block Requests (e.g., eth_getBlockByHash*
& eth_getBlockByNumber
)
Return zero 32bytes hexadecimal value for the stateRoot
Returns the stateRoot
hexadecimal value of the final state trie of the block
Communication
Requires communication with both consensus and mirror nodes
Direct communication with nodes
Native Tokens
Supports native tokens in addition to ERC-20 and ERC-721 token standards
All ERC token standards but primarily ERC-20 and ERC-721 tokens.
Fee Structure
Single gas price
Token Association**
No concept of token association
Keys for Token Functionality
Keys control access to token functionality (KYC
, FREEZE
, WIPE
, supply, fee, and PAUSE
)
No equivalent native functionality
Precheck Failures
Typically single failure reason
HBAR Decimal Precision
8 or 18 (varies across Hedera APIs)
Consistent 18 point decimal precision