New payload with witness ssz

[hudem1]

Follow up of PR #11623 as this was from a forked repo

What types of changes does your code introduce?

• Bugfix (a non-breaking change that fixes an issue)
• New feature (a non-breaking change that adds functionality)
• Breaking change (a change that causes existing functionality not to work as expected)
• Optimization
• Refactoring
• Documentation update
• Build-related changes
• Other: Description

Testing

Requires testing

• Yes
• No

If yes, did you write tests?

• Yes
• No

Notes on testing

Optional. Remove if not applicable.

Documentation

Requires documentation update

• Yes
• No

If yes, link the PR to the docs update or the issue with the details labeled docs. Remove if not applicable.

Requires explanation in Release Notes

• Yes
• No

If yes, fill in the details here. Remove if not applicable.

Remarks

Optional. Remove if not applicable.

[claude]

Claude finished @hudem1's task in 8m 52s —— View job

---

Claude finished reviewing the updated PR

---

PR Review: New payload with witness SSZ (updated)

Tasks

• Load context and rule files
• Read key changed files
• Check if previous findings (H1, H2, M1-M4) were addressed
• Review new architecture (PatriciaTrieWitnessGenerator, updated WitnessGeneratingWorldState)
• Post inline comments for open findings
• Post final summary

---

Architecture changes since previous review

The author's comment explains the key shift: state-node capture was removed from the in-flight path (the deleted WitnessCapturingTrieStore) and replaced with a post-execution trie walk using PatriciaTrieWitnessGenerator (from PR #12029). The new approach walks the pre-state patricia trie after execution, given the set of touched accounts/slots — cleaner than per-trie-node interception and avoids the flat-DB compatibility problem.

The new code is well-structured. WitnessGeneratingWorldState accumulates address/slot/bytecode touches during execution; CollectStateNodes fans those out into trie walks via PatriciaTrieWitnessGenerator; the PatriciaTrieWitnessGenerator itself is a clean BulkSet-mirroring traversal that correctly handles collapse siblings and the order-independence rule. The WitnessGeneratingBlockProcessingEnvFactory pool is idiomatic.

---

Status of previous findings

ID	Finding	Status
H1	DI lambda anti-pattern in BlockProcessingModule.cs	Still open
H2	fallbackTrieStore not disposed	Resolved — WitnessCapturingTrieStore deleted; BeginScope/using pattern properly manages the SnapshotBundle. IReadOnlyTrieStore.Dispose() is technically missing but practically a no-op (see new Low finding below).
M1	LINQ on hot-path (WitnessTrieStoreRecorder)	Resolved — recorder deleted; new code uses plain Dictionary/foreach
M2	Fragile cast (WitnessCapturingWorldStateProxy)ctx.Resolve<IWorldState>()	Still open — code comment added explaining the constraint, but structural fragility unchanged
M3	Fragile is NewPayloadWithWitnessSszHandler check in SszMiddleware	Still open — code comment added, check unchanged
M4	TryArm <remarks> inverts the memory-ordering description	Still open
L1	TruncateUtf8 silent empty-string on all-continuation input	Still present (low risk)
L2	node.Keccak null guard in WitnessCapturingTrieStore	Resolved — file deleted
L3	No timeout before CancelWitnessRequest	Still present, acknowledged with code comment

---

New finding

Low – IReadOnlyTrieStore implements IDisposable but is never disposed

IReadOnlyTrieStore extends ITrieStore : IDisposable. In WitnessCapturingBlockProcessor.ProcessOne (line 94) a trie store is created and passed to WitnessGeneratingWorldState without ever being disposed. The same in WitnessGeneratingBlockProcessingEnvFactory.BuildEntry (line 83). Practical impact is low because the actual snapshot bundle (flat-DB path) is managed by the BeginScope/using in CollectStateNodes, and the patricia store's Dispose is a no-op — but it violates robustness.md dispose discipline. See inline comment for fix options.

---

Verdict: Not mergeable

H1 (DI lambda anti-pattern in BlockProcessingModule.cs:66–77) is unchanged from the previous review and is the primary blocker. M2, M3, and M4 remain open and have not been explicitly acknowledged with rationale in PR-level comments (code comments partially note the constraints for M2/M3 but not M3/M4).

Suggested next steps:

1. Fix H1 — change isWitnessExecution: Func<bool>? to witnessExecutionPredicate: WitnessExecutionPredicate? and derive the Func<bool> in the constructor. That lets the single-liner .AddScoped<IBlockAccessListManager, BlockAccessListManager>() work again.
2. Fix M4 — flip "post-CAS" to "pre-CAS" in the TryArm remarks.
3. Decide on M2/M3 — either fix them or post a PR comment explicitly accepting the fragility and why it is bounded.

[asdacap]

Use a different graph for block processor so that it does not do a closure lookup on all read? #12094

[asdacap]

No special case here please. Abstract the path/characteristic behind ISszEndpointHandler