Last updated
Last updated
After compiling your smart contract, you can deploy it to the Hedera network. The constructor's "init code" includes the contract's entire bytecode. When deploying, the EVM is expected to be supplied with both the smart contract and the gas required to execute and deploy the contract. Post-deployment, the constructor is removed, leaving only the runtime_bytecode for future contract interactions.
➡
➡
➡
The 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 submit ContractCreate, 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 (). 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 .
Reference:
The Hedera network nodes utilize the 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 components for greater fault tolerance, finality, and scalability.
As of the Hedera Mainnet release , the Besu EVM client is configured to support the Cancun hard fork of the Ethereum Mainnet, with some modifications.
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.
fallback() / receive() Functions in Hedera Smart ContractsWhen 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.
msg.sender: The address initiating the contract call.
msg.value: The amount of HBAR sent along with the call.
Developers should implement explicit functions to handle HBAR transfers.
Understanding these differences is crucial for anyone developing smart contracts on Hedera, particularly those familiar with Ethereum.
SDK
Hardhat
Admin Key
Contract Memo
Automatic Token Associations
Auto Renew Account ID
Staking Node ID or Account ID
Decline Staking Rewards
The smart contract platform has been upgraded to support the visible EVM changes introduced in the hard fork. This includes adding new opcodes for transient storage and memory copy, semantic updates for opcodes introduced certain operations introduced in the , , , and hard forks, except those with changes in block production, data serialization, and the double fee market.
As of the Hedera Services 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.
Hedera does not provide blobs under . 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.
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 .
Reference: ,
To disable native operations entirely, consider submitting a .
You can use a 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 can be used to deploy your smart contract by pointing to a community-hosted . However, EVM tools do not support features that are native to Hedera smart contracts like:
If you need to set any of the above properties for your contract, you will have to call the ContractCreateTransaction API using one of the
Yes, you can use Solidity functions directly with the Hedera EVM. However, refer to the table to understand any modifications to opcode descriptions that better reflect their behavior on the Hedera network.
If your contract relies on blob-related opcodes introduced in the Cancun hard fork, you can still deploy it on Hedera. The blob-related opcodes will not fail. They'll return default values as .
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 table for more information.