Add EIP: Scaling Ethereum with a Perceptron Tree ZKP

[khajievN]

ATTENTION: ERC-RELATED PULL REQUESTS NOW OCCUR IN ETHEREUM/ERCS

--

When opening a pull request to submit a new EIP, please use the suggested template: https://github.com/ethereum/EIPs/blob/master/eip-template.md

We have a GitHub bot that automatically merges some PRs. It will merge yours immediately if certain criteria are met:

• The PR edits only existing draft PRs.
• The build passes.
• Your GitHub username or email address is listed in the 'author' header of all affected PRs, inside .
• If matching on email address, the email address is the one publicly listed on your GitHub profile.

[eth-bot]

File EIPS/eip-7911.md

Requires 1 more reviewers from @g11tech, @lightclient, @SamWilsn

[bomanaps]

This describes what the verification does at a high level, but has these shortcomings and needs to be improved:

Lacks normative language: EIP specifications should use RFC 2119 keywords (MUST, SHOULD, etc.) in the specification section to clearly indicate what's required versus optional eg "Smart contracts MUST verify the submitted proof (Π) by:"
Missing technical precision: It should specify exactly how to perform each verification step, which could lead to inconsistent implementations.

[g11tech]

making the claim here that SNARK/STARK can't consolidate multiple transactions into single proof but zkVMs are providing 128kb single proof for the entire mainnet block (check ethproofs.org), this claim might need substantiation/clarification of what exactly you mean here

[sopia19910]

Thanks @g11tech for pointing this out. You’re correct that existing zkVM-based solutions (such as zkRollups and zkEVMs) can indeed consolidate multiple transactions into a single proof (as demonstrated by projects providing ~128kb single proof sizes for entire Ethereum mainnet blocks—e.g., ethproofs.org).

To clarify our statement: our claim isn't about the impossibility of SNARK/STARK consolidating multiple transactions into a single proof. Rather, the key differentiation we're making is about what type of information is being proven within these proofs.

Existing zk-SNARK/zk-STARK (zkVM) rollup solutions primarily prove the validity of multiple independent transactions at once, effectively compressing multiple validity checks into a single concise proof. However, these proofs typically don't encapsulate or explicitly represent relationships, patterns, or similarities across transactions.

The proposed Perceptron Tree-based ZKP model differs significantly in this aspect. Our model leverages a hybrid AI structure (decision tree + perceptron) to encode and prove relationship-level information (such as transaction clustering, pattern similarity, or dependency relationships). Thus, it's not simply consolidating individual validity proofs into one; instead, it summarizes the inherent structure and relationship patterns across transactions in a single, compact ZKP, enabling richer analytical verification (e.g., risk assessments, AML compliance checks) without exposing sensitive data.

In other words, while zkVM indeed creates a single proof for the entire block (e.g., ~128kb per mainnet block at ethproofs.org), these proofs don't inherently contain relationship-based or higher-level structural summaries across transactions—they remain focused primarily on correctness of execution and state transitions.

We'll clarify this distinction explicitly in the abstract to avoid confusion. Thanks again for bringing this important nuance to attention!

[g11tech]

again refer to previous comment

[sopia19910]

Thanks again for pointing out this aspect clearly, @g11tech.

Let me clarify further: The motivation statement here doesn't imply that existing zk-SNARK/STARK or zkVM solutions cannot consolidate multiple transactions into a single proof. As you've mentioned previously, solutions like zkRollup or zkEVM indeed effectively aggregate many transactions into one succinct proof, primarily focusing on the validity and correctness of state transitions.

However, the limitation we're highlighting pertains specifically to relationship-based or structural analytics across transactions. Existing ZKP methods (zkVM included) mainly verify individual transactions or the correctness of combined execution outcomes, but they typically don't address the explicit capturing or proving of transactional relationships or patterns, such as:

1. Identifying clusters or groups of transactions based on similarity metrics.

2. Detecting anomalies or structural relationships (e.g., AML, fraud patterns) across transaction sets.

3. Proving relational or contextual characteristics across multiple transactions without exposing sensitive data.

The proposed Perceptron Tree-based ZKP model aims explicitly at addressing these points. It provides a method to encode relationships and patterns across transactions within a single proof, while maintaining zero-knowledge characteristics. This structural relationship encoding is a distinct feature currently not offered by conventional zkRollup or zkEVM-based systems, which primarily validate state correctness without explicitly capturing or demonstrating inter-transactional relationships.

We'll update the motivation section to clearly reflect this specific differentiation to avoid confusion. Thanks again for your valuable feedback!

[g11tech]

privacy is not a security consideration unless it messes up security of the blockchain/current systems

[sopia19910]

@g11tech, thanks for the insightful feedback. Our perceptron tree-based ZKP structure does indeed verify transaction validity without revealing specific details. For example, the proof can show that a transaction follows a valid path (meets all the required conditions) without disclosing the transaction’s actual data. This approach is crucial for privacy protection, as it allows the system to validate transactions while keeping sensitive information confidential. That said, you’re absolutely right that this privacy feature isn’t a “security consideration” in the strict sense. It doesn’t directly mitigate a security threat or vulnerability; rather, it’s a design rationale – a functional aspect of the system that enhances privacy. In other words, this mechanism improves privacy but doesn’t impact or weaken the core security of the blockchain itself. I agree that it belongs in the design/specification sections of the document, not under Security Considerations. I’ll go ahead and move the “Privacy Protection” entry out of the Security Considerations section and into the Design Rationale (or appropriate Specification section) to reflect its true role. Thank you for pointing this out – I appreciate your thorough review and will adjust the documentation accordingly.

[g11tech]

lemme know when you do

[g11tech]

not a security consideration, consider moving into specification section

[sopia19910]

Thanks for the insightful feedback, @g11tech. I agree these points align more closely with specification or design rationale than strictly security considerations. Let me clarify briefly:

1. Replay Attack Prevention:
   The Perceptron Tree-based ZKP model includes unique transaction identifiers embedded directly within proofs, preventing reuse of proofs across different transactions. Any replay attempt would fail verification due to identifier mismatch. While this prevents a security risk (replay attacks), it's indeed part of the specification rather than a direct security vulnerability mitigation.

L2. ightweight Verification:
The structure of this ZKP model enables simplified and efficient on-chain proof verification, significantly reducing computational overhead and gas costs. This is primarily a performance optimization rather than a security enhancement per se.

Given your accurate points, I'll move both Replay Attack Prevention and Lightweight Verification from Security Considerations into the Design Rationale or the specification section, as appropriate.

Thanks again for clarifying this important distinction!