core/txpool: add 7702 protection to blobpool #31526

[gzliudan]

Proposed changes

Ref: ethereum#31526

Types of changes

What types of changes does your code introduce to XDC network?
Put an ✅ in the boxes that apply

• Bugfix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation Update (if none of the other choices apply)
• Regular KTLO or any of the maintaince work. e.g code style
• CICD Improvement

Impacted Components

Which part of the codebase this PR will touch base on,

Put an ✅ in the boxes that apply

• Consensus
• Account
• Network
• Geth
• Smart Contract
• External components
• Not sure (Please specify below)

Checklist

Put an ✅ in the boxes once you have confirmed below actions (or provide reasons on not doing so) that

• This PR has sufficient test coverage (unit/integration test) OR I have provided reason in the PR description for not having test coverage
• Provide an end-to-end test plan in the PR description on how to manually test it on the devnet/testnet.
• Tested the backwards compatibility.
• Tested with XDC nodes running this version co-exist with those running the previous version.
• Relevant documentation has been updated as part of this PR
• N/A

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Note

Other AI code review bot(s) detected

CodeRabbit has detected other AI code review bot(s) in this pull request and will avoid duplicating their findings in the review comments. This may lead to a less comprehensive review.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[Copilot]

Pull request overview

This PR adds support for EIP-7702 SetCode transactions (type 0x04) with protection mechanisms to prevent transaction pool abuse. The key changes introduce a lazy transaction wrapper to defer full transaction resolution until needed, a reservation system to prevent address conflicts across subpools, and specialized handling for delegated accounts.

Key changes:

• Introduced LazyTransaction wrapper to optimize transaction handling by deferring full resolution
• Added cross-subpool address reservation tracking via ReservationTracker and Reserver to prevent conflicts
• Implemented delegation limits restricting accounts with deployed or pending delegations to a single in-flight transaction
• Moved transaction ordering logic from core/types to miner package with support for lazy transactions

Reviewed changes

Copilot reviewed 18 out of 18 changed files in this pull request and generated 9 comments.

Show a summary per file

File	Description
miner/ordering.go	New transaction ordering implementation using LazyTransaction with miner fee calculation
miner/ordering_test.go	Comprehensive tests for transaction ordering including legacy, EIP-1559, and special transaction separation
miner/worker.go	Updated to use LazyTransaction wrapper and new ordering functions
core/txpool/reserver.go	New reservation tracking system to ensure address exclusivity across subpools
core/txpool/txpool.go	Updated to create and pass reservation tracker to subpools
core/txpool/subpool.go	Added LazyTransaction type and updated SubPool interface signatures
core/txpool/validation.go	Added Prague fork validation for SetCode transactions and authorization checks
core/txpool/errors.go	Added new error types for account limits, reservations, and in-flight limits
core/txpool/legacypool/legacypool.go	Major changes: reservation tracking, SetCode validation, delegation limit enforcement, authority tracking
core/txpool/legacypool/legacypool_test.go	Extensive tests for SetCode transactions, delegations, and reorgs
core/txpool/legacypool/legacypool2_test.go	Updated test initialization to include reserver
core/types/transaction.go	Removed ordering code (moved to miner), added SetCodeAuthorities() and Time-related helper methods
core/types/transaction_test.go	Removed tests that were moved to miner package
core/types/tx_setcode.go	Changed SignSetCode parameter order from (auth, prv) to (prv, auth)
eth/protocol.go	Updated txPool interface Pending signature to return LazyTransaction
eth/sync.go	Updated to resolve LazyTransaction before appending to transaction list
eth/api_backend.go	Updated to resolve LazyTransaction when retrieving pool transactions
eth/helper_test.go	Updated test helper to return LazyTransaction from Pending

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Missing nil check for resolved transaction. If lazyTx.Resolve() returns nil or warped.Tx is nil, the code breaks at line 1089 when calling tx.To(). The break statement at line 1086 prevents processing nil transactions, but the logic should also handle the case where Resolve succeeds but Tx is nil, or skip to the next transaction instead of breaking the entire loop.

Suggested change

	break
	log.Debug("Skipping nil resolved transaction")
	txs.Pop()
	continue

[Copilot]

Potential nil pointer dereference. At line 253, the code checks if resolved is nil or resolved.Tx.To() is nil. However, if resolved is not nil but resolved.Tx is nil, the code will panic when accessing resolved.Tx.To(). The check should be updated to include resolved.Tx != nil before accessing resolved.Tx.To().

Suggested change

	if resolved == nil || resolved.Tx.To() == nil || *resolved.Tx.To() == common.BlockSignersBinary {
	if resolved == nil || resolved.Tx == nil || resolved.Tx.To() == nil || *resolved.Tx.To() == common.BlockSignersBinary {

[Copilot]

The Clear method iterates over pool.all.locals and pool.all.remotes to release reservations, but this doesn't handle the case where multiple transactions from the same account are in the pool. Since each unique account should only have one reservation, calling Release for each transaction from the same sender will result in multiple Release calls for the same address. This will trigger the "pool attempted to unreserve non-reserved address" error logged at line 102 of reserver.go for all but the first transaction from each account. The code should track unique sender addresses and only release each address once.

Suggested change

	// acquire the subpool lock until the transaction addition is completed.
	for _, tx := range pool.all.locals {
	senderAddr, _ := types.Sender(pool.signer, tx)
	pool.reserver.Release(senderAddr)
	}
	for _, tx := range pool.all.remotes {
	senderAddr, _ := types.Sender(pool.signer, tx)
	// acquire the subpool lock until the transaction addition is completed.
	senders := make(map[common.Address]struct{})
	for _, tx := range pool.all.locals {
	senderAddr, _ := types.Sender(pool.signer, tx)
	if _, seen := senders[senderAddr]; seen {
	continue
	}
	senders[senderAddr] = struct{}{}
	pool.reserver.Release(senderAddr)
	}
	for _, tx := range pool.all.remotes {
	senderAddr, _ := types.Sender(pool.signer, tx)
	if _, seen := senders[senderAddr]; seen {
	continue
	}
	senders[senderAddr] = struct{}{}