diff --git a/evm/development/deploying.mdx b/evm/development/deploying.mdx index dc152bba..ffbbf8a8 100644 --- a/evm/development/deploying.mdx +++ b/evm/development/deploying.mdx @@ -3,11 +3,13 @@ title: "Deploying Smart Contracts" --- -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 [bytecode](/support/glossary#bytecode) 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. +After compiling your smart contract, you can deploy it to the Hedera network. The deployment payload, or "*init code*", contains the constructor logic together with the contract's runtime bytecode. When deploying, the EVM is expected to be supplied with both the smart contract [bytecode](/support/glossary#bytecode) and the gas required to execute and deploy the contract. The constructor runs once during deployment and returns the `runtime_bytecode`, which is what's stored on-chain for future contract interactions. **➡** [**Hyperledger Besu EVM**](#hyperledger-besu-evm-on-hedera) -**➡** [**Cancun Hard Fork**](#cancun-hard-fork) +**➡** [**Pectra Hard Fork**](#pectra-hard-fork) + +**➡** [**Past Hard Forks**](#past-hard-forks) **➡** [**Solidity Variables and Opcodes**](#solidity-variables-and-opcodes) @@ -19,15 +21,17 @@ The [Ethereum Virtual Machine (EVM)](/support/glossary#ethereum-virtual-machine- 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 ([opcodes](/support/glossary#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](https://www.evm.codes/?fork=cancun). +When the EVM receives the bytecode, it will be further broken down into operation codes ([opcodes](/support/glossary#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 Pectra hard fork (Prague EVM execution layer) can be found [here](https://www.evm.codes/?fork=prague). #### Smart Contract Opcode Example -```solidity + +```text wrap PUSH1 0x80 PUSH1 0x40 MSTORE CALLVALUE DUP1 ISZERO PUSH2 0x10 JUMPI PUSH1 0x0 DUP1 REVERT JUMPDEST POP PUSH1 0x40 MLOAD PUSH2 0x558 CODESIZE SUB DUP1 PUSH2 0x558 DUP4 CODECOPY DUP2 DUP2 ADD PUSH1 0x40 MSTORE PUSH1 0x20 DUP2 LT ISZERO PUSH2 0x33 JUMPI PUSH1 0x0 DUP1 REVERT JUMPDEST DUP2 ADD SWAP1 DUP1 DUP1 MLOAD PUSH1 0x40 MLOAD SWAP4 SWAP3 SWAP2 SWAP1 DUP5 PUSH5 0x100000000 DUP3 GT ISZERO PUSH2 0x53 JUMPI PUSH1 0x0 DUP1 REVERT JUMPDEST DUP4 DUP3 ADD SWAP2 POP PUSH1 0x20 DUP3 ADD DUP6 DUP2 GT ISZERO PUSH2 0x69 JUMPI PUSH1 0x0 DUP1 REVERT JUMPDEST DUP3 MLOAD DUP7 PUSH1 0x1 DUP3 MUL DUP4 ADD GT PUSH5 0x100000000 DUP3 GT OR ISZERO PUSH2 0x86 JUMPI PUSH1 0x0 DUP1 REVERT JUMPDEST DUP1 DUP4 MSTORE PUSH1 0x20 DUP4 ADD SWAP3 POP POP POP SWAP1 DUP1 MLOAD SWAP1 PUSH1 0x20 ADD SWAP1 DUP1 DUP4 DUP4 PUSH1 0x0 JUMPDEST DUP4 DUP2 LT ISZERO PUSH2 0xBA JUMPI DUP1 DUP3 ADD MLOAD DUP2 DUP5 ADD MSTORE PUSH1 0x20 DUP2 ADD SWAP1 POP PUSH2 0x9F JUMP JUMPDEST POP POP POP POP SWAP1 POP SWAP1 DUP2 ADD SWAP1 PUSH1 0x1F AND DUP1 ISZERO PUSH2 0xE7 JUMPI DUP1 DUP3 SUB DUP1 MLOAD PUSH1 0x1 DUP4 PUSH1 0x20 SUB PUSH2 0x100 EXP SUB NOT AND DUP2 MSTORE PUSH1 0x20 ADD SWAP2 POP JUMPDEST POP PUSH1 0x40 MSTORE POP POP POP CALLER PUSH1 0x0 DUP1 PUSH2 0x100 EXP DUP2 SLOAD DUP2 PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF MUL NOT AND SWAP1 DUP4 PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND MUL OR SWAP1 SSTORE POP DUP1 PUSH1 0x1 SWAP1 DUP1 MLOAD SWAP1 PUSH1 0x20 ADD SWAP1 PUSH2 0x144 SWAP3 SWAP2 SWAP1 PUSH2 0x14B JUMP JUMPDEST POP POP PUSH2 0x1E8 JUMP JUMPDEST DUP3 DUP1 SLOAD PUSH1 0x1 DUP2 PUSH1 0x1 AND ISZERO PUSH2 0x100 MUL SUB AND PUSH1 0x2 SWAP1 DIV SWAP1 PUSH1 0x0 MSTORE PUSH1 0x20 PUSH1 0x0 KECCAK256 SWAP1 PUSH1 0x1F ADD PUSH1 0x20 SWAP1 DIV DUP2 ADD SWAP3 DUP3 PUSH1 0x1F LT PUSH2 0x18C JUMPI DUP1 MLOAD PUSH1 0xFF NOT AND DUP4 DUP1 ADD OR DUP6 SSTORE PUSH2 0x1BA JUMP JUMPDEST DUP3 DUP1 ADD PUSH1 0x1 ADD DUP6 SSTORE DUP3 ISZERO PUSH2 0x1BA JUMPI SWAP2 DUP3 ADD JUMPDEST DUP3 DUP2 GT ISZERO PUSH2 0x1B9 JUMPI DUP3 MLOAD DUP3 SSTORE SWAP2 PUSH1 0x20 ADD SWAP2 SWAP1 PUSH1 0x1 ADD SWAP1 PUSH2 0x19E JUMP JUMPDEST JUMPDEST POP SWAP1 POP PUSH2 0x1C7 SWAP2 SWAP1 PUSH2 0x1CB JUMP JUMPDEST POP SWAP1 JUMP JUMPDEST JUMPDEST DUP1 DUP3 GT ISZERO PUSH2 0x1E4 JUMPI PUSH1 0x0 DUP2 PUSH1 0x0 SWAP1 SSTORE POP PUSH1 0x1 ADD PUSH2 0x1CC JUMP JUMPDEST POP SWAP1 JUMP JUMPDEST PUSH2 0x361 DUP1 PUSH2 0x1F7 PUSH1 0x0 CODECOPY PUSH1 0x0 RETURN INVALID PUSH1 0x80 PUSH1 0x40 MSTORE CALLVALUE DUP1 ISZERO PUSH2 0x10 JUMPI PUSH1 0x0 DUP1 REVERT JUMPDEST POP PUSH1 0x4 CALLDATASIZE LT PUSH2 0x36 JUMPI PUSH1 0x0 CALLDATALOAD PUSH1 0xE0 SHR DUP1 PUSH4 0x2E982602 EQ PUSH2 0x3B JUMPI DUP1 PUSH4 0x32AF2EDB EQ PUSH2 0xF6 JUMPI JUMPDEST PUSH1 0x0 DUP1 REVERT JUMPDEST PUSH2 0xF4 PUSH1 0x4 DUP1 CALLDATASIZE SUB PUSH1 0x20 DUP2 LT ISZERO PUSH2 0x51 JUMPI PUSH1 0x0 DUP1 REVERT JUMPDEST DUP2 ADD SWAP1 DUP1 DUP1 CALLDATALOAD SWAP1 PUSH1 0x20 ADD SWAP1 PUSH5 0x100000000 DUP2 GT ISZERO PUSH2 0x6E JUMPI PUSH1 0x0 DUP1 REVERT JUMPDEST DUP3 ADD DUP4 PUSH1 0x20 DUP3 ADD GT ISZERO PUSH2 0x80 JUMPI PUSH1 0x0 DUP1 REVERT JUMPDEST DUP1 CALLDATALOAD SWAP1 PUSH1 0x20 ADD SWAP2 DUP5 PUSH1 0x1 DUP4 MUL DUP5 ADD GT PUSH5 0x100000000 DUP4 GT OR ISZERO PUSH2 0xA2 JUMPI PUSH1 0x0 DUP1 REVERT JUMPDEST SWAP2 SWAP1 DUP1 DUP1 PUSH1 0x1F ADD PUSH1 0x20 DUP1 SWAP2 DIV MUL PUSH1 0x20 ADD PUSH1 0x40 MLOAD SWAP1 DUP2 ADD PUSH1 0x40 MSTORE DUP1 SWAP4 SWAP3 SWAP2 SWAP1 DUP2 DUP2 MSTORE PUSH1 0x20 ADD DUP4 DUP4 DUP1 DUP3 DUP5 CALLDATACOPY PUSH1 0x0 DUP2 DUP5 ADD MSTORE PUSH1 0x1F NOT PUSH1 0x1F DUP3 ADD AND SWAP1 POP DUP1 DUP4 ADD SWAP3 POP POP POP POP POP POP POP SWAP2 SWAP3 SWAP2 SWAP3 SWAP1 POP POP POP PUSH2 0x179 JUMP JUMPDEST STOP JUMPDEST PUSH2 0xFE PUSH2 0x1EC JUMP JUMPDEST PUSH1 0x40 MLOAD DUP1 DUP1 PUSH1 0x20 ADD DUP3 DUP2 SUB DUP3 MSTORE DUP4 DUP2 DUP2 MLOAD DUP2 MSTORE PUSH1 0x20 ADD SWAP2 POP DUP1 MLOAD SWAP1 PUSH1 0x20 ADD SWAP1 DUP1 DUP4 DUP4 PUSH1 0x0 JUMPDEST DUP4 DUP2 LT ISZERO PUSH2 0x13E JUMPI DUP1 DUP3 ADD MLOAD DUP2 DUP5 ADD MSTORE PUSH1 0x20 DUP2 ADD SWAP1 POP PUSH2 0x123 JUMP JUMPDEST POP POP POP POP SWAP1 POP SWAP1 DUP2 ADD SWAP1 PUSH1 0x1F AND DUP1 ISZERO PUSH2 0x16B JUMPI DUP1 DUP3 SUB DUP1 MLOAD PUSH1 0x1 DUP4 PUSH1 0x20 SUB PUSH2 0x100 EXP SUB NOT AND DUP2 MSTORE PUSH1 0x20 ADD SWAP2 POP JUMPDEST POP SWAP3 POP POP POP PUSH1 0x40 MLOAD DUP1 SWAP2 SUB SWAP1 RETURN JUMPDEST PUSH1 0x0 DUP1 SLOAD SWAP1 PUSH2 0x100 EXP SWAP1 DIV PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND CALLER PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND EQ PUSH2 0x1D1 JUMPI PUSH2 0x1E9 JUMP JUMPDEST DUP1 PUSH1 0x1 SWAP1 DUP1 MLOAD SWAP1 PUSH1 0x20 ADD SWAP1 PUSH2 0x1E7 SWAP3 SWAP2 SWAP1 PUSH2 0x28E JUMP JUMPDEST POP JUMPDEST POP JUMP JUMPDEST PUSH1 0x60 PUSH1 0x1 DUP1 SLOAD PUSH1 0x1 DUP2 PUSH1 0x1 AND ISZERO PUSH2 0x100 MUL SUB AND PUSH1 0x2 SWAP1 DIV DUP1 PUSH1 0x1F ADD PUSH1 0x20 DUP1 SWAP2 DIV MUL PUSH1 0x20 ADD PUSH1 0x40 MLOAD SWAP1 DUP2 ADD PUSH1 0x40 MSTORE DUP1 SWAP3 SWAP2 SWAP1 DUP2 DUP2 MSTORE PUSH1 0x20 ADD DUP3 DUP1 SLOAD PUSH1 0x1 DUP2 PUSH1 0x1 AND ISZERO PUSH2 0x100 MUL SUB AND PUSH1 0x2 SWAP1 DIV DUP1 ISZERO PUSH2 0x284 JUMPI DUP1 PUSH1 0x1F LT PUSH2 0x259 JUMPI PUSH2 0x100 DUP1 DUP4 SLOAD DIV MUL DUP4 MSTORE SWAP2 PUSH1 0x20 ADD SWAP2 PUSH2 0x284 JUMP JUMPDEST DUP3 ADD SWAP2 SWAP1 PUSH1 0x0 MSTORE PUSH1 0x20 PUSH1 0x0 KECCAK256 SWAP1 JUMPDEST DUP2 SLOAD DUP2 MSTORE SWAP1 PUSH1 0x1 ADD SWAP1 PUSH1 0x20 ADD DUP1 DUP4 GT PUSH2 0x267 JUMPI DUP3 SWAP1 SUB PUSH1 0x1F AND DUP3 ADD SWAP2 JUMPDEST POP POP POP POP POP SWAP1 POP SWAP1 JUMP JUMPDEST DUP3 DUP1 SLOAD PUSH1 0x1 DUP2 PUSH1 0x1 AND ISZERO PUSH2 0x100 MUL SUB AND PUSH1 0x2 SWAP1 DIV SWAP1 PUSH1 0x0 MSTORE PUSH1 0x20 PUSH1 0x0 KECCAK256 SWAP1 PUSH1 0x1F ADD PUSH1 0x20 SWAP1 DIV DUP2 ADD SWAP3 DUP3 PUSH1 0x1F LT PUSH2 0x2CF JUMPI DUP1 MLOAD PUSH1 0xFF NOT AND DUP4 DUP1 ADD OR DUP6 SSTORE PUSH2 0x2FD JUMP JUMPDEST DUP3 DUP1 ADD PUSH1 0x1 ADD DUP6 SSTORE DUP3 ISZERO PUSH2 0x2FD JUMPI SWAP2 DUP3 ADD JUMPDEST DUP3 DUP2 GT ISZERO PUSH2 0x2FC JUMPI DUP3 MLOAD DUP3 SSTORE SWAP2 PUSH1 0x20 ADD SWAP2 SWAP1 PUSH1 0x1 ADD SWAP1 PUSH2 0x2E1 JUMP JUMPDEST JUMPDEST POP SWAP1 POP PUSH2 0x30A SWAP2 SWAP1 PUSH2 0x30E JUMP JUMPDEST POP SWAP1 JUMP JUMPDEST JUMPDEST DUP1 DUP3 GT ISZERO PUSH2 0x327 JUMPI PUSH1 0x0 DUP2 PUSH1 0x0 SWAP1 SSTORE POP PUSH1 0x1 ADD PUSH2 0x30F JUMP JUMPDEST POP SWAP1 JUMP INVALID LOG2 PUSH5 0x6970667358 0x22 SLT KECCAK256 AND DIFFICULTY CHAINID 0x5F 0x5F PUSH20 0xDFD73A518B57770F5ADB27F025842235980D7A0F 0x4E ISZERO 0xB1 0xAC 0xB1 DUP15 PUSH5 0x736F6C6343 STOP SMOD STOP STOP CALLER ``` + -Reference: https://ethervm.io/ +Reference: [ethervm.io](https://ethervm.io/) *** @@ -59,20 +63,19 @@ If you need to set any of the above properties for your contract, you will have ### Deploying Large Contracts -Hedera supports **jumbo Ethereum transactions (**[**HIP-1086**](https://hips.hedera.com/hip/hip-1086)**)** for large bytecode payloads. You can include up to **24KB for contract creation** and **128KB for contract calls** directly in `ethereumData`, without using the File Service (`callDataFileId`). +Hedera supports **jumbo Ethereum transactions (**[**HIP-1086**](https://hips.hedera.com/hip/hip-1086)**)** for large bytecode payloads, letting you include `callData` directly in `ethereumData` without using the File Service (`callDataFileId`). The exact ceilings are **network-configurable parameters**, not fixed protocol constants; current values are on the order of **~24KB for contract creation** (aligned with the [EIP-170](https://eips.ethereum.org/EIPS/eip-170) code-size limit) and **~128KB for contract calls**. Check the active network configuration for the precise limits. However, jumbo transactions: -* Can’t be included in batch transactions (`TransactionList`). +* 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 for `callData`: -* 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 +* 4 gas per zero byte +* 16 gas per non-zero byte #### Example @@ -82,43 +85,105 @@ If your contract bytecode is 10KB, with 20% (2KB) as zero bytes and 80% (8KB) as * **gas for non-zero bytes**: 16 × 8,192 = 131,072 * **total intrinsic gas** = 21,000 + 8,192 + 131,072 = 160,264 -Ensure you adjust `gasLimit` (RLP) and `maxGasAllowance` (wrapper) to cover this total gas. +Under Pectra, the transaction also has to satisfy the [EIP-7623](https://eips.ethereum.org/EIPS/eip-7623) calldata floor: `21000 + 10 × (zero + 4 × non_zero)`. For this example that floor is `21,000 + 10 × (2,048 + 4 × 8,192) = 369,160` gas, well above the 160,264 intrinsic figure. The deployment pays whichever is greater: the intrinsic **plus execution** total, or the floor. In practice deployment execution includes the code-deposit charge (200 gas per byte of runtime bytecode, roughly 2M gas for a 10KB contract), which pushes the standard total far past the floor, so the floor mainly matters for calldata-heavy transactions with little execution work. See the [Gas and Fees page](/evm/development/gas-fees#intrinsic-gas) for the full intrinsic-gas formula. -📣 Learn more on the [Gas and Fees page,](/evm/development/gas-fees) [EthereumTransaction SDK page](/native/smart-contracts/ethereum-transaction), and the [Understanding Hedera's EVM Differences and Compatibility page](/evm/differences). +Ensure you adjust `gasLimit` (RLP) and `maxGasAllowance` (wrapper) to cover this total gas. + + 📣 Learn more on the [Gas and Fees page,](/evm/development/gas-fees) [`EthereumTransaction` SDK page](/native/smart-contracts/ethereum-transaction), and the [Understanding Hedera's EVM Differences and Compatibility page](/evm/differences). + *** ## Hyperledger Besu EVM on Hedera The Hedera network nodes utilize the [HyperLedger Besu EVM ](/support/glossary#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](/support/glossary#virtual-merkle-tree) components for greater fault tolerance, finality, and scalability. -As of the Hedera Mainnet release [`0.50.0`](/networks/release-notes/services#v0.50), the Besu EVM client is configured to support the Cancun hard fork of the Ethereum Mainnet, with some modifications. +The Besu EVM client is configured to support the **Pectra hard fork** of the Ethereum Mainnet (activated on Ethereum May 7, 2025), with some modifications. Pectra was introduced on Hedera under [HIP-1341](https://hips.hedera.com/hip/hip-1341) (Support for Ethereum Pectra Release). + + +**EIP-7702 is deactivated.** Hedera runs the Prague EVM, but EIP-7702 (set EOA account code), and therefore EOA Code Delegation, is currently disabled. Type 4 (set-code) transactions are not accepted and no account delegation takes execution effect. The other applicable Pectra EIPs (EIP-2537 and EIP-7623, below) are active. + + +### **Pectra Hard Fork** + +The smart contract platform has been upgraded to support the visible EVM changes introduced in the [Pectra](https://eips.ethereum.org/EIPS/eip-7600) hard fork (Prague execution layer plus Electra consensus layer). The applicable EIPs adopted on Hedera are: + +| EIP | Title | Summary | +| ---------------------------------------------------- | ------------------------------------ | ------------------------------------------------------------------------------------------------------------- | +| [EIP-2537](https://eips.ethereum.org/EIPS/eip-2537) | BLS12-381 curve precompiles | Adds precompiles at addresses `0x0b` to `0x11` for efficient BLS signature and pairing operations. | +| [EIP-7623](https://eips.ethereum.org/EIPS/eip-7623) | Increase calldata cost (floor) | Introduces a calldata gas floor: `21000 + 10 × (zero_bytes + 4 × non_zero_bytes)`. | + +[EIP-7702](https://eips.ethereum.org/EIPS/eip-7702) (Set EOA account code) is part of Pectra but is **currently deactivated on Hedera**: Type 4 transactions are not accepted and no EOA code delegation takes effect. Support is tracked for a future release under [HIP-1340](https://hips.hedera.com/hip/hip-1340). + +The following Pectra EIPs are **not applicable** to Hedera and are not adopted: EIP-7691, EIP-7840 (blob-related, Hedera does not support blobs); EIP-6110, EIP-7002, EIP-7251, EIP-7685 (Ethereum validator features, no Hedera equivalent); EIP-2935, EIP-7549 (Ethereum consensus-layer features); EIP-7642 (informational). Per [HIP-1341](https://hips.hedera.com/hip/hip-1341). + +As of the Consensus Node [0.22](/networks/release-notes/services#v0.22) release ([HIP-185](https://hips.hedera.com/hip/hip-185)), 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. Under Pectra (EIP-7623), an additional floor of `21000 + 10 × (zero + 4 × non_zero)` applies to calldata-heavy transactions. 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. -### **Cancun Hard Fork** +#### Supported Ethereum Transaction Types -The smart contract platform has been upgraded to support the visible EVM changes introduced in the [Cancun](https://github.com/ethereum/execution-specs/blob/master/network-upgrades/mainnet-upgrades/cancun.md) hard fork. This includes adding new opcodes for transient storage and memory copy, semantic updates for opcodes introduced certain operations introduced in the [Shanghai](https://github.com/ethereum/execution-specs/blob/master/network-upgrades/mainnet-upgrades/shanghai.md), [London](https://github.com/ethereum/execution-specs/blob/master/network-upgrades/mainnet-upgrades/london.md), [Istanbul](https://github.com/ethereum/execution-specs/blob/master/network-upgrades/mainnet-upgrades/istanbul.md), and [Berlin](https://github.com/ethereum/execution-specs/blob/master/network-upgrades/mainnet-upgrades/berlin.md) hard forks, except those with changes in block production, data serialization, and the double fee market. +`EthereumTransaction` accepts RLP-encoded payloads for all of the following types: -As of the Consensus Node [0.22](/networks/release-notes/services#v0.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. +| Type | Spec | Description | +| :--: | ----------------------------------------------------- | ------------------------------------------------------------------------------------------------------------- | +| `0x00` | Legacy ([EIP-155](https://eips.ethereum.org/EIPS/eip-155)) | Pre-Berlin legacy transactions. | +| `0x01` | [EIP-2930](https://eips.ethereum.org/EIPS/eip-2930) | Optional `access_list` to pre-warm storage slots and addresses. | +| `0x02` | [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559) | `max_fee_per_gas` plus `max_priority_fee_per_gas` (priority fee is ignored on Hedera; fees are fixed by the network). | + +Type 3 (blob transactions per EIP-4844) is **not supported** on Hedera (see [HIP-866](https://hips.hedera.com/hip/hip-866)). Type 4 ([EIP-7702](https://eips.ethereum.org/EIPS/eip-7702)) is also **not accepted**: EOA Code Delegation is currently deactivated. For the full type list, access-list usage, and SDK examples, see [Ethereum transaction](/native/smart-contracts/ethereum-transaction#supported-ethereum-transaction-types). -#### Proto-Danksharding +#### Blobs supported on Hedera? -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. +Hedera does not provide blobs under [EIP-4844](https://eips.ethereum.org/EIPS/eip-4844) (Cancun), nor under the Pectra blob-throughput EIPs ([EIP-7691](https://eips.ethereum.org/EIPS/eip-7691), [EIP-7840](https://eips.ethereum.org/EIPS/eip-7840)). [HIP-866](https://hips.hedera.com/hip/hip-866) defines how Hedera behaves without blob support. To preserve compatibility and future design space, Hedera acts as if blobs are not being added. This allows existing contracts that depend on blob behavior to function without blobs. Blobs are prevented from entering the system by prohibiting "Type 3" transactions, which enable blobs. This keeps blobs out of the EVM's concern without affecting other desirable interactions on Hedera. With jumbo `EthereumTransaction` support ([HIP-1086](https://hips.hedera.com/hip/hip-1086)) on Hedera, large `callData` payloads are the preferred path for rollup-style data. -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. +### **Past Hard Forks** -#### ❌ Blobs supported on Hedera? +Hedera tracks Ethereum mainnet hard forks and adopts the EIPs that apply to the Smart Contract Service. The table below summarizes recent forks and the practical differences between them on Hedera. -Hedera does not provide blobs under [EIP-4844](https://eips.ethereum.org/EIPS/eip-4844). [HIP-866](https://hips.hedera.com/hip/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. +| Fork (Ethereum activation) | First adopted on Hedera | Headline changes on Hedera | +| -------------------------- | ---------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| **Pectra** (May 7, 2025) | [HIP-1341](https://hips.hedera.com/hip/hip-1341) | • [EIP-2537](https://eips.ethereum.org/EIPS/eip-2537): BLS12-381 precompiles (`0x0b` to `0x11`).
• [EIP-7623](https://eips.ethereum.org/EIPS/eip-7623): calldata gas floor.
• [EIP-7702](https://eips.ethereum.org/EIPS/eip-7702) (Type 4 / EOA code delegation): **deactivated on Hedera**. | +| **Cancun** (Mar 13, 2024) | Mainnet release [`v0.50`](/networks/release-notes/services#v0.50) | • New opcodes `TLOAD`/`TSTORE` (transient storage), `MCOPY`, `BLOBHASH`, `BLOBBASEFEE`.
• `SELFDESTRUCT` semantics updated per [EIP-6780](https://eips.ethereum.org/EIPS/eip-6780).
• Blob support (EIP-4844) **not** adopted; Type 3 transactions are rejected ([HIP-866](https://hips.hedera.com/hip/hip-866)). | +| **Shanghai** (Apr 12, 2023)| Mainnet release [`v0.38`](/networks/release-notes/services#v0.38) | • `PUSH0` opcode.
• Updated `INITCODE` cost for contract creation. | -### Solidity Variables and Opcodes +#### What changed from Cancun to Pectra? + +If you previously targeted Cancun, the practical differences on Hedera are: + +1. **Calldata floor (EIP-7623).** Calldata-heavy transactions must now pay at least `21000 + 10 × (zero_bytes + 4 × non_zero_bytes)`. Standard contract calls (where execution gas dominates) are unaffected. +2. **BLS12-381 precompiles (EIP-2537).** Seven new precompiles at addresses `0x0b` to `0x11` for G1/G2 add, multi-scalar multiplication, pairing check, and field-to-curve mapping. These make BLS aggregation, threshold signatures, and zk-friendly cryptography native (no Solidity gymnastics). +3. **EOA Code Delegation (EIP-7702) is deactivated.** Type 4 transactions are not accepted and EOAs cannot delegate execution to a contract. `eth_getCode(eoa)` continues to return empty for externally owned accounts. + +> Blobs (EIP-4844 / EIP-7691 / EIP-7840) remain unsupported on Hedera. Type 3 transactions are rejected. -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](https://www.evm.codes/). +### Solidity Variables and Opcodes -
SolidityOpcodeHedera
addressThe 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.basefeeBASEFEEThe BASEFEE opcode will return zero. Hedera does not use the Fee Market mechanism this is designed to support.
block.chainIdCHAINIDThe 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.coinbaseCOINBASEThe COINBASE operation will return the funding account (Hedera transaction fee collecting account 0.0.98).
block.numberThe index of the record file (not recommended, use block.timestamp).
block.timestampThe transaction consensus timestamp.
block.difficultyAlways zero.
block.gaslimitGASLIMITThe 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.senderThe 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.valueThe value associated to the transaction associated in tinybar.
tx.originThe account ID paying for the transaction, regardless of depth.
tx.gaspriceFixed (varies with the global fee schedule and exchange rate).

selfdestruct

(address payable recipient)

SELFDESTRUCTAddress 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>.codePrecompile contract addresses will report no code, including HTS System contract.
<address>.codehashPrecompile contract addresses will report the empty code hash.
PRNGSEEDThis opcode returns a random number based on the n-3 record running hash.
delegateCallContracts may no longer use delegateCall() to invoke system contracts. Contracts should instead use the call() method.
blobVersionedHashesAtIndexBLOBHASHThe BLOBHASH operation will return all zeros at all times.
blobBaseFeeBLOBBASEFEE

The BLOBBASEFEE operation will return

1 at all times.

+The table below defines the mapping of Solidity variables and operation codes to Hedera. The full list of supported Opcodes for the Pectra hard fork (Prague EVM execution layer) can be found [here](https://www.evm.codes/?fork=prague). + +| 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 payable recipient)` | `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. | +| `
.code` | | Precompile and system-contract addresses (including the HTS system contract at `0x167`) report no code. Externally owned accounts report empty code (EOA Code Delegation is currently deactivated). | +| `
.codehash` | | Precompile contract addresses will report the empty code hash. | +| | PRNG system contract (`0x169`) | There is no PRNG opcode. Per [HIP-351](https://hips.hedera.com/hip/hip-351), contracts call `getPseudorandomSeed()` on the PRNG system contract at `0x169`, which returns a 256-bit seed derived from 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 `BLOBBASEFEE` operation will return `1` at all times. | Reference: [HIP-866](https://hips.hedera.com/hip/hip-866), [HIP-868](https://hips.hedera.com/hip/hip-868) @@ -150,30 +215,30 @@ Understanding these differences is crucial for anyone developing smart contracts Yes, you can use Solidity functions directly with the Hedera EVM. However, refer to the [Solidity Variables and Opcodes](#solidity-variables-and-opcodes) table to understand any modifications to opcode descriptions that better reflect their behavior on the Hedera network. - -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](/evm/differences#jumbo-ethereum-transactions). - - - -No, jumbo ethereum transactions cannot be included in a `TransactionList` (batch). each jumbo transaction must be submitted individually. + +Yes. Hedera supports jumbo Ethereum transactions ([HIP-1086](https://hips.hedera.com/hip/hip-1086)), which carry `callData` directly in `ethereumData` and remove the need to upload bytecode to the File Service in most cases. Note that jumbo transactions cannot be included in a `TransactionList` (batch); each one must be submitted individually. See [Deploying Large Contracts](#deploying-large-contracts) for the current size ceilings and throttling details. 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](/evm/development/gas-fees) for details. - + 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](#limitation-on-fallback-receive-functions-in-hedera-smart-contracts). - + Yes, but Hardhat cannot set Hedera-native properties like admin key or token associations. For these, use the [Hedera SDK](/native/fundamentals). -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 [specified by the EVM](https://www.evm.codes/?fork=cancun). +If your contract relies on blob-related opcodes introduced in the Cancun hard fork (`BLOBHASH`, `BLOBBASEFEE`), you can still deploy it on Hedera. The blob-related opcodes **will not** fail; they return default values (`0` and `1` respectively) as [specified by the EVM](https://www.evm.codes/?fork=prague). Blob transactions themselves (Type 3) remain unsupported. -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](/evm/development/gas-fees) table for more information. +Yes, while the Hedera EVM supports the updated opcodes from the Pectra hard fork (including Cancun-era `TLOAD`/`TSTORE`/`MCOPY` and Pectra-era BLS12-381 precompiles), you should know the intrinsic gas costs and input data charges specific to Hedera, including the EIP-7623 calldata floor. Refer to the [gas schedule and fees](/evm/development/gas-fees) table for more information. + + + +No. EIP-7702 (set EOA account code) is currently deactivated on Hedera. Type 4 `EthereumTransaction` payloads are not accepted, and EOA code delegation has no effect. The other Pectra EIPs (EIP-2537 BLS precompiles and the EIP-7623 calldata floor) are active. diff --git a/evm/development/gas-fees.mdx b/evm/development/gas-fees.mdx index f2f1aaa7..4106c353 100644 --- a/evm/development/gas-fees.mdx +++ b/evm/development/gas-fees.mdx @@ -45,7 +45,7 @@ Gas fees for EVM transactions consist of: ### Intrinsic Gas -A transaction submitted to the smart contract service must be sent with enough gas to cover **intrinsic gas**. With the **Cancun fork** of the EVM update, intrinsic gas is calculated as: +A transaction submitted to the smart contract service must be sent with enough gas to cover **intrinsic gas**. The standard cost is a base fee plus a per-byte charge for calldata: ```bash 21000 + 4 × (number of zero bytes) + 16 × (number of non-zero bytes) = intrinsic gas @@ -57,6 +57,31 @@ A transaction submitted to the smart contract service must be sent with enough g If insufficient gas is submitted, the transaction will **fail during precheck** and no record will be created. +#### Calldata Floor (EIP-7623) + +With the **Pectra** hard fork, [EIP-7623](https://eips.ethereum.org/EIPS/eip-7623) adds a floor so that transactions carrying a large amount of calldata pay at least a minimum, regardless of how little computation they perform. First define the calldata tokens: + +```bash +tokens_in_calldata = (number of zero bytes) + 4 × (number of non-zero bytes) +``` + +The gas charged is then the greater of the standard cost and the floor: + +```bash +standard = 21000 + 4 × tokens_in_calldata + execution gas +floor = 21000 + 10 × tokens_in_calldata +gas used = max(standard, floor) +``` + +- **4** (`STANDARD_TOKEN_COST`): the standard cost per calldata token (a non-zero byte is 4 tokens = 16 gas; a zero byte is 1 token = 4 gas) +- **10** (`TOTAL_COST_FLOOR_PER_TOKEN`): the floor cost per calldata token + +When a transaction is calldata-heavy relative to its execution, the floor applies and it costs more than under Cancun. The JSON-RPC Relay computes intrinsic gas as well, so its gas estimates reflect the floor. + + +The EIP-7623 calldata floor is part of Hedera's Pectra hard fork. See [Deploying Smart Contracts](/evm/development/deploying#pectra-hard-fork) for the full Pectra summary. + + This applies to both standard transactions and **jumbo EthereumTransactions** introduced by **[HIP-1086](https://hips.hedera.com/hip/hip-1086)**, which allow larger `callData` payloads. @@ -80,7 +105,7 @@ If `SLOAD` accesses a storage slot twice within the same transaction, the total - **Second Access (Warm)** = `100 + 100 = 200 gas` - **Final Gas Cost Total** = `2,400 gas` -📣 *Explore [opcodes in Cancun fork](https://www.evm.codes/).* +📣 *Explore [opcodes in Prague fork](https://www.evm.codes/?fork=prague).* ### Hedera System Contract Gas @@ -154,7 +179,7 @@ The **gas limit** is the maximum amount of gas you are willing to pay for an ope The current opcode gas fees are reflective as of the **[0.22 Hedera Service release](/networks/release-notes/services#v0.22)**. -| Operation | Cancun Cost (Gas) | Current Hedera (Gas) | +| Operation | Prague Cost (Gas) | Current Hedera (Gas) | | ------------------------------------------------------------------------ | ------------------------------------------- | ------------------------------------------- | | Code deposit | 200 \* bytes | 200 \* bytes | |

BALANCE
(cold account)

| 2600 | 2600 | diff --git a/native/smart-contracts/ethereum-transaction.mdx b/native/smart-contracts/ethereum-transaction.mdx index cbdd0007..6b0b7833 100644 --- a/native/smart-contracts/ethereum-transaction.mdx +++ b/native/smart-contracts/ethereum-transaction.mdx @@ -3,7 +3,7 @@ title: "Ethereum transaction" --- -An `EthereumTransaction` lets you execute a raw, RLP-encoded (type 0, 1, or 2) Ethereum transaction on the Hedera network. This enables developers familiar with EVM tooling to leverage their existing knowledge and infrastructure when interacting with the [Hedera Smart Contract Service (HSCS)](/evm/tutorials). +An `EthereumTransaction` lets you execute a raw, RLP-encoded Ethereum transaction on the Hedera network. Legacy, access list ([EIP-2930](https://eips.ethereum.org/EIPS/eip-2930)), and dynamic fee ([EIP-1559](https://eips.ethereum.org/EIPS/eip-1559)) transactions are supported; see [Supported Ethereum transaction types](#supported-ethereum-transaction-types). This enables developers familiar with EVM tooling to reuse their existing knowledge and infrastructure when interacting with the [Hedera Smart Contract Service (HSCS)](/evm/tutorials). #### **Important** @@ -17,7 +17,42 @@ Hedera interprets HBAR decimals differently depending on the context: Reference: [HIP-410](https://hips.hedera.com/hip/hip-410) -
FieldDescription
Ethereum DataAn RLP-encoded (type 0, 1, or 2) Ethereum transaction to execute on the Hedera network. This enables developers to leverage existing EVM tooling and workflows with the Hedera Smart Contract Service (HSCS).
Call Data File IDAn optional field referencing a file on the Hedera File Service (HFS) containing the callData. When set, the network ignores the callData in ethereumData during execution and instead loads the data from the referenced file. However, the full callData must still be present in the originally signed ethereumData for signature validation. In this case, ethereumData will contain a placeholder where callData normally resides, and the transaction must be "rehydrated" with the HFS content during validation.

Note: With HIP-1086, jumbo ethereumData is the preferred approach for large payloads, but callDataFileId remains supported for oversized payloads or legacy workflows.
Max Allowance

The maximum amount of HBAR (specified in tinybars) the payer is willing to cover for the gas consumed during transaction execution. This value acts as a ceiling if the actual gas cost (determined by gasLimit in the RLP-encoded transaction and the network's gas price) exceeds this amount, the transaction fails.

Ordinarily, the account with the ECDSA alias extracted from the ethereumData signature covers the execution fees. If insufficient fees are authorized by that account, the payer can be charged up to but not exceeding maxGasAllowance. If the authorized fee is zero, the payer is charged the full amount.

+
FieldDescription
Ethereum DataAn RLP-encoded Ethereum transaction (legacy, EIP-2930, or EIP-1559) to execute on the Hedera network. This enables developers to leverage existing EVM tooling and workflows with the Hedera Smart Contract Service (HSCS).
Call Data File IDAn optional field referencing a file on the Hedera File Service (HFS) containing the callData. When set, the network ignores the callData in ethereumData during execution and instead loads the data from the referenced file. However, the full callData must still be present in the originally signed ethereumData for signature validation. In this case, ethereumData will contain a placeholder where callData normally resides, and the transaction must be "rehydrated" with the HFS content during validation.

Note: With HIP-1086, jumbo ethereumData is the preferred approach for large payloads, but callDataFileId remains supported for oversized payloads or legacy workflows.
Max Allowance

The maximum amount of HBAR (specified in tinybars) the payer is willing to cover for the gas consumed during transaction execution. This value acts as a ceiling if the actual gas cost (determined by gasLimit in the RLP-encoded transaction and the network's gas price) exceeds this amount, the transaction fails.

Ordinarily, the account with the ECDSA alias extracted from the ethereumData signature covers the execution fees. If insufficient fees are authorized by that account, the payer can be charged up to but not exceeding maxGasAllowance. If the authorized fee is zero, the payer is charged the full amount.

+ +## Supported Ethereum transaction types + +`EthereumTransaction` accepts RLP-encoded Ethereum transactions of the following types: + +| Type | Name | EIP | Status on Hedera | +| --- | --- | --- | --- | +| `0x00` | Legacy | Pre-typed | Supported | +| `0x01` | Access list | [EIP-2930](https://eips.ethereum.org/EIPS/eip-2930) | Supported | +| `0x02` | Dynamic fee | [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559) | Supported | +| `0x03` | Blob | [EIP-4844](https://eips.ethereum.org/EIPS/eip-4844) | Not supported | +| `0x04` | Set code | [EIP-7702](https://eips.ethereum.org/EIPS/eip-7702) | Deactivated | + +Type 3 (blob) transactions are rejected because Hedera does not implement blobs ([HIP-866](https://hips.hedera.com/hip/hip-866)). Type 4 (set-code) transactions are part of Ethereum's Pectra upgrade, but **EIP-7702 is deactivated on Hedera**, so type 4 transactions are rejected and EOA code delegation is not available. Support is tracked for a future release under [HIP-1340](https://hips.hedera.com/hip/hip-1340). For type 2 (EIP-1559), the priority fee (`max_priority_fee_per_gas`) is ignored on Hedera because network fees are fixed by the fee schedule rather than a priority market. + +### Access lists (EIP-2930) + +A type 1 (and type 2) transaction can carry an `accessList`: a list of addresses and storage keys the transaction expects to touch. Pre-declaring these accesses marks them "warm," lowering the gas cost of the first access to each. An access list is encoded as an array of `{ address, storageKeys }` entries: + +```json +[ + { + "address": "0xa02457e5dfd32bda5fc7e1f1b008aa5979568150", + "storageKeys": [ + "0x0000000000000000000000000000000000000000000000000000000000000081" + ] + } +] +``` + +You can submit an access-list transaction either through the JSON-RPC Relay (`eth_sendRawTransaction`) or directly to HAPI via `EthereumTransaction`, where the access list is part of the RLP-encoded `ethereumData`. + + +Access lists are supported as part of Hedera's [Pectra](/evm/development/deploying#pectra-hard-fork) hard fork. + ## Handling Large callData Payloads diff --git a/support/glossary.mdx b/support/glossary.mdx index aac41fda..59e69d88 100644 --- a/support/glossary.mdx +++ b/support/glossary.mdx @@ -23,6 +23,14 @@ A 1/3 attack is a less discussed threat in distributed networks such as Hedera, ## A +### Access List (EIP-2930) + +--- + +An optional list of addresses and storage keys that a type 1 or type 2 Ethereum transaction declares it expects to access. Pre-declaring these accesses marks them "warm" and lowers the gas cost of the first access to each. Access lists are supported on Hedera as part of the [Prague](#prague-pectra) upgrade. + +📒 See [EIP-2930](https://eips.ethereum.org/EIPS/eip-2930) and the [Ethereum transaction](/native/smart-contracts/ethereum-transaction#access-lists-eip-2930) page. + ### Account Abstraction --- @@ -154,6 +162,12 @@ A block node is a service that receives the [block stream](#block-stream) from a The [consensus](#consensus) [timestamp](#timestamp) of the first transaction in the Record file. +### BLS12-381 + +--- + +A pairing-friendly elliptic curve widely used for signature aggregation and zero-knowledge proofs. [EIP-2537](https://eips.ethereum.org/EIPS/eip-2537), adopted by Hedera through the [Prague](#prague-pectra) upgrade ([HIP-1341](https://hips.hedera.com/hip/hip-1341)), adds seven precompiles at addresses `0x0b` through `0x11` for BLS12-381 curve operations. They perform curve arithmetic, multi-scalar multiplication, and pairing checks at a lower gas cost than an equivalent Solidity implementation. + ### Bytecode --- @@ -171,6 +185,12 @@ Bytecode is the information that Solidity code gets "translated" into. It contai Contract call trace information captures the input, output, and gas details of all the nested smart contracts functions executed in a transaction. On Ethereum, these are occasionally called inner transactions but they simply capture snapshots of the message frame consideration the EVM encounters when processing a smart contract execution at each depth for all involved functions. +### Calldata + +--- + +The input data sent with a transaction to a smart contract, encoding the function to call and its arguments. Calldata is priced per byte: zero bytes cost less than non-zero bytes. [EIP-7623](https://eips.ethereum.org/EIPS/eip-7623), adopted through the [Prague](#prague-pectra) upgrade, adds a gas floor that raises the cost of transactions carrying large amounts of calldata relative to the computation they perform. + ### Central Bank Digital Currency (CBDC) --- @@ -897,6 +917,12 @@ The integration showcases a groundbreaking application of distributed ledger tec ## P +### Pectra + +--- + +An Ethereum network upgrade (activated on Ethereum Mainnet in May 2025) that bundles a set of EIPs across the execution and consensus layers. Its execution-layer component is the [Prague](#prague-pectra) hard fork. Hedera adopts the applicable Pectra EIPs through [HIP-1341](https://hips.hedera.com/hip/hip-1341). + ### Peer-to-Peer (P2P) --- @@ -923,6 +949,12 @@ Permissionless means a system or property accessible by anyone without permissio A free and open-source relational database management system emphasizing extensibility and SQL compliance. [Mirror nodes](#mirror-nodes) use a PostgreSQL database to store the transaction and event data organized in a structure that mirrors the Hedera Network. +### Prague (Pectra) + +--- + +The execution-layer hard fork of Ethereum's [Pectra](#pectra) upgrade. On Hedera, Prague is defined by [HIP-1341](https://hips.hedera.com/hip/hip-1341), which adopts [EIP-2537](https://eips.ethereum.org/EIPS/eip-2537) ([BLS12-381](#bls12-381) precompiles), [EIP-7623](https://eips.ethereum.org/EIPS/eip-7623) (a [calldata](#calldata) gas floor), and [EIP-2930](#access-list-eip-2930) access lists. Blob and validator/consensus-layer EIPs are not adopted, and set-code / code delegation ([EIP-7702](https://eips.ethereum.org/EIPS/eip-7702)) is **deactivated**, tracked for a future release under [HIP-1340](https://hips.hedera.com/hip/hip-1340). + ### Precompile ---