test: Load transaction signature v as uint64#1571
Conversation
There was a problem hiding this comment.
Pull request overview
This PR fixes evmone-t8n rejecting valid legacy EIP-155 transactions whose signature v exceeds 0xff (common when chainId is large), by widening the transaction v field and its JSON loader to uint64_t.
Changes:
- Widen
state::Transaction::vfromuint8_ttouint64_t. - Update the state-test JSON loader to parse
vasuint64_tinstead ofuint8_t. - Add/extend unit tests to cover large
vvalues and the maximum legacy-EIP-155 chainId representable viauint64_tv.
Reviewed changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| test/utils/statetest_loader.cpp | Parse transaction v as uint64_t to avoid JSON parsing failures for v > 0xff. |
| test/state/transaction.hpp | Widen Transaction::v to uint64_t to match loader and legacy EIP-155 encoding needs. |
| test/unittests/tooling_t8n_test.cpp | Add a t8n regression test ensuring very large v values are accepted. |
| test/unittests/statetest_loader_tx_test.cpp | Add loader regression test for maximum legacy chainId / v representable in uint64_t. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| { | ||
| evmc::VM vm{evmc_create_evmone()}; | ||
|
|
||
| // Legacy EIP-155 `v` is chainId*2 + 35 + parity, exceeding 0xff for chainId >= 110. |
There was a problem hiding this comment.
Good catch — at chainId 110 with parity 0, v is exactly 0xff, not above it. Tightened the threshold to chainId > 110, where v exceeds 0xff for either parity.
A legacy EIP-155 transaction encodes `v` as chainId*2 + 35 + parity, so `v` exceeds 0xff for any chainId >= 110 (e.g. chainId 300 gives v=0x27c). The state-test loader narrowed `v` to `uint8_t` and `Transaction::v` was `uint8_t`, so `from_json<uint8_t>` threw `value > 0xFF` and `evmone t8n` rejected such transactions while geth `evm t8n` executes them. Widen `Transaction::v` and its loader to `uint64_t`, matching the `chainId` fix (#1570). `v` is only RLP-encoded for the transaction hash, so the wider type is encoded correctly with no other behavior change. Fixes #1487.
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #1571 +/- ##
=======================================
Coverage 97.37% 97.37%
=======================================
Files 163 163
Lines 14529 14572 +43
Branches 3388 3393 +5
=======================================
+ Hits 14147 14190 +43
Misses 280 280
Partials 102 102
Flags with carried forward coverage won't be shown. Click here to find out more.
🚀 New features to boost your workflow:
|
A legacy EIP-155 transaction encodes
vas chainId*2 + 35 + parity, sovexceeds 0xff for any chainId >= 110 (e.g. chainId 300 gives v=0x27c). The state-test loader narrowedvtouint8_tandTransaction::vwasuint8_t, sofrom_json<uint8_t>threwvalue > 0xFFandevmone t8nrejected such transactions while gethevm t8nexecutes them.Widen
Transaction::vand its loader touint64_t, matching thechainIdfix (#1570).vis only RLP-encoded for the transaction hash, so the wider type is encoded correctly with no other behavior change.Fixes #1487.