Hedera's EVM Equivalence Goals and Exceptions
Last updated
Was this helpful?
Last updated
Was this helpful?
Hedera aims to achieve equivalence to enhance the programmability and adoption of the network. This page outlines Hedera's EVM equivalence goals and highlights the key differences and exceptions between Hedera and .
Hedera's EVM equivalence strategy is designed to empower developers by facilitating the execution of EVM smart contracts more rapidly and cost-effectively while ensuring seamless integration of Hedera’s native services. The key goals include:
Hedera aims to enable a wider range of application programmability without sacrificing its unique value. This means allowing developers to build a diverse range of applications on the Hedera network, from applications to supply chain solutions, while still benefiting from the unique features of Hedera, such as its speed, security, and fairness.
Hedera plans to integrate its native services with the EVM seamlessly. This will allow developers to execute more rapidly and cost-effectively. It will also make it easier for developers to use Hedera's services, as they can use the same tools and languages they are already familiar with from the Ethereum ecosystem.
Hedera's strategy involves leveraging the HyperLedger Besu EVM client, which allows developers to capitalize on their existing Solidity expertise. This means that developers already familiar with and the EVM can easily transition to developing on Hedera, taking advantage of its unique strengths such as faster transactions, low and fixed fees, fair transaction ordering, immediate finality, and heightened security.
Hedera aims to provide a seamless transition for developers already working with EVM-based platforms. This means making it easy for developers to move their existing applications, smart contracts, and other digital assets to the Hedera network. This goal aims to encourage the adoption of the Hedera network by reducing the barriers to entry for developers.
Hedera plans to support familiar , libraries, and environments. This includes providing support for popular development environments like and , as well as libraries like and . The network also supports tools like , , and . This goal is to make it easier for developers to build on Hedera, as they can use the same tools they are already familiar with from the Ethereum ecosystem.
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.
Network State Data Structure
Virtual Merkle Tree
Merkle Patricia Trie
Hashing Algorithm
SHA-384
Keccak-256
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
Mempools available
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
Native Tokens
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
Communication
Requires communication with both consensus and mirror nodes
Direct communication with nodes
HBAR Decimal Precision
Consistent 18 point decimal precision
Hedera encourages developers to contribute to its EVM development and join the community discussions in the official . This goal aims to foster a vibrant and engaged developer community, which is crucial for the long-term success and sustainability of the Hedera network.
🔔 Detailed of Hedera's EVM Equivalence strategy.
No
Supports native tokens in addition to
8 or 18