### Final Development Update

> Purpose: Summarizing your activity during the program, reflect on your project and participation.

- Team: EIP-X
- Report by: Luke Schoen

#### Abstract

The purpose of EIP-x in its stage 1 was to improve Ethereum light clients like Helios as a first stage, and then in stage 2 to improve Portal Network implementations like Trin by fetching the latest block header, generating a ZK proof of it, and then allowing peer nodes to exchange and verify the ZK proofs.

The benefit is that this avoids light clients having to burden Ethereum full and archive nodes wishing to download the intermediate Merkle trie nodes to verify account and storage data when that could be otherwise be verified from the ZK proofs that light clients may fetch from other light clients, and that Portal Network nodes could fetch from other Portal Network nodes.

- [Project document link](https://github.com/eth-protocol-fellows/cohort-four/blob/master/projects/EIP-x-efficient-stateless-execution.md)
- [Previous weekly development notes link](https://hackmd.io/k2xNzibsS8GSgUiGz5gwCQ?view)

##### Previous Work

The following tasks were performed by the team during the initial couple of months of the EPF.

- [X] Investigated using Helios light client to obtain latest block headers from which to generate the ZK proofs
- [X] Investigated using Axiom to generate and verify the ZK proofs of the latest block headers
- [X] Changed plans to use zkEVM (from [Privacy & Scaling Solutions](https://github.com/privacy-scaling-explorations)) instead of Axiom for generation and verification of ZK proofs
- [X] Investigated using Trin clients (implementation of the Portal Network), which provides a distributed network that mitigates burdening full and archive nodes with too many requests and use a modified version of Helios
- [X] Established that the ZK proof would be just a base64 format string with a size of approx. 300kB

##### Current Status

> This section covers the state of the project, an overview of roadmap, finished/unfinished tasks, changes of plans, current usability, etc

The following were established as outstanding tasks at a team meeting on 4 Nov 2023:

- [ ] Created an example Trin script offer.rs to offer a string between Trin nodes and check that it was sent and stored in the recipient's DB
- [ ] Unable to detect Trin nodes run from the command line with `find_node` method due to network timeout issues (cause unknown), only possible using Trin nodes generated using peertest
- [ ] Create Trin test cases using peertest to create each Trin node and create PR into https://github.com/sogolmalek/trin and then into https://github.com/ethereum/trin
- [ ] Create a new message type (if necessary) for transferring ZK proofs between Trin nodes, and for verifying the ZK proof received from other Trin nodes
- [ ] Note: It should store the associated finalised block number
- [ ] Note: Refer to Sogol's https://github.com/sogolmalek/EIP-x/tree/main/my_discv5_app and Luke's examples in the example/ folder at https://github.com/ltfschoen/trin/pull/2
- [ ] Create Trin tests that:
- [ ] Obtains latest block header using `get_block_by_hash` from the Portal Network's History Network
- [ ] Stores the latest block header in the Portal Network's State Network in cache, since we want the Helios light client to remain stateless, and since we want to use the State Network to verify the correctness of ZK proofs across Trin nodes. See https://ethereum.github.io/trin/developers/architecture/workspaces.html#trin-state
- [ ] Create Trin test fixture that is a base64 format string with a size of approx. 300kB to represent a ZK proof from the latest block header
- [ ] Note: Actual implementation to use ZK generated by https://github.com/privacy-scaling-explorations/zkevm-circuits/tree/main/mpt-witness-generator
- [ ] Create Trin tests that:
- [ ] Store the ZK proof fixture in the DB of a Trin peertest node using the State Network
- [ ] Finds other nearby Trin peertest nodes within a given radius
- [ ] Checks whether those Trin peertest nodes already have the ZK proof associated with a given block number
- [ ] Offers the ZK proof stored in a Trin peertest node only to the other Trin peertest nodes that it found within the given radius and stores it in their State Network DB
- [ ] Checks that the ZK proof that was accepted by other Trin peertest nodes was actually stored in their State Network DB
- [ ] Verifies the ZK proof that is in a State Network DB of a Trin peertest node (generated on that node or received from another node)
- [ ] Allows the Trin peertest node to configure rate limit of how often to interact with other Trin peertest nodes (offering ZK proof, etc)
- [ ] Removes the ZK proof associated with a given finalised block if the block is x blocks older than the latest block to prevent unnecessary DB state bloat, or just only use the latest block

sequenceDiagram
    Trin (Node 1) ->> Helios (Node 1): requests `get_block_by_hash`
    Helios (Node 1)--x Trin (Node 1): returns latest block hash
    Note right of Trin (Node 1) : Generate and store ZK proof <br/>from latest block hash <br/>using Privacy & Scaling Solutions
    Note right of Trin (Node 1) : Find nearby Trin <br/>peertest nodes including <br/>Node 2 using `find_node` of <br/>Discovery v5 peer discovery protocol
    Trin (Node 1)-->> Trin (Node 2) : Check whether already <br/>has ZK proof of <br/> latest block number 
    Trin (Node 1)-->> Trin (Node 2) : Offer latest ZK proof and <br/>if accepted store in their DB
    Trin (Node 2)-x Trin (Node 1): accept ZK proof
    Trin (Node 1)-->> Trin (Node 2) : Store offered ZK proof in their DB and <br/>check if ZK proof is in their local DB
    Trin (Node 2)-x Trin (Node 1): confirm ZK proof is in their DB
    Trin (Node 1)-->> Trin (Node 2) : Verify latest ZK proof <br/>of the latest block number
    Trin (Node 2)-x Trin (Node 1): confirm ZK proof is valid
    Note right of Trin (Node 1) : Allow Trin peertest <br/>Node 1 to be configured <br/>to rate limit interaction with <br/>after Trin  
    Note right of Trin (Node 1) : Remove ZK proof associated <br/>with finalised block headers <br/>if the block is more than x blocks<br/>older than the <br/>latest block to prevent uncessary <br/>DB state bloat

- [ ] Investigate how to ensure that initial block header used to generate the ZK proof was trustful?
- Note: Perhaps initially some randomly choosen Trin nodes each obtain the latest block header and generate the ZK proof and we verify that each of those ZK proofs are the same before further sharing those ZK proofs with other Trin nodes

##### Future Work

> This section covers potential next steps, improvements, use cases

- Finish unfinished work from the [Current Status](https://hackmd.io/xt3aYxTlQPq4LOuBCUs2PA?view#Current-Status) section
- Helios direct integration
- Flashbots integration
- zkEVM learn and apply
- [ ] Trin macOS setup instructions PR https://github.com/ethereum/trin/pull/1018
- Review
- https://github.com/keep-starknet-strange/beerus
- https://github.com/ZpokenWeb3/zk-light-client-implementation
- Presentation at [DCxPrague](https://dcxprague.org/) between 15-21 Nov 2023

##### Conclusions

###### Self-evaluation

> This section covers general feedback about your project and activity within EPF

- The most effective approach for learning Helios and Trin codebases was to:
- Read the documentation
- Review the codebases in particulate the unit tests
- Write example scripts first based on unit tests
- Write my own unit tests
- Write implementation to pass the unit tests
- Write documentation

###### Feedback about EPF

> This section covers takeaways from the program, both the good and bad

- Weekly standups were great and helped me decide to join another team instead of working solo.
- Joining a team that shared their ideas each week and were able to obtain more human resources, obtain feedback from mentors, and write scripts helped me learn better and provided guidance, whilst allowing us to progress on more complex tasks that were necessary but beyond our own skillset
- Weekly meetings in addition to standup and office hours were important help reflect upon the current scope and progress and whether it was necessary to pivot and change scope (e.g. from Axiom to zkEVM).
- After the EPF it will be important spend time discovering what other EPF teams did in more detail.
- Weekly office hours presentations were great and it will be important to listen to them again after the EPF.

#### Glossary

- [Helios light client](https://github.com/a16z/helios)
- [Trin client Rust implementation from Portal Network](https://github.com/ethereum/trin)
- [Privacy & Scaling Explorations ZK circuits](https://github.com/privacy-scaling-explorations/zkevm-circuits)
- [Discovery v5 peer discovery protocol](https://github.com/njgheorghita/discv5)