runtime_bytecode for future contract interactions.
➡ Hyperledger Besu EVM
➡ Cancun Hard Fork
➡ Solidity Variables and Opcodes
Ethereum Virtual Machine (EVM)
The Ethereum Virtual Machine (EVM) is a run-time environment for executing smart contracts written in EVM native programming languages, like Solidity. The source code must be compiled into bytecode for the EVM to execute a given smart contract. On Hedera, users can interact with the EVM-compatible environment in several ways. They can submitContractCreate, EthereumTransaction, or make eth_sendRawTransaction RPC calls with the contract bytecode directly. These various paths allow developers to deploy and manage smart contracts efficiently.
When the EVM receives the bytecode, it will be further broken down into operation codes (opcodes). The EVM opcodes represent the specific instructions it can perform. Each opcode is one byte and has its own gas cost associated with it. The cost per opcode for the Ethereum Cancun hard fork can be found here.
Smart Contract Opcode Example
Deployment Options
SDK You can use a Hedera SDK to deploy your smart contract bytecode to the network. This approach does not require using any EVM tools like Hardhat or an instance of the Hedera JSON-RPC Relay. Hardhat Hardhat can be used to deploy your smart contract by pointing to a community-hosted JSON-RPC Relay. However, EVM tools do not support features that are native to Hedera smart contracts like:- Admin Key
- Contract Memo
- Automatic Token Associations
- Auto Renew Account ID
- Staking Node ID or Account ID
- Decline Staking Rewards
ContractCreateTransaction API using one of the Hedera SDKs.
Deploy A Smart Contract Using Hardhat Hedera Json Rpc Relay
Deploying Large Contracts
Hedera supports jumbo Ethereum transactions (HIP-1086) for large bytecode payloads. You can include up to 24KB for contract creation and 128KB for contract calls directly inethereumData, without using the File Service (callDataFileId).
However, jumbo transactions:
- Can’t be included in batch transactions (
TransactionList). - Are subject to network throttling based on bytes per second and per-node limits.
Bytecode and Gas Essentials
When deploying contracts, gas must cover both intrinsic gas and the cost of executing deployment code. Intrinsic gas includes a base fee (21,000) plus a per-byte cost forcallData:
- Intrinsic gas includes a base fee (21,000) plus a per-byte cost for
callData:- 4 gas per zero byte
- 16 gas per non-zero byte
Example
If your contract bytecode is 10KB, with 20% (2KB) as zero bytes and 80% (8KB) as non-zero bytes:- gas for zero bytes: 4 × 2,048 = 8,192
- gas for non-zero bytes: 16 × 8,192 = 131,072
- total intrinsic gas = 21,000 + 8,192 + 131,072 = 160,264
gasLimit (RLP) and maxGasAllowance (wrapper) to cover this total gas.
📣 Learn more on the Gas and Fees page, EthereumTransaction SDK page, and the Understanding Hedera’s EVM Differences and Compatibility page.
Hyperledger Besu EVM on Hedera
The Hedera network nodes utilize the HyperLedger Besu EVM Client written in Java as an execution layer for Ethereum-type transactions. The codebase is up to date with the current Ethereum Mainnet hard forks. The Besu EVM client library is used without hooks for Ethereum’s consensus, networking, and storage features. Instead, Hedera hooks into its own Hashgraph consensus, Gossip communication, and Virtual Merkle Trees components for greater fault tolerance, finality, and scalability. As of the Hedera Mainnet release0.50.0, the Besu EVM client is configured to support the Cancun hard fork of the Ethereum Mainnet, with some modifications.
Cancun Hard Fork
The smart contract platform has been upgraded to support the visible EVM changes introduced in the Cancun hard fork. This includes adding new opcodes for transient storage and memory copy, semantic updates for opcodes introduced certain operations introduced in the Shanghai, London, Istanbul, and Berlin hard forks, except those with changes in block production, data serialization, and the double fee market. As of the Consensus Node 0.22 release, gas and input data costs are charged. The amount of intrinsic gas consumed is a constant charge that occurs before any code executes. The intrinsic gas cost is 21,000. The associated cost of input data is 16 gas for each byte of data that is not zero and 4 gas for each byte of data that is zero. The amount of intrinsic gas consumed is charged in relation to the data supplied when making a contract call to the function parameters of external contracts. The gas schedule and the fees table can be found in the gas section of this documentation page.
Proto-Danksharding
As an interim solution to full sharding, introduced in the Cancun hard fork, the proto-danksharding offers some of the advantages of sharding with reduced complexity and infrastructure changes that are part of a sharding implementation. This, in turn, opens the gates for adding “blobs” of data to append to blocks to increase data availability further and allow more processing efficiency. Blobs are big data objects within blocks. These can be utilized to store rollups (Layer 2 solutions) and different kinds of apps requiring big data objects to be stored in an efficient way. This is data off-chain for the validators and requires minimal processing on their part. It reduces the computational load on the network and hence reduces the transaction gas fee.❌ Blobs supported on Hedera?
Hedera does not provide blobs under EIP-4844. HIP-866 defines how Hedera behaves without blob support. To preserve compatibility and future design space, Hedera will act as if blobs are not being added. This allows existing contracts dependent on blob behavior to function without blobs. Blobs will be prevented from entering the system by prohibiting “Type 3” transactions, which enable blobs. This will keep blobs out of the EVM’s concern without affecting other desirable interactions on Hedera.Solidity Variables and Opcodes
The table below defines the mapping of Solidity variables and operation codes to Hedera. The full list of supported Opcodes for the Cancun hard fork can be found here.| Solidity | Opcode | Hedera |
|---|---|---|
address | The address is a mapping of shard.realm.number (0.0.10) into a 20 byte Solidity address. The address can be a Hedera account ID or contract ID in Solidity format. | |
block.basefee | BASEFEE | The BASEFEE opcode will return zero. Hedera does not use the Fee Market mechanism this is designed to support. |
block.chainId | CHAINID | The CHAINID opcode will return 295(hex 0x0127) for mainnet, 296( hex 0x0128) for testnet, 297( hex 0x0129) for previewnet, and 298 (0x12A) for development networks. |
block.coinbase | COINBASE | The COINBASE operation will return the funding account (Hedera transaction fee collecting account 0.0.98). |
block.number | The index of the record file (not recommended, use block.timestamp). | |
block.timestamp | The transaction consensus timestamp. | |
block.difficulty | Always zero. | |
block.gaslimit | GASLIMIT | The GASLIMIT operation will return the gasLimit of the transaction. The transaction gasLimit will be the lowest of the gas limit requested in the transaction or a global upper gas limit configured for all smart contracts. |
msg.sender | The address of the Hedera contract ID or account ID in Solidity format that called this contract. For the root level or for delegate chains that go to the root, it is the account ID paying for the transaction. | |
msg.value | The value associated to the transaction associated in tinybar. | |
tx.origin | The account ID paying for the transaction, regardless of depth. | |
tx.gasprice | Fixed (varies with the global fee schedule and exchange rate). | |
| SELFDESTRUCT | Address will not be reusable due to Hedera’s account numbering policies. On SELFDESTRUCT the contracts HBAR and HTS tokens are transferred to the recipients. If the recipient does not exist or does not have an allowance for any of the HTS tokens, this opcode will fail. |
<address>.code | Precompile contract addresses will report no code, including HTS System contract. | |
<address>.codehash | Precompile contract addresses will report the empty code hash. | |
PRNGSEED | This opcode returns a random number based on the n-3 record running hash. | |
delegateCall | Contracts may no longer use delegateCall() to invoke system contracts. Contracts should instead use the call() method. | |
blobVersionedHashesAtIndex | BLOBHASH | The BLOBHASH operation will return all zeros at all times. |
blobBaseFee | BLOBBASEFEE | The
|
Limitation on fallback() / receive() Functions in Hedera Smart Contracts
When developing smart contracts on Hedera, it’s important to understand that the fallback() and receive() functions do not get triggered when a contract receives HBAR via a crypto transfer.
In Ethereum, these functions act as “catch-all” mechanisms when a contract receives Ether. In Hedera, however, contract balances may change through native HAPI operations, independent of EVM message calls, making it impossible to maintain balance-related invariants with just the fallback() or receive() methods.
Impacted Variables
msg.sender: The address initiating the contract call.msg.value: The amount of HBAR sent along with the call.
Key Points
- Developers should implement explicit functions to handle HBAR transfers.
- To disable native operations entirely, consider submitting a Hedera Improvement Proposal (HIP).
FAQs
Can I use Solidity functions directly with the Hedera EVM?
Can I use Solidity functions directly with the Hedera EVM?
Yes, you can use Solidity functions directly with the Hedera EVM. However, refer to the Solidity Variables and Opcodes table to understand any modifications to opcode descriptions that better reflect their behavior on the Hedera network.
Can i deploy large contracts with big bytecode?
Can i deploy large contracts with big bytecode?
Yes, hedera supports jumbo ethereum transactions (HIP-1086), allowing up to 24kb for contract creation and 128kb for contract calls. this eliminates the need for uploading bytecode to the file service in most cases. Learn more.
Do jumbo transactions work with batch transactions?
Do jumbo transactions work with batch transactions?
No, jumbo ethereum transactions cannot be included in a
TransactionList (batch). each jumbo transaction must be submitted individually.How does gas work when deploying a contract?
How does gas work when deploying a contract?
Gas covers intrinsic costs (base + per-byte of
callData) and execution costs (opcodes run by the EVM). Ensure your gasLimit and maxGasAllowance cover the total. See the gas and fees page for details.How does hedera handle <code>fallback()</code> and <code>receive()</code> functions?
How does hedera handle <code>fallback()</code> and <code>receive()</code> functions?
Hedera does not trigger
fallback() or receive() functions on HBAR transfers. Balances may change through native operations, so use explicit functions to handle HBAR. Learn more.Can i deploy contracts using only hardhat?
Can i deploy contracts using only hardhat?
Yes, but Hardhat cannot set Hedera-native properties like admin key or token associations. For these, use the Hedera SDK.
What should I do if my contract relies on blob-related opcodes?
What should I do if my contract relies on blob-related opcodes?
Are there any special considerations for using updated EVM opcodes on Hedera?
Are there any special considerations for using updated EVM opcodes on Hedera?
Yes, while the Hedera EVM supports the updated opcodes from the Cancun hard fork, you should know the intrinsic gas costs and input data charges specific to Hedera. Refer to the gas schedule and fees table for more information.