Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
34 changes: 16 additions & 18 deletions CHANGELOG.md
Original file line number Diff line number Diff line change
Expand Up @@ -7,38 +7,36 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0

## [Unreleased]

> **Note:** v0.3.0 was never released (only `v0.3.0-beta` shipped). Changes originally staged under v0.3.0 are rolled into v0.4.0 below so the upgrade path is v0.2.x → v0.4.0.

### Added

- `EV_TRACE_LEVEL` env var to control OTLP span export verbosity independently from `RUST_LOG` stdout log level ([#156](https://github.com/evstack/ev-reth/issues/156))
- `ev-deployer` CLI (`bin/ev-deployer`) for generating genesis alloc entries with embedded contract bytecodes ([#167](https://github.com/evstack/ev-reth/pull/167))
- `ev-dev` binary (`bin/ev-dev`): one-command local development chain with pre-funded Hardhat accounts, similar to Anvil or Hardhat Node
- Transaction sponsor service (`bin/sponsor-service`) for signing EvNode transactions on behalf of users via JSON-RPC proxy ([#141](https://github.com/evstack/ev-reth/pull/141))
- Granular tracing instrumentation spans across payload building, transaction validation, and EVM execution
- `EV_TRACE_LEVEL` env var to control OTLP span export verbosity independently from `RUST_LOG` stdout log level ([#156](https://github.com/evstack/ev-reth/issues/156))
- EvNode transaction type (0x76) with atomic batch calls and fee-payer sponsorship ([#103](https://github.com/evstack/ev-reth/pull/103))
- Viem client library (`@evstack/evnode-viem`) for building, signing, and sponsoring EvNode transactions ([#112](https://github.com/evstack/ev-reth/pull/112))
- End-to-end tests for the EvNode client ([#118](https://github.com/evstack/ev-reth/pull/118))
- Tini init process in Docker images for proper signal handling ([#115](https://github.com/evstack/ev-reth/pull/115))

### Changed

- Upgraded Reth from v1.8.4 to v2.0.0 with Osaka/EOF hardfork support, Storage V2, revm 36.0.0, and alloy-evm 0.30.0 ([#106](https://github.com/evstack/ev-reth/pull/106), [#207](https://github.com/evstack/ev-reth/pull/207))
- `reth-primitives` imports migrated to `alloy_consensus` and `reth_ethereum_primitives` (upstream crate removed)
- Txpool fallback (pulling pending transactions when Engine API attributes are empty) restricted to `--dev` mode only
- Migrated build system from Makefile to Justfile
- Disabled default features on several reth crates to unblock SP1 proving work ([#111](https://github.com/evstack/ev-reth/pull/111))
- Removed unused `thiserror` dependency from `ev-precompiles` crate

### Fixed

- Payload builder now uses `decode_2718_exact` instead of `network_decode` for Engine API payloads, fixing silent drops of valid type 0x76 and EIP-1559/EIP-2930 transactions ([#219](https://github.com/evstack/ev-reth/pull/219))
- Payload builder now pulls pending transactions from the txpool in `--dev` mode, fixing `cast send` and other RPC-submitted transactions not being included in blocks
- Txpool now uses sponsor balance for pending/queued ordering in sponsored EvNode transactions, and validates executor balance separately for call value transfers ([#141](https://github.com/evstack/ev-reth/pull/141))

## [0.3.0] - 2026-02-23

### Added

- EvNode transaction type (0x76) with atomic batch calls and fee-payer sponsorship ([#103](https://github.com/evstack/ev-reth/pull/103))
- Viem client library (`@evstack/evnode-viem`) for building, signing, and sponsoring EvNode transactions ([#112](https://github.com/evstack/ev-reth/pull/112))
- End-to-end tests for the EvNode client ([#118](https://github.com/evstack/ev-reth/pull/118))
- Tini init process in Docker images for proper signal handling ([#115](https://github.com/evstack/ev-reth/pull/115))

### Fixed

- Permissioned EVM deploy allowlist validation when gas is explicitly specified ([#122](https://github.com/evstack/ev-reth/pull/122))

### Changed

- Upgraded Reth from v1.8.4 to v1.11.0 with Osaka hardfork and EOF support ([#106](https://github.com/evstack/ev-reth/pull/106))
- Disabled default features on several reth crates to unblock SP1 proving work ([#111](https://github.com/evstack/ev-reth/pull/111))
- Additional test coverage for deploy allowlist edge cases across all transaction types

## [0.2.2] - 2026-01-22

Expand Down
212 changes: 0 additions & 212 deletions docs/UPGRADE-v0.3.0.md

This file was deleted.

127 changes: 127 additions & 0 deletions docs/UPGRADE-v0.4.0.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,127 @@
# Upgrade Guide: v0.4.0

This guide covers the configuration changes required to upgrade ev-reth to v0.4.0. For a full list of changes, see the [CHANGELOG](../CHANGELOG.md).

> **Note:** v0.3.0 was never released. Operators running a v0.3.0-beta build should follow "Upgrading from v0.2.x" below.

## Upgrading from v0.2.x

No configuration changes required. Rebuild and deploy the new binary.

**What changes automatically:**

- Reth v2.0.0 engine (same config, new internals)
- New nodes use Storage V2 by default. Existing V1 data directories continue working as-is
- Txpool fallback (pulling pending transactions when Engine API attributes are empty) is now only enabled in `--dev` mode
- EIP-2718 payload decode fix takes effect immediately

**Build system:** If you have scripts referencing `make`, update them to use `just`.

**Storage V2 notes:**

- V1 and V2 are not interchangeable. Once a node starts with V2, it cannot go back
- No automatic migration. Switching to V2 requires a full resync
- V1 is deprecated upstream. Plan your migration before support is removed
- If using MDBX backup scripts (e.g. `mdbx_copy`), V2 nodes also use RocksDB for indices, so backup tooling may need updating

**Custom code:** If you import from `reth-primitives`, update imports to `alloy_consensus` or `reth_ethereum_primitives` (the crate was removed upstream).

### Osaka / EOF hardfork

The Osaka hardfork (EVM Object Format, EOFv1) is available but not activated by default. If your chainspec does not already set `osakaTime`, the chain stays on Cancun rules and no action is required.

To schedule activation, add `osakaTime` to your chainspec `config` section with a future Unix timestamp (use `0` on new testnets to activate from genesis):

```json
{
"config": {
"osakaTime": 1893456000
}
}
```

Osaka introduces EOFv1 contracts and related EIPs. See the [v0.2.0 upgrade guide](UPGRADE-v0.2.0.md) for the original `osakaTime` rollout notes and the [Ethereum EOF meta EIP (EIP-7692)](https://eips.ethereum.org/EIPS/eip-7692) for the full list of included changes.

## Upgrading from v0.1.x
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can we point people to other upgrade guides to avoid mentioning everything every time


First follow [UPGRADE-v0.2.0.md](UPGRADE-v0.2.0.md) and [UPGRADE-v0.2.2.md](UPGRADE-v0.2.2.md) to reach v0.2.x, then apply "Upgrading from v0.2.x" above. Those guides cover the required `osakaTime`, base fee redirect, native token minting precompile, contract size limit, deploy allowlist, and EIP-1559 parameter chainspec changes.

## Complete Chainspec Reference

All `config.evolve` fields available in v0.4.0:

| Field | Type | Default | Since | Description |
|-------|------|---------|-------|-------------|
| `baseFeeSink` | `address` | -- | v0.2.0 | Receives redirected base fees |
| `baseFeeRedirectActivationHeight` | `u64` | `0` | v0.2.0 | Block height when redirect activates |
| `mintAdmin` | `address` | -- | v0.2.0 | Admin for mint/burn precompile |
| `mintPrecompileActivationHeight` | `u64` | `0` | v0.2.0 | Block height when precompile activates |
| `contractSizeLimit` | `usize` | `24576` | v0.2.0 | Max contract code size in bytes |
| `contractSizeLimitActivationHeight` | `u64` | `0` | v0.2.0 | Block height when custom limit activates |
| `deployAllowlist` | `address[]` | `[]` | v0.2.2 | Addresses allowed to deploy contracts (max 1024) |
| `deployAllowlistActivationHeight` | `u64` | `0` | v0.2.2 | Block height when allowlist activates |
| `baseFeeMaxChangeDenominator` | `u64` | `8` | v0.2.2 | Max base fee change per block |
| `baseFeeElasticityMultiplier` | `u64` | `2` | v0.2.2 | Gas target multiplier |
| `initialBaseFeePerGas` | `u64` | `1000000000` | v0.2.2 | Initial base fee in wei |

Top-level `config` fields:

| Field | Type | Default | Since | Description |
|-------|------|---------|-------|-------------|
| `osakaTime` | `u64` | -- | v0.2.0 | Unix timestamp to activate Osaka/EOF hardfork |

## Complete Chainspec Example

```json
{
"config": {
"chainId": 12345,
"homesteadBlock": 0,
"eip150Block": 0,
"eip155Block": 0,
"eip158Block": 0,
"byzantiumBlock": 0,
"constantinopleBlock": 0,
"petersburgBlock": 0,
"istanbulBlock": 0,
"berlinBlock": 0,
"londonBlock": 0,
"parisBlock": 0,
"shanghaiTime": 0,
"cancunTime": 0,
"osakaTime": 1893456000,
"terminalTotalDifficulty": 0,
"terminalTotalDifficultyPassed": true,
"evolve": {
"baseFeeSink": "0x00000000000000000000000000000000000000fe",
"baseFeeRedirectActivationHeight": 0,
"baseFeeMaxChangeDenominator": 5000,
"baseFeeElasticityMultiplier": 10,
"initialBaseFeePerGas": 100000000000000000,
"mintAdmin": "0x000000000000000000000000000000000000Ad00",
"mintPrecompileActivationHeight": 0,
"contractSizeLimit": 131072,
"contractSizeLimitActivationHeight": 0,
"deployAllowlist": [
"0xYourDeployerAddress"
],
"deployAllowlistActivationHeight": 0
}
},
"difficulty": "0x1",
"gasLimit": "0x2faf080",
"baseFeePerGas": "0x16345785d8a0000",
"alloc": {}
}
```

## Related Documentation

- [EIP-1559 Configuration](eip1559-configuration.md) -- tuning base fee parameters
- [Permissioned EVM Guide](guide/permissioned-evm.md) -- deploy allowlist details
- [Fee System Guide](guide/fee-systems.md) -- base fee redirect and FeeVault
- [ADR 003: Typed Transactions](adr/ADR-0003-typed-transactions-sponsorship.md) -- EvNode 0x76 spec

## Questions?

For issues or questions about the upgrade, please open an issue at <https://github.com/evstack/ev-reth/issues>
Loading