kona: defer invalid span-batch tx types to the typed decoder#21850
Open
sebastianst wants to merge 2 commits into
Open
kona: defer invalid span-batch tx types to the typed decoder#21850sebastianst wants to merge 2 commits into
sebastianst wants to merge 2 commits into
Conversation
Builds on the prefix-preservation fix. read_tx_data no longer rejects Deposit (0x7E) inline: like a leading 0x00, a physically-present Deposit prefix is kept and rejected once by the typed decoder (SpanBatchTransactionData::decode) downstream, matching op-node's ReadTxData -> decodeTyped deferral. Only a byte that maps to no OpTxType at all is still rejected at the reader, since it cannot be represented in the returned type. This removes the inconsistency where a leading 0x00 was preserved-and-deferred while Deposit was rejected inline; both are now handled the same way. Adds tests for the deferred Deposit and the inline-rejected unknown bytes, and corrects the EIP2718_MAX_TX_TYPE doc/test wording about which high bytes fail where. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
read_tx_data is span-batch-specific — it size-bounds against MAX_SPAN_BATCH_ELEMENTS and returns SpanBatchError — with a single caller in decode_tx_data, so it doesn't belong in the general utils module. Relocate it (with its EIP2718_MAX_TX_TYPE const and tests) into batch/transactions.rs, make it private, and drop the crate re-export. Add a doc comment describing its narrow responsibility — split an element into its optional type prefix and RLP payload, validating only RLP structure — and noting it does not yet discard invalid transaction types, which are rejected downstream by the typed decoder in full_txs. No behavior change. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
sebastianst
marked this pull request as ready for review
July 17, 2026 09:32
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Stacks on #21808 (base =
codex/pr-21795-prefix-preservation). Two commits.1. Defer invalid tx types to the typed decoder
Resolves the one inconsistency left in #21808: a leading
0x00was preserved and deferred to the typed decoder, whileDeposit(0x7E) was still rejected inline inread_tx_data.This defers
Deposittoo. Now every representable type that isn't a valid span-batch envelope —Legacy(0x00) andDeposit— is kept and rejected in one place,SpanBatchTransactionData::decode/decode_typed, downstream infull_txs, mirroring op-node'sReadTxData→decodeTypeddeferral. The only remaining inline rejection is for a byte that maps to noOpTxTypeat all (0x03,0x7F, …), which can't be represented in the returned type — a type-forced boundary, not a special case.One-line production change (drop
Ok(OpTxType::Deposit)from the reader's reject arm). Kept theOpTxTypereturn rather than switching to a rawu8: fully deferring unknown bytes too would have required theu8return + aVec<u8>tx_typesfield, adding churn acrossdecode_tx_data/add_txsfor no consensus gain (unknown bytes are dropped either way). Adds a deferred-Depositand an inline-rejected unknown-byte test, and corrects theEIP2718_MAX_TX_TYPEwording about which high bytes fail where.2. Move
read_tx_datainto the batch moduleread_tx_datawas in the generalutilsmodule but is span-batch-specific — it size-bounds againstMAX_SPAN_BATCH_ELEMENTS, returnsSpanBatchError, and has a single caller indecode_tx_data. Relocate it (with itsEIP2718_MAX_TX_TYPEconst and tests) intobatch/transactions.rs, make it private, and drop the crate re-export (no cross-crate users). Adds a doc comment describing its narrow responsibility (split element → optional type prefix + RLP payload, RLP-structure validation only) and noting it does not yet discard invalid tx types — those are rejected downstream by the typed decoder infull_txs. No behavior change.Consensus-equivalence verified for #1: for any first byte
0x00..=0xFF, kona and op-node accept/reject the same and drop the same batches;legacy_tx_count/protected_bitssizing is unchanged.kona-protocolsuite green (231); fmt, clippy, andcargo doc -D warningsall clean.Draft — for review.
🤖 Generated by Claude Opus 4.8 (1M context)