feat: permissioned evm

[tac0turtle]

Description

This pr adds a permissioned system that is optional. Users may want to deploy their chain not as a general chain, this allows it.

[claude]

Claude finished @tac0turtle's task —— View job

---

Code Review: Permissioned EVM Feature

I've thoroughly analyzed this PR that adds an optional permissioned contract deployment system to ev-reth. Here's my comprehensive review:

Review Checklist:

• Understand the core implementation and architecture
• Analyze code quality and best practices
• Check for potential bugs or issues
• Evaluate performance considerations
• Review security concerns
• Assess test coverage
• Provide constructive feedback

✅ Overall Assessment: LGTM with Minor Issues

This is a well-implemented feature that adds valuable permissioning capabilities while maintaining clean code organization and comprehensive testing.

Positive Highlights

1. Excellent Architecture & Design

• Clean separation of concerns: Deploy allowlist logic is properly isolated in crates/ev-revm/src/deploy.rs
• Consistent integration pattern: Follows the same pattern as existing features (base fee redirect, mint precompile)
• Optional by design: Feature is truly optional - when disabled, behavior matches standard Ethereum
• Configuration-driven: Properly integrated with chainspec configuration

2. Robust Implementation

• Binary search optimization: Good performance choice using sorted allowlist with O(log n) lookups in deploy.rs:45
• Proper activation height handling: Consistent with other features, allows safe network upgrades
• Thread-safe design: Uses Arc<[Address]> for efficient sharing across threads

3. Comprehensive Testing

• Unit tests: Good coverage in handler.rs:287-305 and config.rs:429-485
• Integration tests: Excellent end-to-end test in e2e_tests.rs:1063-1207
• Edge case coverage: Tests duplicate addresses, zero addresses, size limits, activation heights

4. Security Considerations

• Proper validation: Rejects zero addresses, duplicates, and oversized allowlists
• Activation height safety: Allows coordinated rollouts on existing networks
• Non-interference: Only affects top-level CREATE transactions, preserves contract-to-contract calls

Issues to Address

🔴 Critical: Debug Assert Issue

Location: crates/ev-revm/src/deploy.rs:16

The debug_assert!(!allowlist.is_empty()) is problematic because:

• Debug assertions are stripped in release builds
• Would allow creating empty allowlists that deny all deployments in production
• Contradicts comment on line 15 saying "empty allowlist disables gating"

Recommendation:

pub fn new(allowlist: Vec<Address>, activation_height: u64) -> Option<Self> {
    if allowlist.is_empty() {
        return None; // Explicitly disable when empty
    }
    // ... rest of implementation
}

🟡 Medium: Missing Test Coverage

Location: crates/ev-revm/src/handler.rs:289

Missing test for unordered allowlist input to verify sorting + binary search work correctly.

Recommendation: Add test case:

#[test] 
fn deploy_allowlist_works_with_unordered_input() {
    let unordered = vec![
        address!("0x...bb"), // Should be second
        address!("0x...aa"), // Should be first  
    ];
    let settings = DeployAllowlistSettings::new(unordered, 0);
    assert!(settings.is_allowed(address!("0x...aa")));
    assert!(settings.is_allowed(address!("0x...bb")));
}

Performance Analysis ✅

Allowlist Validation: Good use of HashSet for O(n) duplicate detection instead of O(n²) nested loops (config.rs:171-183)

Lookup Performance: Optimal O(log n) binary search vs O(n) linear scan suggested by reviewers

Memory Efficiency: Smart use of Arc<[Address]> for zero-copy sharing

Security Analysis ✅

Threat Model:

• ✅ Prevents unauthorized contract deployment by non-allowlisted EOAs
• ✅ Still allows contract-to-contract CREATE/CREATE2 (by design)
• ✅ Proper input validation prevents common attack vectors

Edge Cases Handled:

• ✅ Zero address rejection
• ✅ Duplicate address detection
• ✅ Size limits (1024 max addresses)
• ✅ Activation height coordination

Code Quality ✅

Documentation: Comprehensive docs in docs/guide/permissioned-evm.md and inline comments

Error Handling: Appropriate error types and validation in config.rs:212-223

Maintainability: Clean module organization and consistent patterns

Minor Suggestions

1. Comment Clarity (deploy.rs:18): The intention comment about "allowlist created from scratch" could be clearer about the sorting requirement

2. Configuration Validation: Consider validating allowlist during config parsing rather than at runtime for faster startup failure

Conclusion

This is a high-quality implementation that adds valuable permissioning capabilities. The main issue is the debug assert that needs to be addressed for production safety. The architecture is sound, testing is comprehensive, and the feature integrates cleanly with the existing codebase.

Recommendation: Approve after fixing the debug assert issue and optionally adding the missing test case.

[gemini-code-assist]

Summary of Changes

Hello @tac0turtle, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request implements an optional permissioned contract deployment system for EVM chains. It allows chain operators to define an allowlist of EOAs that are permitted to deploy new contracts, providing a mechanism for more controlled chain environments. The feature is configurable via the chainspec and integrates seamlessly into the existing EVM execution flow, ensuring that only authorized top-level contract creations are processed while maintaining existing contract-to-contract interaction capabilities.

Highlights

• Permissioned Contract Deployment: Introduced an optional permissioned system allowing chain operators to restrict contract deployment to a specific allowlist of Externally Owned Accounts (EOAs) via chainspec configuration.
• EVM Handler Enforcement: The deploy allowlist is enforced at the EVM handler level, specifically for top-level CREATE transactions. Contract-to-contract CREATE/CREATE2 operations remain unrestricted by design.
• Chainspec Configuration & Validation: The system is configured through new deployAllowlist and deployAllowlistActivationHeight fields in the chainspec. Robust validation checks are implemented to ensure the allowlist adheres to constraints like maximum length, absence of zero addresses, and uniqueness of entries.
• Core EVM Integration: Modified EvEvm and EvHandler structs to incorporate the new DeployAllowlistSettings, ensuring these settings are passed through the EVM execution pipeline and applied during transaction validation.
• Documentation and Testing: Updated documentation in README.md and docs/contracts/admin_proxy.md to guide users on configuring the feature. Comprehensive end-to-end tests have been added to verify that unauthorized deployments are correctly blocked while authorized ones proceed.

🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request introduces an optional permissioned system for contract deployment, which is a great feature for private or consortium chains. The implementation is well-structured, with changes cleanly plumbed through the EVM execution flow, from configuration parsing in the node to enforcement in the EVM handler. The addition of comprehensive unit and end-to-end tests is excellent and ensures the feature works as expected.

I have a couple of suggestions for performance improvements in the allowlist validation and lookup logic. These are not critical but would improve efficiency, especially as the allowlist grows.

[chatton]

Overall looks good, left a few small comments but nothing major, I think the debug_assert! is the main thing that should be updated.