🤖 Kimi Code Review

Overall Assessment:
The PR correctly fixes an edge case where zero-value transfers were incorrectly creating/touching accounts, affecting EIP-7702 authorization gas costs. The fix is minimal and the test coverage is comprehensive.

crates/vm/levm/src/db/gen_db.rs

Lines 551-553 and 581-583
The early returns for zero-value balance changes are correct and necessary for EIP-7702 compliance.

• Rationale: EIP-7702 charges different gas based on whether the authority account exists. A zero-value transfer should not mark an account as "existing" or touch it, as this would artificially inflate the gas cost of subsequent authorization validations.
• Safety: These checks prevent unnecessary account creation via get_account_mut when the net balance change is zero, which aligns with Ethereum's state semantics (no state modification occurs when transferring 0 wei).
• Note: Ensure get_account_mut does not perform side effects (like cache warming) that are required even for zero-value operations. If the cache expects all accessed addresses to be present, this early return might need adjustment, but for pure balance operations this is correct.

test/tests/blockchain/eip7702_zero_transfer_tests.rs

Lines 130-145 (sign_auth_tuple)
Correctly implements EIP-7702 authorization signing:

• Magic byte 0x05 is correct per the EIP.
• RLP encoding order [chain_id, address, nonce] matches the specification.
• Hashing and secp256k1 signature serialization are standard.

Lines 247-248
The gas comparison assertion is the correct way to verify the fix. If the zero-value transfer polluted the authority state, the subsequent EIP-7702 transaction would consume different gas (specifically, it would skip the account creation cost).

Minor Suggestions:

1. Line 48: Consider using CARGO_MANIFEST_DIR with a fallback or documenting that this test must run from the workspace root. The path fixtures/genesis/execution-api.json assumes a specific directory structure.

2. Line 16 (TEST_PRIVATE_KEY): While acceptable for integration tests, add a comment confirming this is a deterministic test key with no mainnet/testnet funds.

3. Lines 72, 90: The sign_inplace method is called with .await.unwrap(). Ensure this handles potential signature errors gracefully in the test context (current usage is fine for tests).

Security: No vulnerabilities detected. The test correctly validates that state isolation is maintained between unrelated transactions.

Performance: The early returns in gen_db.rs provide a minor optimization by avoiding unnecessary state lookups and cache modifications.

Conclusion: LGTM. The fix is precise, and the test validates the specific EIP-7702 interaction that was broken.

Automated review by Kimi (Moonshot AI) · kimi-k2.5 · custom prompt

Greptile Summary

This PR fixes a bug where sending a zero-value transfer to an empty account would incorrectly mark that account as "existing" in the VM's cache, causing EIP-7702 gas to be charged at the wrong (lower) rate in a subsequent set_code authorization for that authority.

• Root cause fix in gen_db.rs: increase_account_balance and decrease_account_balance now early-return when the amount is zero, preventing get_account_mut (and its side-effecting load_account / mark_modified chain) from being called unnecessarily.
• Regression test added in eip7702_zero_transfer_tests.rs: runs two scenarios—with and without a preceding zero-value transfer to the authority—and asserts the EIP-7702 transaction uses identical gas in both cases.

Confidence Score: 5/5

Safe to merge — the change is a small, targeted early-return that removes an unintended side effect, covered by a new end-to-end integration test.

The fix is minimal and well-scoped: two identical early-return guards added to functions that previously had no callers relying on the zero-value side-effect. The existing transfer wrapper already skipped both calls for zero values, so the only paths affected are direct callers that did not have their own guard. The new integration test directly validates the gas difference that motivated the bug report.

No files require special attention.

_{Reviews (1): Last reviewed commit: "do not mark the account as modified when..." | Re-trigger Greptile}

Lines of code report

Total lines added: 6
Total lines removed: 0
Total lines changed: 6

+----------------------------------------+-------+------+
| File                                   | Lines | Diff |
+----------------------------------------+-------+------+
| ethrex/crates/vm/levm/src/db/gen_db.rs | 560   | +6   |
+----------------------------------------+-------+------+

🤖 Codex Code Review

No findings.

The change in gen_db.rs and gen_db.rs looks correct: skipping get_account_mut() for zero deltas prevents a non-existent account from being marked modified/existing, and that exists bit is exactly what EIP-7702 refund logic consumes in utils.rs. This is the right fix layer, since transfer_value() still calls increase_account_balance() even when msg_value == 0 in default_hook.rs. The new regression in eip7702_zero_transfer_tests.rs covers the intended end-to-end behavior well by asserting receipt gas parity across the polluted/non-polluted scenario.

I couldn’t run the new test locally: cargo needs to materialize the libssz git dependency, but this environment blocks writes to the Cargo/Rustup cache and has no network access, so runtime verification is still pending.

Automated review by OpenAI Codex · gpt-5.4 · custom prompt

