fix(test): sign state-test transactions instead of using a placeholder signature

[felix314159]

during fuzzing i saw nethtest crash and here is the fix (case is not relevant for mainnet). for more context and instructions on how to reproduce check out the execution-specs PR which can be used for verifying the current crash and that this fix works. thank you for your attention to this matter

Changes

• fixes crash in state test tooling

Types of changes

What types of changes does your code introduce?

• Bugfix (a non-breaking change that fixes an issue)

Testing

Requires testing

• Yes
• No

If yes, did you write tests?

• Yes
• No

[flcl42]

@claude review

[claude]

Claude finished @flcl42's task in 2m 46s —— View job

---

Code Review

• Gather context and read changed files
• Analyze the diff and correctness
• Check adherence to coding rules and test guidelines
• Post findings

---

Summary

The fix is correct. The root cause is clear: state tests carry a placeholder signature (1, 1, 27) on their transactions. When the sender account is absent from the pre-state (e.g. a zero-gas-price transaction), TransactionProcessor.RecoverSenderIfNeeded re-derives the sender from that bogus signature, gets a wrong address, then crashes trying to increment a nonce on it. Signing with the actual secretKey makes recovery deterministic and consistent with the intended sender.

The chainId threading through the call chain is also correct — the test's configured chain ID is already loaded at the Convert(string, string, GeneralStateTestJson) call site and passed down.

---

Findings

No Critical / High / Medium issues.

Low — double PrivateKey allocation

new PrivateKey(transactionJson.SecretKey) at line 125 and again at line 217. The intermediate Address could be stored and the key reused, avoiding a duplicate secp256k1 scalar parse. Inconsequential in test infra, but easy to clean up.

Low — redundant SenderAddress re-assignment (line 219)

transaction.SenderAddress = privateKey.Address is set to the same value already written at line 125. The only code path that changes SenderAddress to something other than privateKey.Address is the auth-list validation, which sets it to Address.Zero — excluded by the != Address.Zero guard. Consider removing to reduce noise.

Low — isEip155Enabled: false is correct but worth a one-liner

Hardcoding false here is the right call: state tests conventionally use pre-EIP-155 (V=27|28) signatures, which are valid (and recoverable) in every fork. A brief inline note like // state tests use pre-EIP-155 (V=27/28) signatures next to the Sign call would make this self-evident to future readers, especially since the default for IEthereumEcdsa.Sign is isEip155Enabled: true.

---

Correctness check

Concern	Verdict
Crash path fixed	✅ Signing with real key prevents bogus recovery
Address.Zero guard for intentionally-invalid txs	✅ Correct
chainId propagation	✅ Loaded from test config and passed through
Non-legacy typed txs (EIP-1559, Blob, SetCode)	✅ isEip155Enabled only affects legacy V adjustment; chain ID embedded in typed tx via tx.ChainId = ecdsa.ChainId
Hash recalculation after signing	✅ Required, correctly done
SecretKey is not null guard	✅ Defensive; note that line 125 would already throw if null

---

Mergeable. Nits above are take-or-leave; none block the fix.

[flcl42]

Thanks the fix!