feat: add custom exex for block pushing

[tac0turtle]

Description

This pr adds a push based streaming service in order to better integrate into atlas allowing blocks to be pushed instead of pulled via rpc

Type of Change

• Bug fix (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
• Performance improvement
• Refactoring

Related Issues

Fixes #(issue)

Checklist

• I have performed a self-review of my code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged and published

Testing

Additional Notes

[coderabbitai]

Important

Review skipped

Draft detected.

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.

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: a14b1196-fd7a-4c9c-a05f-1dcbbd231db2

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

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch marko/ex-ex

---

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.}

Tip

You can customize the high-level summary generated by CodeRabbit.

Configure the reviews.high_level_summary_instructions setting to provide custom instructions for generating the high-level summary.

[claude]

Claude finished @tac0turtle's task —— View job

---

PR Review: Custom ExEx for Block Pushing

I've completed a comprehensive review of this PR that adds a push-based streaming service for block integration with Atlas.

Review Checklist:

• Read repository guidelines
• Review core exex-remote crate implementation
• Analyze gRPC/protobuf integration
• Check error handling and type safety
• Evaluate performance considerations
• Assess security implications
• Review test coverage
• Provide comprehensive feedback

---

🎯 Overall Assessment

This is a well-structured PR that introduces a clean, versioned gRPC streaming API for block execution events. The implementation follows good architectural principles with proper separation of concerns and comprehensive test coverage.

✅ Strengths

Architecture & Design:

• Clean separation between wire types and internal types (crates/exex-remote/src/types.rs:1-264)
• Proper versioning with REMOTE_EXEX_SCHEMA_VERSION_V1 constant
• Well-designed notification enum covering commit/reorg/revert scenarios
• Bounded broadcast channels prevent memory leaks

Error Handling:

• Proper error propagation using thiserror (crates/exex-remote/src/error.rs:1-16)
• Graceful handling of lagged subscribers with ResourceExhausted status (crates/node/src/exex.rs:79-85)
• Schema version validation in codec (crates/exex-remote/src/codec.rs:49-55)

Type Safety:

• Comprehensive validation in constructors (e.g., RemoteBlockRangeV1::new asserts ordered bounds)
• Transaction/receipt count validation in RemoteBlockV1::new (crates/exex-remote/src/types.rs:215-219)
• Proper signer recovery with error handling (crates/node/src/exex.rs:224-227)

Test Coverage:

• Excellent unit test coverage with roundtrip serialization tests
• Integration tests for gRPC server/client communication (crates/node/src/exex.rs:493-552)
• Contract tests ensuring documentation stays in sync (crates/tests/src/test_remote_exex_contract.rs)

🔍 Areas for Improvement

Performance Considerations:

1. Memory Usage: Each RemoteBlockV1 duplicates substantial block data. For high-throughput chains, consider:

   • Block data compression in the protobuf envelope
   • Optional fields for large data (transactions, receipts) with separate streaming
   • Configurable buffer sizes per subscriber type

2. Serialization Overhead: Bincode serialization happens on every notification (crates/exex-remote/src/codec.rs:22-32). Consider:

   • Pre-serializing notifications when possible
   • Using more efficient serialization formats for large payloads

Security Considerations:

1. gRPC Server Security: The server has no authentication or authorization (crates/node/src/exex.rs:111-123). Consider adding:

   • TLS configuration options
   • Authentication mechanisms for production deployments
   • Rate limiting per client

2. Resource Exhaustion: Unbounded message sizes in example (bin/ev-reth/examples/remote_consumer.rs:69-70). Consider:

   • Reasonable default limits in production code
   • Configurable limits based on deployment needs

API Design:

1. Missing Block Range Validation: RemoteBlockRangeV1::new uses const assertion which panics at runtime (crates/exex-remote/src/types.rs:27). Consider:

   pub fn new(start_block: u64, end_block: u64) -> Result<Self, &'static str> {
       if start_block > end_block {
           return Err("start block must be <= end block");
       }
       // ...
   }

2. Fee Payer Recovery: Complex logic in crates/node/src/exex.rs:308-317 could benefit from better error context when sponsor recovery fails.

🐛 Potential Issues

Minor Issues:

1. Transaction Ordering: Gas used calculation assumes sequential processing (crates/node/src/exex.rs:292-295) but doesn't validate this assumption.

2. Log Index Management: Block-global log indexing is handled manually (crates/node/src/exex.rs:218-291). Consider extracting this to a helper struct for better encapsulation.

Documentation:

1. The protobuf schema is minimal but could benefit from field documentation (crates/exex-remote/proto/remote_exex.proto:11-16).

🚀 Recommendations

1. Add configuration for gRPC server security in RemoteExExConfig
2. Consider compression options for large block payloads
3. Add metrics/monitoring for subscriber lag and throughput
4. Document the wire format contract more thoroughly for external integrators
5. Add graceful shutdown handling for the gRPC server

🔐 Security Verdict

✅ Safe to merge - This is defensive infrastructure code with proper error handling and no obvious security vulnerabilities. The streaming service is read-only and doesn't modify chain state.

---

Summary: This is a high-quality implementation that introduces a clean, versioned streaming API for block execution events. While there are opportunities for performance optimization and security hardening in production deployments, the core implementation is solid and follows good engineering practices.