🤖 Claude Code Review

Now I have everything I need. Here is the full review:

PR #6591 — fix(l1): account erroneously considered as existing after zero-value transfer

Overview

This PR fixes a gas accounting bug in EIP-7702 processing. When a zero-value transfer is sent to an empty account (notably an EIP-7702 authority address), increase_account_balance calls get_account_mut, which calls mark_modified(), which unconditionally sets exists = true on the account. If an EIP-7702 authorization list is processed in a later transaction in the same block, authority_exists = true triggers an incorrect gas refund (REFUND_AUTH_PER_EXISTING_ACCOUNT = 12500 gas pre-Amsterdam, or STATE_GAS_NEW_ACCOUNT post-Amsterdam).

The fix adds early returns in increase_account_balance and decrease_account_balance when the amount is zero, preventing any account from being loaded or marked modified.

Code Fix (crates/vm/levm/src/db/gen_db.rs)

Correctness — correct. The root cause is in transfer_value (default_hook.rs:655), which calls vm.increase_account_balance(to, value) directly without a zero-check:

// hooks/default_hook.rs — this is the entry point for the bug
pub fn transfer_value(vm: &mut VM<'_>) -> Result<(), VMError> {
    if !vm.is_create()? {
        let value = vm.current_call_frame.msg_value;
        let to = vm.current_call_frame.to;
        vm.increase_account_balance(to, value)?;  // no zero guard

Similarly, undo_value_transfer (default_hook.rs:207–213) calls both decrease_account_balance and increase_account_balance with msg_value without guarding for zero. The early returns in the individual functions are the right fix — they protect all call sites without requiring defensive guards at every caller.

Interaction with transfer: The transfer method (gen_db.rs:606) already has if value != U256::zero(). That guard is now redundant (harmless but slightly more efficient since it avoids two function calls). No action required.

BAL recorder skipped for zero-ops: The set_initial_balance / record_balance_change recorder calls are also skipped when returning early. This is correct — there is no balance change to record.

No observable behaviour change for non-zero paths: The early return only fires for the exact zero case; all other paths are unchanged.

Test (test/tests/blockchain/eip7702_zero_transfer_tests.rs)

Test design — solid. The gas-delta comparison approach directly tests the observable consequence of the bug: incorrect gas refund changes the per-transaction gas cost. Running both "polluted" and "control" scenarios and asserting equality is clear and hard to fake.

Potential issues:

• Duplicated magic constant (test file:25): EIP_7702_MAGIC: u8 = 0x05 is already exported as pub const MAGIC: u8 = 0x05; in crates/vm/levm/src/constants.rs:85. The test should import and reuse that constant to prevent divergence if the spec changes.

• sign_auth_tuple is a local re-implementation: The test's sign_auth_tuple function manually mirrors the signing logic from eip7702_recover_address (utils.rs:205). If either diverges from the spec, the test could silently start signing auth tuples that the verifier rejects or accepts for wrong reasons. Consider extracting a shared test helper or re-using existing signing utilities if any exist.

• y_parity cast verbosity (test file:96): U256::from(Into::<i32>::into(recovery_id) as u64) — recovery_id as u8 as u64 would be cleaner and equally correct since RecoveryId is 0 or 1.

• tx_index cast to u64 (test file:215): tx_index as u64 — not wrong for any real block, but a comment or assert bounding the value would be defensive and make intent clear.

• auth_tuple.nonce is hardcoded to 0 (test file:179): This is correct for a fresh authority account. A comment explaining "authority has nonce 0 since it never sent a tx" would help future readers.

• run_scenario only tests gas, not delegation result: The test correctly verifies gas parity but does not assert that the delegation itself succeeded (i.e., that the authority's code was set to the expected delegation designator). The assertion receipt_7702.succeeded (test file:218) covers the success case but a check on the authority's code post-block would strengthen confidence that the entire auth flow completed correctly, not just that gas was the same. This is a "nice to have", not a blocker.

Security / Consensus Implications

The bug is exploitable within a block: a sender can include a zero-value transfer to a target authority address in tx N, then include an EIP-7702 tx in tx N+1 (same block) that uses that authority, and incorrectly receive up to 12,500 gas of refund (pre-Amsterdam) or STATE_GAS_NEW_ACCOUNT (post-Amsterdam) that they are not entitled to. The impact is bounded and local to a single block but represents a real consensus divergence from EELS/geth.

Summary

The fix is minimal, correctly placed, and addresses the root cause. The test is well-structured and directly proves the intended invariant. The items above are minor quality improvements — the EIP_7702_MAGIC duplication and the sign_auth_tuple re-implementation being the most worth addressing before merge.

Automated review by Claude (Anthropic) · sonnet · custom prompt

Benchmark Results Comparison

No significant difference was registered for any benchmark run.