Skip to content

Add EIP: Scaling Ethereum with a Perceptron Tree ZKP #9497

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 16 commits into
base: master
Choose a base branch
from
143 changes: 143 additions & 0 deletions EIPS/eip-7911.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,143 @@
---
eip: 7911
title: Scaling Ethereum with a Perceptron Tree ZKP
description: Improving Ethereum scalability and privacy using Perceptron Trees to compress transaction data via ZKP.
author: Ryo Ha (@sopia19910) <[email protected]>, Khajiev Nizomjon (@khajievN) <[email protected]>
discussions-to: https://ethereum-magicians.org/t/improving-blockchain-scalability-using-a-perceptron-tree-based-zero-knowledge-proof-model/23196
status: Draft
type: Standards Track
category: Core
created: 2025-03-19
---

## Abstract

This project proposes a method to enhance scalability and privacy protection in the Ethereum network using a Perceptron Tree-based Zero-Knowledge Proof (ZKP) model. The Perceptron Tree, a hybrid model combining the strengths of decision trees and perceptron neural networks, provides a compressed representation for transaction relationships, facilitating efficient verification. It addresses specific drawbacks of existing zk-SNARK and zk-STARK methods, consolidating multiple transactions into a single proof to reduce gas fees and decrease on-chain verification load.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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!


## Motivation

The significant increase in blockchain transactions has resulted in scalability limitations and privacy issues. Existing ZKP methods effectively validate individual transactions but fall short in analyzing inter-transaction relationships while maintaining privacy.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

again refer to previous comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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!


ZK-Rollups bundle multiple transactions off-chain into a single proof submitted to the Ethereum mainnet, improving throughput and reducing costs. However, current batching approaches verify transactions individually without leveraging inter-transaction patterns or relationships.

Existing privacy solutions generate separate ZK proofs for each transaction, limiting ZKP's full potential. The proposed Perceptron Tree model overcomes these limitations by measuring the similarity among multiple transactions and compressing them into a unified proof, thus broadening ZKP applications.

## Specification

### 1. Tree Construction

The system inputs a transaction dataset T = {x₁, x₂, ..., xₙ} to construct a recursive tree.

- Each node classifies transaction data using a perceptron with a linear function:

```
f(x) = step(Wₐ·a + Wᵦ·b + θ)
```

where the step function is defined as:

```
step(z) = {
1, if z ≥ 0
0, if z < 0
}
```

![Perceptron Tree ZKP Process](../assets/eip-7911/20250319_203521.png)

- Tree construction recursively partitions nodes based on conditions like homogeneity (isPure) or maximum depth (maxDepth).

![Perceptron Tree ZKP Process](../assets/eip-7911/20250319_203546.png)

### 2. Relationship Similarity Calculation

#### Path Similarity

Measures similarity by the ratio of shared paths between two transactions within the tree:

```
sim_path(xᵢ, xⱼ) = d/D
```

Where:

- d = length of shared path
- D = maximum depth of the tree

![Path Similarity Example](../assets/eip-7911/20250319_203429.png)

Example: If transactions x₁ and x₂ share only the root node (d=1) in a tree of depth 3, their similarity would be 1/3 ≈ 0.33.

#### Vector Space Similarity

Uses cosine similarity calculated from the feature vectors of each transaction:

```
sim_cos(xᵢ, xⱼ) = (xᵢ·xⱼ)/(‖xᵢ‖‖xⱼ‖)
```

![Vector Similarity Example](../assets/eip-7911/20250319_203500.png)

Example: For vectors x₁ = [0.7, 0.8] and x₂ = [0.9, 0.4], the similarity is 0.89.

### 3. ZKP Proof Generation

The process follows five key steps:


1) **Construct Perceptron Tree**: Build a tree based on transaction set T and train perceptrons at each node.

2) **Calculate Node Commitments**: Compute a commitment value Cₙ for each node n using weights Wₙ, bias bₙ, and hashes of left/right child nodes:

```
Cₙ = H(Wₙ, bₙ, Cₗₑₜₜ, Cᵣᵢₑₕₜ)
```

3) **Generate Path Proof**: For a specific transaction xᵢ, demonstrate the classification path within the tree.

4) **Prove Similarity Threshold**: Prove that the similarity between two transactions xᵢ and xⱼ exceeds a predefined threshold θ.

5) **Construct Final ZKP Proof**: The final Zero-Knowledge Proof Π includes:

```
Π = {Cᵣₒₒₜ, path(xᵢ), sim(xᵢ, xⱼ)}
```

Where Cᵣₒₒₜ is the root commitment, path(xᵢ) is the path proof of xᵢ, and sim(xᵢ, xⱼ) is the similarity proof between transactions.

![ZKP Generation Process](../assets/eip-7911/20250319_203626.png)

### 4. On-chain Verification

Smart contracts verify the submitted proof (Π) by checking:

- The Cᵣₒₒₜ commitment matches the pre-registered tree root hash

- The transaction xᵢ is correctly classified along the provided path(xᵢ)

- The similarity between two transactions meets the predefined threshold θ

## Rationale

The Perceptron Tree-based ZKP model extends the capabilities of existing zero-knowledge proof techniques by incorporating transaction relationships into the proof structure. Traditional zk-SNARK and zk-STARK methods validate individual transactions but do not leverage inter-transaction similarity, which can lead to inefficiencies.

By structuring transactions using a Perceptron Tree, this model enables compression of multiple transactions into a single proof,
reducing gas fees and improving on-chain verification efficiency. The use of a perceptron-based decision structure
ensures adaptability to various transaction patterns, making it a scalable solution for Ethereum.

This proposal operates at the smart contract level, requiring no modifications to the existing Ethereum protocol or consensus algorithm.
It can be implemented alongside existing transaction verification methods, allowing optional adoption without network upgrades.

## Security Considerations

- **Privacy Protection**: Verifies transaction validity without revealing specific transaction details.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lemme know when you do


- **Tamper Resistance**: Uses commitment values based on tree structures and weights to detect data tampering.

- **Replay Attack Prevention**: Includes unique transaction IDs in proofs to avoid replay attacks.

- **Lightweight Verification**: Ensures efficient, simple proof verification operations within smart contracts, minimizing gas fees.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

not a security consideration, consider moving into specification section

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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!


## Copyright

Copyright and related rights waived via [CC0](../LICENSE.md).
Binary file added assets/eip-7911/20250319_203429.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Binary file added assets/eip-7911/20250319_203500.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Binary file added assets/eip-7911/20250319_203521.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Binary file added assets/eip-7911/20250319_203546.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Binary file added assets/eip-7911/20250319_203626.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.