Flashblocks Support #43
Conversation
- Introduced a new extension trait `FlashblocksSupport` for `RpcWithBlock` to automatically select the appropriate block tag based on the chain ID. - Updated the `EoaExecutorWorker` to utilize the new `with_flashblocks_support` method when fetching the transaction count, enhancing compatibility with specific chains. These changes improve the flexibility and functionality of the RPC provider in handling flashblocks support.
WalkthroughAdds a FlashblocksSupport extension trait to adapt RPC block tags for specific chain IDs and integrates it into the EOA confirmation path for get_transaction_count. Also removes an unused import in the EIP-7702 executor confirm module. No public API removals. Changes
Sequence Diagram(s)sequenceDiagram
autonumber
participant CW as ConfirmWorker (EOA)
participant P as Provider
participant R as RpcWithBlock
participant FB as FlashblocksSupport
participant N as Node
CW->>P: get_transaction_count(address)
P->>R: build RPC call (with block tag)
R->>FB: with_flashblocks_support(chain_id)
alt chain_id ∈ {8453, 84532}
FB-->>R: apply pending()
else other chains
FB-->>R: no-op (keep default)
end
R->>N: eth_getTransactionCount (with selected block tag)
N-->>R: result
R-->>P: count
P-->>CW: count
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Pre-merge checks (3 passed, 1 warning, 1 inconclusive)❌ Failed checks (1 warning, 1 inconclusive)
✅ Passed checks (3 passed)
Tip 👮 Agentic pre-merge checks are now available in preview!Pro plan users can now enable pre-merge checks in their settings to enforce checklists before merging PRs.
Please see the documentation for more information. Example: reviews:
pre_merge_checks:
custom_checks:
- name: "Undocumented Breaking Changes"
mode: "warning"
instructions: |
Pass/fail criteria: All breaking changes to public APIs, CLI flags, environment variables, configuration keys, database schemas, or HTTP/GraphQL endpoints must be documented in the "Breaking Change" section of the PR description and in CHANGELOG.md. Exclude purely internal or private changes (e.g., code not exported from package entry points or explicitly marked as internal).Please share your feedback with us on this Discord post. ✨ Finishing touches
🧪 Generate unit tests
Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (3)
executors/src/lib.rs (2)
21-26: Centralize chain IDs and make behavior easier to extendInline literals make it easy to miss future network additions. Consider a small refactor to centralize supported chain IDs.
Apply this diff:
- fn with_flashblocks_support(self, chain_id: u64) -> Self { - match chain_id { - 8453 | 84532 => self.pending(), // Base Mainnet | Base Sepolia - _ => self, - } - } + fn with_flashblocks_support(self, chain_id: u64) -> Self { + const CHAINS_WITH_FLASHBLOCKS: &[u64] = &[8453, 84532]; // Base Mainnet, Base Sepolia + if CHAINS_WITH_FLASHBLOCKS.contains(&chain_id) { + self.pending() + } else { + self + } + }
10-13: Minor: document semantics more explicitlyAdd a note that this intentionally selects the “pending” tag to count preconfirmed/pool nonces on Base, which can return values ahead of latest/safe. This helps readers understand why confirmation logic may see higher nonces.
executors/src/eoa/worker/confirm.rs (1)
36-41: Using pending nonce on Base aligns with preconfirmations; consider a safety toggle + observabilityThe placement before
.awaitis correct so the provider call uses the pending tag on Base chains. Two optional enhancements:
- Add a config/feature flag to flip this quickly if providers regress (aligns with “execution mode flag” in the issue).
- Emit a trace when pending is used to aid debugging spikes in “fetched lower than cached” warnings caused by pending vs latest differences.
Example (conceptual):
- .get_transaction_count(self.eoa) - .with_flashblocks_support(self.chain.chain_id()) + .get_transaction_count(self.eoa) + .with_flashblocks_support(self.chain.chain_id())Plus (elsewhere): plumb an
enable_preconfirmationsoption and guard the call, and add atracing::trace!indicating the chosen block tag.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
💡 Knowledge Base configuration:
- Linear integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
📒 Files selected for processing (3)
executors/src/eip7702_executor/confirm.rs(0 hunks)executors/src/eoa/worker/confirm.rs(2 hunks)executors/src/lib.rs(1 hunks)
💤 Files with no reviewable changes (1)
- executors/src/eip7702_executor/confirm.rs
🧰 Additional context used
🧬 Code graph analysis (1)
executors/src/lib.rs (2)
core/src/chain.rs (2)
chain_id(31-31)chain_id(74-76)core/src/execution_options/mod.rs (1)
chain_id(179-181)
🔇 Additional comments (3)
executors/src/lib.rs (1)
15-27: Clean extension and correct generics; approach looks solidImplementing a local extension trait over
RpcWithBlockto inject.pending()conditionally is clean and composes well with the builder API. The generic bounds look appropriate (Map: Cloneis needed for.pending()to clone the mapper).executors/src/eoa/worker/confirm.rs (2)
5-18: Importing the extension trait is required for method resolution — good catchBringing
crate::FlashblocksSupportinto scope ensures.with_flashblocks_support(..)is available on the RPC builder.
36-41: Sanity-check other call sites for consistencyFound get_transaction_count calls that do NOT chain .with_flashblocks_support(...):
- eip7702-core/src/delegated_account.rs:93
- eip7702-core/tests/integration_tests.rs:431, 507, 625
Confirm whether omission is intentional; if not, add
.with_flashblocks_support(self.chain.chain_id())to avoid divergent nonce behavior.
Summary by CodeRabbit