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 Complete

I've completed my comprehensive review of the permissioned EVM implementation. Here's my detailed feedback:

Todo List:

• Read and understand the core permissioned system implementation
• Review security aspects of the allowlist validation
• Analyze performance considerations beyond Gemini's suggestions
• Check test coverage and edge cases
• Review integration with existing EVM execution flow
• Provide comprehensive feedback

---

Overall Assessment

This is a well-implemented feature that adds optional contract deployment allowlisting to ev-reth. The code is clean, well-tested, and follows good architectural patterns. I agree with Gemini's performance suggestions and have additional observations.

Code Quality & Best Practices ✅

Strengths:

• Clean Architecture: Proper separation of concerns with dedicated modules for deploy allowlist logic
• Type Safety: Good use of Rust's type system with Arc<[Address]> for zero-copy sharing
• Error Handling: Comprehensive validation with meaningful error messages
• Documentation: Clear inline docs and dedicated guide in docs/guide/permissioned-evm.md

Minor Suggestions:

• crates/ev-revm/src/deploy.rs:18: Good that sorting is already implemented (addresses Gemini's suggestion)
• crates/node/src/config.rs:171-183: HashSet validation is already implemented (addresses Gemini's suggestion)

Security Analysis 🔒

Positive Security Aspects:

1. Validation is Comprehensive:

   • Rejects zero address (config.rs:173-177)
   • Prevents duplicates (config.rs:178-183)
   • Enforces size limits (1024 max, config.rs:165-169)

2. Proper Enforcement Point:

   • Validation occurs in validate_against_state_and_deduct_caller (handler.rs:116) before execution
   • Only affects top-level TxKind::Create transactions (handler.rs:75)

3. Activation Height Control:

   • Allows coordinated rollouts via activation_height configuration
   • Graceful defaults (activation at block 0 if unspecified)

Security Considerations:

• ⚠️ Contract-to-Contract CREATE/CREATE2: By design, only top-level deploys are restricted. Existing factory contracts can still be used by non-allowlisted accounts. This is documented but worth emphasizing.
• ⚠️ Static Configuration: Changes require chainspec update and restart - no runtime updates possible.

Performance Analysis 🚀

Gemini already identified the key performance optimizations. Additional notes:

1. Binary Search Implementation: ✅ Already implemented correctly in deploy.rs:42
2. Memory Efficiency: ✅ Uses Arc<[Address]> for shared ownership without copying
3. Lookup Cost: O(log n) is excellent for up to 1024 entries
4. Early Exit: ✅ Proper early return when allowlist not active (handler.rs:71-73)

Additional Performance Notes:

• The u64::MAX fallback for block number conversion (handler.rs:70) is safe but could log a warning
• Validation happens once per transaction, not per operation - good placement

Test Coverage Analysis 🧪

Excellent Coverage:

• ✅ Unit tests: Comprehensive validation tests in config.rs (lines 462-485, 429-443, 446-459)
• ✅ Integration tests: Full E2E test in e2e_tests.rs covering allowed/denied scenarios
• ✅ Edge cases: Zero address rejection, duplicates, size limits all tested
• ✅ Handler tests: Direct EVM handler testing in handler.rs (lines 287-305)

Test Quality:

• Good use of realistic addresses and scenarios
• Proper error assertion patterns
• Tests both positive and negative cases

Potential Issues & Edge Cases 🔍

Minor Issues Found:

1. Block Number Overflow Handling (handler.rs:69-70):

   let block_number = evm.ctx_ref().block().number().try_into().unwrap_or(u64::MAX);

   • Using u64::MAX as fallback could cause unexpected behavior if allowlist has activation height < u64::MAX
   • Consider logging a warning or using a more explicit fallback

2. Error Message Specificity (handler.rs:78):

   • Generic "contract deployment not allowed" message doesn't indicate which address was rejected
   • Consider including the caller address in error message for better debugging

3. Configuration Ordering:

   • No validation that deployAllowlistActivationHeight is reasonable (e.g., not in distant future)

Integration Quality ✅

Excellent Integration:

• Properly flows through the EVM execution pipeline
• Settings correctly passed from config → factory → EVM → handler
• No breaking changes to existing interfaces
• Clean separation from other EV-specific features (base fee redirect, mint admin)

Recommendations

1. Address Gemini's Performance Suggestions: The binary search and HashSet optimizations are already implemented ✅

2. Consider Enhanced Error Messages:

   return Err(<ERROR as FromStringError>::from_string(
       format!("contract deployment not allowed for caller {}", tx.caller())
   ));

3. Add Block Number Validation (optional):

   if block_number == u64::MAX {
       // Log warning about block number overflow
   }

4. Documentation Enhancement: Consider adding examples of factory contract interactions to the security limitations section.

Final Verdict: ✅ APPROVED

This is a high-quality implementation that follows Rust and Ethereum best practices. The security model is sound for its intended use case, performance is well-optimized, and test coverage is comprehensive. The only suggestions are minor enhancements rather than blocking issues.

The permissioned EVM feature successfully provides chain operators with granular control over contract deployment while maintaining compatibility with existing EVM semantics.

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