componentization: TxPool component extraction and modular tx pipeline

## Summary

Extract `TxPoolComponent` from the monolithic `node/eth/backend.go` and build the modular transaction pipeline on top of it. This is the recommended starting point for all component work — lowest risk, highest leverage, most downstream value.

**Design documents**: [modular-tx-pipeline/](https://github.com/erigontech/erigon-documents/tree/master/cocoon/pocs-and-proposals/modular-tx-pipeline)

---

## Why start here

The txpool is better positioned for componentization than any other subsystem:
- `Assemble()` factory already exists
- Config is self-contained in `txpoolcfg`
- Both directions of the txpool ↔ execution interface are already mediated by gRPC-compatible interfaces — no circular import, no concrete type coupling
- Already runs standalone (`cmd/txpool/`)

Doing txpool first unlocks, in order:
1. **Type registry** — EIP-8141 becomes a handler registration, not 40-file surgery
2. **Validation independence** — removes `ethBackend.AAValidation()` RPC call, txpool validates itself
3. **EIP-8141 full integration** — FrameHandler + frame pipeline engine
4. **L1-L2 multi-pool** — Combined mode can instantiate a second `TxPoolComponent` per chain
5. **Interop Bridge Phase 3** — `TxInjector` surface exposed cleanly by the component

The Downloader component can proceed in parallel (no txpool dependency).

---

## Phases

### Phase 1 — TxPool Component (~1 week)

New files:
```
node/components/txpool/
├── provider.go — Provider{Pool, Server}, Configure/Initialize/Activate/Deactivate
├── component.go — type alias + constructor
└── events.go — event type definitions
```

`Configure()` takes explicit interfaces:
```go
func (p *Provider) Configure(
cfg txpoolcfg.Config,
chainDB kv.TemporalRoDB,
chainCfg *chain.Config,
ethBackend remoteproto.ETHBACKENDClient, // runtime queries only (fees, head block)
stateChanges StateChangesClient, // state subscription
logger log.Logger,
) error
```

Modified: `node/eth/backend.go` (replace `txpool.Assemble()` call), `cmd/txpool/main.go` (reuse component).

---

### Phase 2 — Validation independence (~3 days)

Move AA validation out of the `ethBackend.AAValidation()` RPC call into a self-contained `txtype/validate/` package. Txpool validates without calling execution.

**Key design principle**: txpool validation and execution validation serve different purposes and are implemented independently:
- Txpool: spam protection, self-contained, tiered classifier (structural checks → bytecode introspection → bounded EVM for ambiguous cases)
- Execution: consensus-exact, full state, definitive

The tiered classifier approach — bytecode pattern matching without EVM execution for first-pass filtering, bounded EVM only for unknown/ambiguous cases — keeps validation cost bounded and removes the execution dependency entirely. Detail in [design.md](https://github.com/erigontech/erigon-documents/blob/master/cocoon/pocs-and-proposals/modular-tx-pipeline/design.md).

---

### Phase 3 — Type registry (~1 week)

Replace 40+ scattered type switches with the `TypeHandler` registry. Each tx type (legacy, blob, setcode, AA, frame) registers a handler. Pipeline stages call through the registry — no type switches in pipeline code.

Migrate one pipeline stage at a time, verifying all tests pass at each step:
1. Parsing → `handler.ParseBody()`
2. Validation → `handler.MempoolValidator.Validate()`
3. Pool operations → `handler.OnAdd()` / `handler.OnRemove()`
4. Promotion → `handler.PromotionCheck()`
5. Block builder → `handler.Executor.ExecuteInBlock()`
6. RPC → `handler.Serializer.RPCFields()`

---

### Phase 4 — Frame pipeline engine, execution side (~1 week)

Refactor existing RIP-7560 execution (`aa/aa_exec.go`) to use a generic frame pipeline internally. No new tx type yet — purely internal refactor of execution. Parallel workstream to Phase 3.

```
execution/protocol/frames/
├── pipeline.go — generic frame execution loop
├── rip7560_adapter.go — converts RIP-7560 tx → frame sequence
└── types.go — Frame, FrameResult, FrameType
```

---

### Phase 5 — EIP-8141 FrameTransaction (~1 week)

Wire type 6 through both sides. Txpool side:
```go
func init() { txtype.Global.Register(&FrameHandler{}) }
```
Plus `FrameHandler` implementation (~300 lines) and the frame pipeline already built in Phase 4.

Execution side: `FrameTransaction` struct, RLP codec, state processor routing, block builder.

Gated by `AllowFrameTx` fork activation flag.

---

### Phase 6 — APPROVE opcode (blocked on spec)

New EVM opcode for VERIFY frame validation. Requires EIP-8141 spec finalization (opcode number not yet assigned) and a hardfork gate.

---

### Phase 7 — Middleware layer

Shutter: refactor existing `decryption_keys_processor.go` into the middleware decorator pattern.
Lucid: new commitment pool + payload propagation layer (separate planning, depends on external spec).

---

### Phase 8 — Execution componentization (separate, larger effort)

Decompose `node/eth/backend.go` (1,700 lines, 59-field struct, 1,400-line constructor). Separate planning document required — ~3–5 week effort. The work in Phases 1–2 above clarifies the execution component boundary before this begins.

---

## Sequencing diagram

```
Phase 1: TxPool Component
│
├── Phase 2: Validation independence (parallel: Downloader Component)
│ │
│ └── Phase 3: Type registry
│ │
│ └── Phase 5: EIP-8141 ─────────────────┐
│ │
└── Phase 4: Frame pipeline engine ─────────────────────┘
│
┌─────────────┘
│
Phase 6: APPROVE opcode (blocked on spec)
Phase 7: Middleware (Shutter, Lucid)
Phase 8: Execution component (separate plan)
```

---

## Out of scope

- Execution componentization — separate issue, separate plan
- Lucid P2P protocol — depends on external spec
- MEV-Boost / builder integration — unaffected
- ERC-7562 staking registry — existing infrastructure, no changes needed

## References

- [modular-tx-pipeline/development-plan.md](https://github.com/erigontech/erigon-documents/blob/master/cocoon/pocs-and-proposals/modular-tx-pipeline/development-plan.md) — full phased plan with file-level detail
- [modular-tx-pipeline/design.md](https://github.com/erigontech/erigon-documents/blob/master/cocoon/pocs-and-proposals/modular-tx-pipeline/design.md) — TypeHandler registry, validation tiering, migration strategy
- [modular-tx-pipeline/eip-8141-integration.md](https://github.com/erigontech/erigon-documents/blob/master/cocoon/pocs-and-proposals/modular-tx-pipeline/eip-8141-integration.md) — EIP-8141 gap analysis and frame pipeline design