-
Notifications
You must be signed in to change notification settings - Fork 5.6k
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
base: master
Are you sure you want to change the base?
Changes from all commits
4c861d2
e7bfa6d
6a61bf1
549790c
d7123bf
4ad26c2
4921567
dc0e75c
a3b028d
0b45729
6910cb5
e91a1f6
4e22d91
dc924ea
1c5c8bc
fde5d09
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
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. | ||
|
||
## 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. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. again refer to previous comment There was a problem hiding this comment. Choose a reason for hiding this commentThe 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:
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 | ||
} | ||
``` | ||
|
||
 | ||
|
||
- Tree construction recursively partitions nodes based on conditions like homogeneity (isPure) or maximum depth (maxDepth). | ||
|
||
 | ||
|
||
### 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 | ||
|
||
 | ||
|
||
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ⱼ‖) | ||
``` | ||
|
||
 | ||
|
||
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. | ||
|
||
 | ||
|
||
### 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. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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 There was a problem hiding this comment. Choose a reason for hiding this commentThe 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. There was a problem hiding this comment. Choose a reason for hiding this commentThe 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. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. not a security consideration, consider moving into specification section There was a problem hiding this comment. Choose a reason for hiding this commentThe 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:
L2. ightweight Verification: 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). |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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!