forked from eth-protocol-fellows/cohort-four
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Showing
12 changed files
with
180 additions
and
131 deletions.
There are no files selected for viewing
Large diffs are not rendered by default.
Oops, something went wrong.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,83 +1,74 @@ | ||
| ## EIP-x: Empowering Stateless Light Clients: Enhancing Data Access and Efficiency through Stateless Verification with State Provider and Cache Mechanism | ||
|
|
||
| ## Motivation: | ||
| ##EIP-x | ||
| Stateless LC That Consumes ZKP | ||
|
|
||
| Light clients struggle to efficiently access and validate data on the mainnet due to challenges in obtaining concise witness proofs. Verkle trees help lightweight clients transition between blocks but can't prove new state accuracy. Stateless clients lack state data for actions beyond transitioning. The Portal Network doesn't fully address these issues. Our solution adds a stateless verifier LC (Lightweight Client) on the Portal Network with a cache to store important state fragments. We distribute the latest state using Zero-Knowledge proofs (ZKP) and propose a chase mechanism for efficient data retrieval. This addresses challenges in accessing state data for tasks like gas estimation and enhances lightweight client efficiency. | ||
|
|
||
| ## Project Description: | ||
| ## Motivation | ||
| In the dynamic landscape of blockchain technology, addressing the limitations of traditional light clients is paramount for the widespread adoption and efficient functioning of the Ethereum network. Conventionally, light clients have burdened full nodes by incrementally requesting block state, posing challenges to network scalability. The integration of Verkle trees has provided a significant step forward, facilitating smoother transitions for lightweight clients between blocks. However, a lingering concern lies in the assurance of accurate state root confirmation, highlighting the need for further advancements. The inability of light clients to handle zero-knowledge proofs compounds the complexity. Moreover, portal nodes, a crucial bridge in this ecosystem, face the challenge of effectively prioritizing essential information for streamlined and swift stateless light client operations. Overcoming these obstacles is central to empowering light clients and optimizing the Ethereum network for a seamless and inclusive decentralized future. | ||
|
|
||
| Light clients struggle to efficiently access and validate data. Currently, light clients, which rely on simplified verification, face challenges in accessing and validating the mainnet state due to the absence of concise witness proofs. These clients need to confirm blocks without having access to the full state. | ||
| # Project Description | ||
| Project Description: | ||
|
|
||
| Verkle trees allow very lightweight clients to consume proofs from other networks to transition from the last block to the new block. However, they cannot prove the accuracy of the new state root. If a stateless client discards all its stored information, it can still confirm the accuracy of new state roots. By doing so, a stateless client can still send transactions but cannot calculate gas estimates, perform ETH calls, or read Ethereum's state since it no longer maintains any state data. The client is limited to actions that involve transitioning from one state to the next state root, without any specific state-related functions. | ||
| Our endeavor,EIP-x, embodies a thoughtful exploration of Helios light clients' capabilities to transform the way we access and validate blockchain data. At its core, the State Provider entity operates as a conduit to access the most recent block state of a block in a manner that fosters trust without reliance on intermediaries. This process entails the extraction of a cryptographic witness, which in turn serves as the foundation for the creation of zero-knowledge proofs (ZKPs). These ZKPs, integral to our approach, are subsequently disseminated to all participating lightweight client (LC) nodes across the network. | ||
|
|
||
| This is where the Portal Network comes into play. While it allows the reading of random state data, it doesn't fully mitigate the core issue. The underlying challenge persists—efficiently accessing state data remains crucial for various tasks, including gas estimation. Additionally, Verkle trees, despite their benefits, don't inherently solve problems like federated access to the state. | ||
| To bridge this gap, an innovative solution comes in the form of the Portal Network introducing a stateless verifier LC (Lightweight Client) with a partial state caching mechanism to enhance the efficiency of accessing specific segments of the state. It achieves this by storing frequently accessed or important state fragments in a cache, enabling clients to retrieve them more quickly than repeatedly traversing Verkle trees. | ||
| In the context of the Portal Network, Our approach centers on empowering Trin clients to efficiently incorporate ZKPs into their operations, coupled with the implementation of a dedicated cache mechanism. This cache mechanism offers the flexibility to select portions of proofs that align with individual requirements, thereby optimizing the overall performance. | ||
|
|
||
| To bring this vision to fruition, we propose the incorporation of two pivotal elements: a state provider that leverages the capabilities of Helios light clients, delivering ZK proofs of the most recent state to all LC nodes, and a cache mechanism catering specifically to stateless light clients on the Portal Network, thereby optimizing their operations. Furthermore, this initiative strives to empower Verkle trees, enabling them to access and validate the mainnet state despite the scarcity of succinct witness proofs. | ||
| The collaboration between the State Provider and stateless LC consuming zkp within the Portal Network establishes a dynamic partnership, fostering robust data validation. In cases where cache-related inconsistencies or failures may surface, participants can confidently resort to the ZK proofs of the latest state. These cryptographic proofs serve as a dependable means to verify the integrity of cached data fragments, reinforcing trust and reliability within the system. The State Provider project endeavors to significantly enhance the efficiency, security, and accessibility of blockchain data for stateless light clients, contributing to the ongoing evolution of decentralized technologies. | ||
|
|
||
| The synergy between these two components is noteworthy. Should inconsistencies or failures arise within the cache, participants can resort to the ZK proofs of the latest state, effectively validating the integrity of cached fragments. | ||
|
|
||
|
|
||
| ## Our proposal of partial state caching complements our goals in these ways: | ||
|
|
||
| - Improved Retrieval for Stateless Clients: | ||
| Stateless clients lack the ability to store the full state and rely on external means to access data. By using partial state caching, we offer an efficient method for these clients to access vital state fragments, reducing their reliance on complex Verkle tree processes. | ||
| ## Roadmap | ||
| POC of the eniter EIP-X | ||
| testing | ||
| evovling the implement5ation to improve the capabilites | ||
|
|
||
| - Less Data Transfer and Computation: | ||
| Stateless clients struggle with data transfer and computation. Partial state caching lets them access pre-cached data, lessening the need for extensive data transfers and computational work, in line with the efficiency objectives of stateless clients. | ||
|
|
||
| - Decentralized, Trustless Verification: | ||
| Stateless clients aim for trustless Ethereum network interaction. Through partial state caching, clients can independently verify cached state fragment validity using ZK proofs, preserving trustlessness by eliminating dependence on a central source. | ||
| ## Goal of the project | ||
|
|
||
| - Swift Data Retrieval: | ||
| Cached state fragments are readily available, bypassing the need to rebuild or navigate the Verkle tree for each request. This rapid access to cached data results in quicker retrieval times compared to direct tree fetching, especially for frequently needed data. | ||
| ##Important Use-case1: | ||
| Being stateless Node for Flashbot | ||
| Problem: | ||
| Flashbots' 0 gas price transactions, paying miners via smart contracts, risk a Denial-of-Service (DOS) vector. Miners must simulate transactions to assess profitability, making them vulnerable to spam attacks without cost. This differs from regular Ethereum transactions with inherent fees and node-based mempool filtering. | ||
|
|
||
| - Reduced Network Latency: | ||
| Cached fragments can be fetched locally, reducing the reliance on multiple network interactions for Verkle tree traversal. This minimizes network delay and enhances responsiveness. | ||
| Potential Solution with EIP-X: Stateless clients, which can consume zkps, have the potential to mitigate the problem above | ||
|
|
||
| - Efficient Resource Use: | ||
| Cached fragments reduce computational load during Verkle tree traversals, particularly for complex state structures. This optimizes computing resource utilization. | ||
| 1. Efficient Profitability Validation: They enable miners to determine transaction profitability using zkps, reducing resource consumption.Since zkps can verify transaction validity without executing them, miners can filter out spammy transactions more effectively, as they can identify them without the need for costly simulation. | ||
|
|
||
| - Consistency and Validity: | ||
| The partial state caching mechanism ensures consensus-validated data, preventing caching of compromised or invalid data. This boosts integrity and data retrieval reliability. | ||
| 2. Protection from Spam:Stateless nodes can defend against spam by verifying transaction validity without execution, enhancing spam filtering. | ||
|
|
||
| - Optimized State Access: | ||
| Partial state caching can prioritize frequently accessed state fragments, catering to stateless clients' needs for specific data subsets. This speeds up necessary information access, elevating overall efficiency. | ||
| 3. Privacy and Permissionlessness: They maintain privacy by validating transactions without revealing sensitive data and achieve permissionlessness in Flashbots transactions. | ||
|
|
||
| - Improved Security and Reliability: | ||
| Stateless clients face security risks with third-party state data. Incorporating cryptographic proofs and cached state fragments empowers clients to autonomously verify data integrity, boosting security and reliability in Ethereum network interactions. | ||
| ##Important Use-case 2: | ||
| Being stateless Relayer for Flashbot | ||
|
|
||
| ## Roadmap | ||
| Problem: | ||
| In the Flashbot ecosystem, the absence of costs for failed bids allows for potential network spam via invalid bundles, leading to denial of service (DoS) threats. Malicious actors can send miners invalid bundles, causing wasted computational resources. Relayers are crucial for DoS mitigation. Flashbots' mev-relay addresses this, but trust-based concerns exist. | ||
|
|
||
| Step 1: State provider entity including trustless RPC query for latest state (to Helios light client from [Axiom](https://github.com/ltfschoen/axiom-quickstart#docker-setup)), generation of ZK proof of the last state using Axiom, and propagation of the ZK proof to the Portal Network clients like [Trin](https://github.com/ethereum/trin). | ||
|
|
||
| https://github.com/sogolmalek/EIP-x/issues/6#issue-1869376007 | ||
| Solution: | ||
| stateless light client with ZKPs to efficiently verify bundle validity and payment status, preventing invalid bundles from reaching miners and enhancing network security. Our EIP-x can solve Flashbot in three ways: | ||
|
|
||
| Step 2: A stateless verifier LC (Lightweight Client) with a partial state caching mechanism to enhance the efficiency of accessing specific segments of the state. It achieves this by storing frequently accessed or important state fragments in a cache, enabling clients to retrieve them more quickly than repeatedly traversing Verkle trees. By relying on ZK proofs to verify the state, users and applications can interact with the blockchain securely and efficiently. This approach empowers more participants to engage with the network without requiring extensive computational resources and storage, promoting network inclusivity. | ||
|
|
||
| https://github.com/sogolmalek/EIP-x/issues/5#issuecomment-1694222160 | ||
| 1- according to the flow, relayer consumes the Ethereum state(what we provide is a fir here, zkp of last block state) | ||
| 2- we can provide a zk of payment proof by bundlers if they have payed to the miner : 1- it will reduce resource usage to compute if bundler has paid | ||
| 3-preventing Relayers to have full access to the contents of all bundles and could easily reorder or steal or censor them! | ||
|
|
||
|
|
||
|
|
||
| ## Collaborators | ||
| Sogol Malek, | ||
| Luke Schoen, | ||
| Elvis Sabanovic | ||
|
|
||
| Luke Schoen, | ||
| Samuel Dare, | ||
| ### Fellows | ||
| Sogol Malek (EPF) | ||
| Luke Schoen (EPF) | ||
|
|
||
| ### Mentors | ||
|
|
||
| Guillaume Ballet, | ||
| Matt Garnett, | ||
| Yoav Weiss, | ||
| Sina Mahmoodi | ||
| Guilluame Ballet(Verkle) | ||
| Sina Mahmoodi(Geth) | ||
| Daniel Marzec (Flashbot) | ||
|
|
||
| ## Resources | ||
|
|
||
| https://github.com/sogolmalek/EIP-x | ||
| https://docs.google.com/presentation/d/1ExNviOulPM8bsnMS-EuvFbH8hLpWNltiqaxjm2jSZd0/edit?usp=sharing | ||
| https://ethresear.ch/t/making-flashbot-relay-stateless-with-eip-x/16788 | ||
| https://docs.google.com/document/d/1M1N1jVZTmrD3kfznQhfOVttXVdsM6sS3G_CDz2NFbH8/edit?usp=drive_link | ||
|
|
||
| https://github.com/ltfschoen/axiom-quickstart#docker-setup | ||
|
|
||
| https://docs.google.com/presentation/d/1heCbSH1Mj1oG0aPamk0yQ5Mo9sLJfAmt71lzBe-0-C4/edit?usp=drive_link |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.