feat: enforce blacklist for native coin transfers across txpool, execution, and consensus layers

[code0xff]

Overview

This pull request introduces protocol-level blacklist enforcement across transaction validation, EVM execution, and consensus signing.
The enforcement applies to operations that can initiate native coin (value) transfers, preventing blacklisted accounts from sending or receiving value or benefiting from balance transfers under the Anzeon fork rules.

---

Files Modified

core/txpool

• blobpool/blobpool.go
• legacypool/legacypool.go
• validation.go

core/state_transition.go

core/vm

• errors.go
• evm.go
• instructions.go

consensus/wbft

• common/errors.go
• engine/engine.go

tests

• consensus/wbft/engine/engine_test.go
• core/txpool/validation_test.go
• core/vm/evm_test.go
• core/vm/instructions_test.go

---

Key Changes

1. Transaction Pool Validation

Transactions are rejected when:

• The sender (from) is blacklisted
• The recipient (to) is blacklisted
• The delegated fee payer (if applicable) is blacklisted

2. State Transition Enforcement

Transactions are rejected during execution when:

• The sender (from) is blacklisted
• The recipient (to) is blacklisted
• The delegated fee payer (if applicable) is blacklisted

3. EVM Execution Enforcement

Blacklist checks were added to execution paths that can result in native value transfers, including:

• Contract call
• Contract creation
• Self-destruct operations, where:
  • The contract performing the self-destruct is rejected if it is blacklisted
  • The beneficiary receiving the remaining balance is rejected if it is blacklisted

4. Consensus Signer Validation

• Blocks are rejected when the block signer (coinbase) is blacklisted

5. Error Handling and Testing Improvements

• Added layer-specific errors to correctly represent blacklist violations in protocol, execution, and consensus contexts
• Added and updated tests to cover blacklist handling in txpool, EVM execution, and consensus signer validation

---

Testing

• Comprehensive blacklist enforcement tests added across affected components
• Clear positive/negative scenarios introduced for each enforcement path
• Confirmed consistent error handling across all layers

---

Request for Review

• Verify correctness of blacklist checks across all value-transfer paths
• Confirm error consistency across txpool, execution, and consensus layers
• Evaluate whether additional edge cases require coverage

---

Related Issue

• Close: Blacklisting Functionality #11

[0xmhha]

Should we also add blacklist validation for DELEGATECALL to prevent potential bypass vectors?

[eomti-wm]

It looks like the error messages for blacklisted accounts are following a similar pattern.
What do you think about switching to a structured error type instead of using a simple errors.New(...)?

For example:

type ErrBlacklistedAccount struct {
	Address common.Address
	Role    string
}

func (e *ErrBlacklistedAccount) Error() string {
	return fmt.Sprintf("%s (%s) is blacklisted", e.Role, e.Address.Hex())
}

This could provide more context and make the error handling more consistent across the codebase.