# zk-wave (now joined the EIP-X team)
## Project Proposal
**Initial objective**: improve zkWASM test coverage.
**EIP-X objectives**: is contributing to [EIP-X](https://github.com/sogolmalek/EIP-x)
### Motivation <a id="motivation"></a>
TBC
### Project Description <a id="desc"></a>
### Specification <a id="specification"></a>
TBC
### Roadmap <a id="roadmap"></a>
TBC
```mermaid
gantt
title Projects timeline
dateFormat YYYY-MM-DD
section A
?? :2023-08-14, 23d
?? :2023-09-03, 30d
?? :2023-10-08, 7d
?? :2023-10-08, 7d
?? :2023-10-15, 15d
?? :2023-10-29, 7d
section B
?? :active, 2023-08-14, 23d
```
* Inspiration for use of timeline by @0x5f3759df https://hackmd.io/@Orlogskapten/HyUSMD6j3 https://github.com/wenceslas-sanchez/cohort-four/blob/master/projects/consensus-specs-enhancement.md
### Possible Challenges <a id="challenges"></a>
TBC
### Goals <a id="goals"></a>
**Initial objective**:
* Work on zkOracle open-source and open-protocols.
* Building prototypes of zkOracle using a decentralized p2p networks.
* Improving client architecture to incorporate zkOracle
* Developing and improving low-level EVM mechanics where possible
* Contributing to the public good.
* Improve knowledge in weak areas and share the journey.
**EIP-X objective**:
* Contribute to [EIP-X](https://github.com/sogolmalek/EIP-x)
### Collaborators <a id="collaborators"></a>
#### Fellows <a id="participants"></a>
See https://github.com/sogolmalek/EIP-x#collaborators
#### Mentors <a id="mentors"></a>
* [Mentors](../program-guide/mentors.md)
* zkOracle - [Suning Yao](https://github.com/fewwwww)
* See https://github.com/sogolmalek/EIP-x#mentors
### Resources <a id="resources"></a>
TODO
## Schedule <a id="schedule"></a>
### Common
* Common
* Mentors (see [Mentors](#mentors)
* Prepare "well-informed technical & topical" questions for "development" & "research" mentors for their ideas and to unlock doors and remove barriers (see ../program-guide/mentors.md). Note: Not for teaching
* Ask questions to mentors in Discord #protocol-fellowship and tag relevant mentors
* Post questions to https://github.com/eth-protocol-fellows/cohort-four/issues
* Post research questions and learnings to [Ethereum Research forum](https://ethresear.ch/)
* Post EIP and technical issues to [Ethereum Magicians forum](https://ethereum-magicians.org/)
* Dev updates
* Publish updated development-updates.md with each dev update
* Post dev update in Discord #protocol-fellowship
* Standup call
* Previously working on
* Next working on
* Blockers (if any)
* Office hours (see [EFP Participation Guide](../program-guide/participation-guide.md))
* [ ] 20230701 W0
* Initial reading. See [Links](#links)
* Initial group session
* Learn about chosen problems
* Form teams
* Create write up of a topic they are interested in based on input from mentors
* **TODO**
* EFP readings
* ZK readings
* Questions
* Difference between [zkOracle](https://ethresear.ch/t/defining-zkoracle-for-ethereum/15131) and:
* [Phala Phat contract oracle](https://github.com/Phala-Network/oracle-workshop/blob/master/easy_oracle/lib.rs)
* [zkOracle Wiki](https://zkoracleofficial.gitbook.io/zk-oracle-wiki/)
### W0
* Note: Start days of the week are shown below
* [ ] 20230707 W0 Dev update & Office hours <a id="w0"></a>
* Deep dive into identified areas
* Learn and familiarize with previous work and current solutions.
* Connect with chosen mentors and work towards defining a deliverable project scope of work
* Write and submit this [project proposal](/projects/project-template.md) on the selected problem(s), suggested solutions, and a roadmap for working on the issue throughout the program.
* Report presentation to other participants and select mentors to gather final feedback.
### W1
* [X] 20230715 W1 Dev update & Standup call & Office hours <a id="w1"></a>
* Contacted Suning Yao who confirmed that zkOracle that was mentioned at ethresear.ch has a solution being developed by @HyperOracle
* Reviewed the whole zkWasm-C codebase but did not really understand it since I had not yet read the Hyper Oracle documentation https://docs.hyperoracle.io/. I was not able to run it because I could not find the project/ directory, so raised this issue https://github.com/DelphinusLab/zkWasm-C/issues/5, however more recently this week I discovered the project/ directory in a specific commit, so if time permits I will revisit that repository.
* Read through the Hyper Oracle documentation here https://docs.hyperoracle.io/ and summarised it with hand-written notes to try to understand how it works so when I read more code implementations then hopefully it will make sense.
* Initial thoughts on issues to contribute to add to the roadmap for working on throughout the program is to create examples, which should help reinforce how it works and help the community, and since they are open issues in the zkGraph repository here https://github.com/hyperoracle/zkgraph/issues that were only opened in the past few weeks, and since it is written in TypeScript it should be an achievable goal.
### W2
* [X] 20230722 W2 Standup call & Office hours <a id="w2"></a>
* Sick with flu from 20th July until Standup on 25th July so unfit to progress.
* Participated in Encode ZK Bootcamp day 1-4 on 25-28th July.
### W3
* [ ] 20230731 W3 Dev update & Standup call & Office hours & Demo day <a id="w3"></a>
* Participated in Encode ZK Bootcamp day 5 on 1st Aug.
* Tried to use the Hyper Oracle zkgraph implementation. I created a PR [here](https://github.com/hyperoracle/zkgraph/pull/56) where I added dotenv and updated the readme file to show how to check if the network supported [`debug_getRawReceipts`](https://ethereum.github.io/execution-apis/api-documentation/) method and how to configure it to use Goerli network, however I encountered an error and created an issue in the repository [here](https://github.com/hyperoracle/zkgraph/issues/57)
### W4
* [ ] 20230807 W4 Standup call & Office hours <a id="w4"></a>
* Investigated the issue further and posted comments https://github.com/hyperoracle/zkgraph/issues/57#issuecomment-1661395174
* Obtained support from the maintainer of zkOracle to the issue that I raised, and finally resolved that issue https://github.com/hyperoracle/zkgraph/issues/57.
* TODO - Preparing project proposal
* TODO - **Project Proposal due by end of this week**
### W5
* [ ] 20230815 W5 Dev update & Standup call & Office hours <a id="w5"></a>
* Sick again with chronic cough and temperature from 12-14th Aug so only minimal progress.
* Read through Subgraph documentation to try to understand zkGraph more, since it is based on Subgraph https://thegraph.academy/developers/defining-a-subgraph/ and is a prerequisite for development on Hyper Oracle as mentioned here https://docs.hyperoracle.io/zkgraph/develop
* Published zkGraph summary https://github.com/ltfschoen/zk#zkgraph
* TODO - Execute project roadmap to complete deliverables
### W6
* [ ] 20230822 W6 Standup call & Office hours <a id="w6"></a>
* Sick still
* Meeting to discuss EIP-X project by Sogol with Michael Elliot also in attendance
* Created a PR https://github.com/a16z/helios/pull/262 for Helios project thanks to help from @ncitron from Helios to allow users to run it in a Docker container and improved the accessibility of understanding how to use the examples including configuration and documentation
* Replaced with local PR https://github.com/ltfschoen/helios/pull/1 since Helios decided they didn't want Docker
* Reading Axiom ZK
* Requested to be early partner of Axiom https://docs.axiom.xyz/
### W7
* [ ] 20230831 W7 Dev update & Standup call & Office hours & Demo day <a id="w7"></a>
* Changed to working in the team [EIP-X](https://github.com/sogolmalek/EIP-x)
* Review Draft Project Management of [EIP-x](https://docs.google.com/document/d/1GZswBmKkjKBGoyF216VnatxH_fCmSL6zXrWms8jPpX0)
* Read [Smart Contract Storage for Ethereum](https://www.cryptoauxiliary.com/post/smart-contract-storage-for-ethereum)
* Watched [Axiom Presentation by Dr Yi Sun](https://www.youtube.com/watch?v=5ORq9PSLhQs)
* Meeting with Dr Yi Sun from Axiom on 25 Aug 2023
* Meeting with Sogol and Elvis Sabanovic on 25 Aug 2023
* Established we would use Helios, Axiom, and Portal Network
* Created a PR https://github.com/ltfschoen/axiom-quickstart/pull/1 using Axiom Demo that uses Helios Light Client, and Alchemy on Ethereum Goerli Testnet, and generates ZK proof using Axiom for latest finalised block
* Joined Portal Network on Discord https://discord.gg/j7UsQCbG
* Watched [The Portal Network by Piper Merriam](https://www.youtube.com/watch?v=0stc9jnQLXA)
* Incorporate PRs into Sogol's EIP-X repo
* Git Submodule added. Reference https://stackoverflow.com/questions/36554810/how-to-link-folder-from-a-git-repo-to-another-repo
* TODO - in future investigate using [Zeth](https://github.com/risc0/zeth)
### W8
* [ ] 20230807 W8 Standup call & Office hours <a id="w8"></a>
* Missed Standup call as accidently fell asleep just before the meeting started
* [X] - Created a PR https://github.com/ethereumjs/ultralight/pull/446 into Ultralight (TypeScript impelemtnation) of Portal Network
* Achieved merge of this PR
* [X] - Created a PR https://github.com/ltfschoen/axiom-quickstart/pull/2 that uses Docker Compose with Axiom Demo + Helios + Trin in separate Docker containers for ease of development
* [X] - Review the [Ultralight](https://github.com/ethereumjs/ultralight) (TypeScript implementation) of Portal Network since that may be easier to understand than Trin
* [X] - Read about Kademlia & Discv5 - https://vac.dev/rlog/kademlia-to-discv5/
* [X] - Summarised Ultralight codebase here https://github.com/ltfschoen/zk#ultralight-typescript-implementation-of-portal-network-review
* TODO - Research creating server that interacts between Portal Network and Axiom (that uses fork of Helios)
* TODO - Read each The Aperture with Portal Network updates https://snakecharmers.ethereum.org/author/piper/
* TODO - Read Portal Network Specification https://github.com/ethereum/portal-network-specs
* TODO - Read zkEVM https://github.com/privacy-scaling-explorations/zkevm-specs
* TODO - Review Sogol comments here https://github.com/ethereum/execution-apis/pull/455#discussion_r1307189649
* TODO - Review Sogol comments here in Discord Portal Network #general https://discord.com/channels/890617081744220180/890617082243350560/1145653536093392916
* [X] - Meeting with Sogol and Elvis Sabanovic and Sina Mahmoodi from Geth on 30 Aug 2023
* Investigate initial prototype using LES Light Clients and future incorporating Portal Network
#### Prototype P1 Plan Draft
* EXIST - Axiom submits a request to Helios Light Client to query Ethereum (axiom-quickstart)
* EXIST - Light Clients try to get canonical chain of blocks, which is the tip of the chain that most agree on through consensus
* Light Clients use Light Ethereum Subprotocol (LES) communication protocol https://github.com/ethereum/devp2p/blob/master/caps/les.md and only download block headers as they appear and fetch other parts of the blockchain state on-demand from Full and Archive nodes
* Light Clients follow the chain by asking for state from other peers and executing it as part of their own EVM
* But if a Light Client user wants to do something like interact with a smart contract that has not been in the last 100 blocks, then they will not have the proof or the state for it, so then they additionally need to request the state for that smart contract, which are in contract state as mentioned here https://docs.axiom.xyz/developers/sending-a-query/finding-storage-slots by burdening a Full or Archive node, and that is where the Portal Network prototype comes in to allow them to request it from another Light Client, since Portal Network allows Light Clients to act as both client and server (instead of only client) and interact in a distributed fashion, but Portal Network is still a few years from completion.
* Full and Archive nodes already have the state, they do not need the ZK proofs, since they sync the latest state with their peers.
* Portal Network is solving Light Client problem since at the moment it is expensive for them to acquire the state from Full and Archive nodes because a lot of them have to ask them all the time, which is a heavy burden
* Pre-state Example:
* Given a transaction, where the state change is a change of account x balance by -100, and account y balance by +100. Assuming the pre-state account x balance is 100 ETH, and account y balance is 0 ETH that Full and Archive nodes know from genesis then they may provide that information to Light Clients. Light Clients are able to calculate the post-state of account balances themselves i.e. post-state account x balance is 0 ETH, account y balance is 100 ETH, and Full and Archive nodes do same thing. To be certain they are correct the Merkle Trie with the state is commited when they execute the block themselves in EVM knowing the state, and then in the next block the root block hash has a block header field called state root, and if that matches the state they already have then it means consensus agreed on the new state, but they may only be certain when it is a finalised block
* EXIST - Light Client (Helios or similar) or similar provides block headers of a finalised block to Axiom
* [ ] TODO P1 - Axiom's implementation that generates the ZK proof is https://github.com/ltfschoen/axiom-eth but although the Axiom team runs it as a server, the repository does not appear to include the server implementation
* Add server to https://github.com/ltfschoen/axiom-eth (Rust) so we have a custom Axiom Prover backend server.
* Configure the custom Axiom Prover backend server to allow for the broadcasting of the generated ZK proof of the pre-state for each finalised block header of each block so it may be received by other Light Client (Helios or Portal Network)
* Update https://github.com/axiom-crypto/axiom-quickstart (uses Axiom JS SDK) and configure it to build proofs using a custom Axiom Prover backend server instead of mock proofs. It will use the Axiom JS SDK https://github.com/axiom-crypto/axiom-sdk (JS) for reference, also see examples here https://github.com/axiom-crypto/examples-v2. We need to create a custom Axiom Prover backend server using https://github.com/ltfschoen/axiom-eth (Rust) that may be configured with a `JSON_RPC_URL` environment variable to connect to a JSON RPC provider to get blocks from Goerli or Mainnet and then
* Note: Axiom uses Halo2 proving system https://docs.axiom.xyz/transparency-and-security/kzg-trusted-setup
* Aggregate ZK proofs with the snark-verifier library https://github.com/axiom-crypto/snark-verifier/
* Reference:
* https://docs.axiom.xyz/protocol-design/zk-circuits-for-axiom-queries
* EXIST - Axiom Prover backend server generates ZK proof (axiom-quickstart)
* [ ] TODO P1 - Axiom Prover backend server implementation logic should be modified to:
* Determine the pre-state from the block headers of a specific latest finalised block, which includes only the state and list of account addresses that performed transactions in it necessary to execute that block.
* Use a JSON-RPC method (non-standardised and different for each client) to get the pre-state of that block similar to how Sin did so using JS here:
* https://github.com/ethereum/go-ethereum/issues/23925#issuecomment-1027189309
* https://gist.github.com/s1na/fee1ffad8b087373d1fd76afe7235569
* Filter the pre-state to only include specific Merkle Trie leaves that contain a batch/list of accounts that we may specifically request (such as specific account abstraction smart contracts that may have emitted events)
* Only generate ZK proof for the filtered part of account addresses that performed transactions in the pre-state of a block that was requested
* Note: Do not need to generate ZK proofs for historical state accounts and transactions, only need the state for the current latest finalised block. By pre-state aka "witness" we mean all the accounts we need to execute the transaction in this specific block
* [ ] TODO P1 - Axiom Prover backend server broadcasts the generate ZK proof of the pre-state for each finalised block header of each block so it may be received by other Light Client (Helios or Portal Network), as this is much for efficient, and is the opposite of how it currently works where they are all having to separately request from servers the same information.
* Axiom Prover backend server(s) may already have a Light Client integrated
* [ ] TODO P1 - Embed Axiom's proving and verifying logic into Light Clients
* EXIST - Axiom Prover submits ZK proofs on-chain via p2p to Verifier smart contract on Ethereum (axiom-quickstart)
* [ ] TODO P1 - Axiom should only submit ZK proof on-chain for parts of pre-state of that block to an Axiom Verifier smart contract.
* Note: Axiom serves as the trustless state provider
* [ ] TODO P1 - Light Client (Helios or Portal Network) to be modified to include a verifier function that listens for broadcast events containing the latest finalised block's ZK proof that is in the form of a Wire Protocol Standard to be received. Upon receipt handles the ZK proof using Axiom to get the pre-state verified using the Axiom Verifier, then take parts of the state that come with the ZK proof to execute the block themselves in EVM knowing the state transition is correct. See https://ethresear.ch/t/beacon-chain-light-client-networking/11063
* Trin may already already use the Wire Protocol Standard to receive propogated messages, and have an EVM implement that we may reuse
* EXIST - Axiom Verifier smart contract verifies the ZK proof
* [ ] TODO P1 - Axiom Verifier smart contract https://github.com/axiom-crypto/axiom-v1-contracts/blob/main/contracts/AxiomV1.sol should only have to verify a ZK proof with only the parts of the pre-state that is necessary to execute the block. See https://docs.axiom.xyz/protocol-design/architecture-overview#fulfilling-queries-in-axiomv1query
* EXIST - Light Client (Helios or Portal Network) then has the necessary pre-state and may execute it with their own EVM to put data on-chain on Ethereum
* Note: They will already have the state transition and post-state as Light Clients are able to calculate the post-state themselves from the pre-state and the state transition. Therefore since Light Clients can do the state transition part themselves they do not need Axiom to include the state transition in the ZK proof. Axiom only proves historical data and historical state of accounts at certain block numbers. If we had to generate ZK proofs for state transitions (instead of just the pre-state) we would be doing the same as zkEVM and that is of a higher complexity and unnecessary
* [ ] TODO - create Sequence Diagram https://mermaid.js.org/syntax/examples.html
### W9
* [ ] 20230915 W9 Dev update & Standup call & Office hours <a id="w9"></a>
* Created PR https://github.com/sogolmalek/ethereum-proof/pull/1 after reviewing Sogol's code
* Trying to resolve issue with Yarn <=1 when setting up Lodestar Dockerfile
* Added draft API to provide endpoints for Ethereum proofs and Axiom proofs
* Generated issue with sandbox to try to use Yarn 3 to get Lodestar to work in Docker container https://github.com/yarnpkg/berry/issues/3580#issuecomment-1712698172
### W10
* [ ] 20230922 W10 Standup call & Office hours <a id="w10"></a>
* Generated comment unable to get lodestar with Yarn 1.x and Ubuntu 22.04 to work https://github.com/yarnpkg/berry/issues/3580#issuecomment-1712897568
* Generated comment unable to get Lodestar with Yarn 3.x and Ubuntu 22.04 to work https://github.com/yarnpkg/berry/issues/3580#issuecomment-1717641795
* Requested help in #lodestar-help Discord chat as suggested by dapplion at Protocol Berg https://discord.com/channels/593655374469660673/743858262864167062/1152634856438775919
* Tried to use PNPM to build Lodestar but got type errors running `pnpm run build` https://github.com/ltfschoen/lodestar/pull/2
* Requested help here https://discord.com/channels/593655374469660673/743858262864167062/1152961881514967120
### W11
* [ ] 20230930 W11 Dev update & Standup call & Office hours & Demo day <a id="w11"></a>
* Solved why Lodestar was not working. It was because I was using an old fork of their project :-(
* Got Lodestar working custom https://github.com/clawbird/lodestar/pull/1
* Added API Express.js server with Axiom incorporated to connect to Light Client https://github.com/ltfschoen/axiom-quickstart/pull/2/commits/f85491086a95caad53ef868a389d965bd99a9a13
* Raised issue with Axiom in Discord https://discord.com/channels/1028547935195119617/1053260994249506867/1155422005055733770, since got error when tried verify query results. I had provided a `queryHash` from a previous request `"0x6122480456cf0f66fc39f18fcb1848eeafdd99cc891659c4310c781e5111f03a"` and the logs showed it created this query `/v1/query/get_data_for_query?queryHash=0x6122480456cf0f66fc39f18fcb1848eeafdd99cc891659c4310c781e5111f03a&chainId=5&contractAddress=0x82842F7a41f695320CC255B34F18769D68dD8aDF&mock=false` but it generated error `QueryNotFoundInDbError`. It might be because I have only used `sendQuery` to the verifier, but haven't generated the zk proof by the prover
* Received response here https://discord.com/channels/1028547935195119617/1053260994249506867/1155884781628837988 in Axiom Discord #ask-any-question
* **TODO** Action response, unfortunately I'm now not getting a response when running the server, so created this issue https://github.com/clawbird/axiom-dapp/issues/19
* Created PR https://github.com/ltfschoen/axiom-quickstart/pull/2/commits/9869225ab7efa4b1fae61001c7cebc2c701e1247 to add Axiom-Eth in separate Docker container using Infura
* Summarised most of the Axiom SDK Documentation https://docs.axiom.xyz/ below under heading "Summary of Axiom Docs"
#### **TODO** Summary of Axiom Docs:
* Steps
* [Configure](https://docs.axiom.xyz/developers/installation-and-configuration) Axiom SDK (JavaScript) to use JSON-RPC provider (i.e. local node, Alchemy, or Infura) where instantiating the Axiom class enables interactions with the Axiom SDK API and to interact with on-chain contracts
* Obtain latest block headers. Specify query requests that filter the block headers and generate witness data that we need. Batch multiple query requests to Axiom.
* EIP-X does not need to generate ZK proofs for all historical state accounts and transactions, we only need the state for the current latest finalised block. By pre-state aka "witness" we mean all the accounts we need to execute the transaction in this specific block
* **TODO** Create front-end dApp (similar to https://demo.axiom.xyz, which uses smart contracts deployed using https://github.com/axiom-crypto/axiom-apps) instead of JSON-RPC queries using cURL
* Query request (using cURL or front-end dApp) is encoded and sent as on-chain transaction by user for historic data from Ethereum block headers, accounts, and account storage via Axiom by **building** a query using the Axiom SDK (JavaScript) using the [Axiom Query Format](https://docs.axiom.xyz/developers/sending-a-query/axiom-query-format) and **submitting** it with `sendQuery` on-chain to the `AxiomV1Query` smart contract. Payment of ETH is required for gas fees and proving fees.
* Query allows access up to 8 pieces of historic information from any historic block, by querying information including historic `blockNumber` up to current block, Ethereum `address`, and storage [`slot`](https://docs.axiom.xyz/developers/sending-a-query/finding-storage-slots) in contract storage
* Batch Query into Axiom allows a user to access up to 64 pieces of historic on-chain information simultaneously in a smart contract, where Batch Queries are identified by a serialized form of the `query`, and `keccakQueryResponse` as the Merkle-ized form of the query (may be uniquely determined from the `query` but contains additional on-chain history info)
* Resources:
* [axiom-quickstart](https://github.com/axiom-crypto/axiom-quickstart) shows how to run a test query
* **TODO** Replace use of Infura and Alchemy used by axiom-quickstart with local node (i.e. Helius or similar on http://localhost:8545)
* [AxiomV1Query](https://github.com/axiom-crypto/axiom-v1-contracts/blob/main/contracts/AxiomV1Query.sol) smart contract
* Note: Latest verified on-chain Axiom smart contract code are deployed at addresses listed [here](https://docs.axiom.xyz/transparency-and-security/contract-addresses)
* Note: Demo contract addresses are [here](https://docs.axiom.xyz/axiom-demo-apps#demo-contract-addresses)
* [Axiom SDK (JavaScript)](https://github.com/axiom-crypto/axiom-sdk)
* Custom smart contract
* Query response. Wait for query fulfillment by monitoring its status using the [Axiom Explorer](https://explorer.axiom.xyz/).
1) Off-chain prover of a proving server will index the query, generate the query response result using the [Query Response Format](https://docs.axiom.xyz/developers/sending-a-query/axiom-query-format#query-response-format), and generate a ZK validity proofs (proving its validity) in response to user queries
* Refer to [axiom-eth](https://github.com/axiom-crypto/axiom-eth)
* **TODO** Replace use of Infura and Alchemy used by axiom-eth with local node (i.e. Helius or similar on http://localhost:8545)
2) Off-chain prover verifies that the ZK proof that was generated was correctly put on-chain. It does this by interacting with on-chain smart contracts, and generates the resulting [`keccakQueryResponse`](https://docs.axiom.xyz/developers/sending-a-query/axiom-query-format#keccak-response-format) (the primary way to access results provided for each query along with [`poseidonQueryResponse`](https://docs.axiom.xyz/developers/sending-a-query/axiom-query-format#poseidon-response-format)) is written/committed on-chain to the `AxiomV1Query` smart contract storage in a Merkle-ized format (allowing Axiom to fulfill queries into large amounts of data without paying to store each piece in contract storage), allowing downstream applications to trustlessly access the query response results that were fulfilled on-chain
* **TODO** - Summarise from this section here https://docs.axiom.xyz/developers/query-fulfillment
* Read (using cURL or front-end dApp) and fetch witnesses to prepare an on-chain transaction to read the final value we are proving and verify query response results against smart contract storage trustlessly.
* Submit the fetched witness data on-chain to execute a transaction to prove the final value. ETH is required for gas fees.
* Note: The smart contract storage data has been previously verified using ZK proofs on-chain with the Axiom SDK (JavaScript) and may contain any historical Ethereum on-chain data that is encoded in block headers, states, transactions, and receipts. So we may access any historic Ethereum on-chain data trustlessly just like an archive node.
* View the on-chain transaction once confirmed using [Axiom Explorer](https://explorer.axiom.xyz/).
* Compute (verifiable compute) the ingested data by Axiom then apply verified compute primitives on top, where the validity of each computation is verified in a ZK proof.
* Note: The verified compute primitives may include diverse operations from basic analytics (sum, count, max, min) to cryptography (signature verification, key aggregation) and machine learning (decision trees, linear regression, neural network inference).
* Verification by Axiom accompanying each `sendQuery` result with a ZK proof of validity that is verified on-chain in the Axiom smart contract and the final query response results (with security cryptographically equivalent to that of Ethereum) is then trustlessly available for use in customer user smart contracts. The ZK proof proves:
1) Requested input data was correctly fetched from the chain
2) Compute was correctly applied
* Operate on and use the final query response results that have been ZK-verified on-chain in our user application and custom smart contracts
* References
* https://docs.axiom.xyz/
* https://docs.axiom.xyz/getting-started
* https://docs.axiom.xyz/developers/axiom-for-developers
* https://docs.axiom.xyz/axiom-demo-apps
* https://docs.axiom.xyz/developers/sending-a-query/axiom-query-format
### W12
* [ ] 20230907 W12 Standup call & Office hours <a id="w12"></a>
* Renamed my fork of axiom-quickstart to axiom-dapp where we combine all the Docker containers https://github.com/clawbird/axiom-dapp
* Created Project Schedule for axiom-dapp repo specifically with target dates https://github.com/orgs/clawbird/projects/2/views/1
* Import issues from other repositories, but specifically those shown are from https://github.com/clawbird/axiom-dapp/issues
* Created list of my questions as issues of the axiom-dapp repo, most important is to determine outputs of using axiom-eth repo and benchmark performance somehow
* my questions so far are based on reviewing the code in the following folders:
* axiom-eth/axiom-eth/configs
* axiom-eth/axiom-eth/data
* axiom-eth/axiom-eth/scripts
* might still have questions after going through the main source code directory, or doing so might actually help me answer those questions
* axiom-eth/axiom-eth/src
* Finished reviewing axiom-eth/axiom-eth/src/providers.rs
* Created issues as actions in the EIP-X repository
* Created PR https://github.com/sogolmalek/EIP-x/pull/18 to incorporate clawbird/axiom-dapp git-submodule into EIP-X repo that Sogol maintains and consolidates all our team work
* e.g. swap to use Helios, integrate Axiom into Helius, integrate Axiom in Trin (i.e. limited to verify function inside Trin), testing propagation, dispatch ZKP against mainnet, message wrapping
* Met with Sogol at 8pm CET to talk about priorities, and identified actions like creating the issues in the repo, and focussing on go through axiom-eth
* Enrolled in EthGlobal hackathon as we discussed that could be opportunity to collaborate on using the nice-to-have Trin integration https://ethglobal.com/events/ethonline2023
* Participated in Standup on 2nd Oct 2023
* Finished reading through axiom-eth codebase (haven't summarised it though)
* [ ] IN PROGRESS READING important background reading to understand axiom-eth codebase and definitions used, in addition to reviewing the codebase
* https://github.com/axiom-crypto/halo2-lib/tree/community-edition/halo2-base
* https://trapdoortech.medium.com/zkp-zkevm-a9b046789b4e
* Halo2 guide https://trapdoortech.medium.com/zero-knowledge-proof-a-guide-to-halo2-source-code-9be0cf792f18
* PLONK algorithm intro https://trapdoortech.medium.com/zkp-plonk-algorithm-introduction-834556a32a
* PLONK aggregation circuits guide https://trapdoortech.medium.com/l2-deep-into-plonk-aggregation-circuit-d9928ccd0749
* PLONK algorithm with L2 https://trapdoortech.medium.com/l2-deep-into-plonk-aggregation-circuit-d9928ccd0749
* zk-EVM specs https://github.com/privacy-scaling-explorations/zkevm-specs
* zkEVM & Halo2 custom gates and errors https://trapdoortech.medium.com/zero-knowledge-proof-error-explanation-when-developing-custom-gate-f599ea606a65
* zkEVM State circuits https://trapdoortech.medium.com/zero-knowledge-proof-deep-into-zkevm-source-code-state-circuit-b3175b937fea
* zkEVM EVM circuits https://trapdoortech.medium.com/zero-knowledge-proof-deep-into-zkevm-source-code-evm-circuit-21d0a47f63aa
* zkEVM MPT circuits https://trapdoortech.medium.com/zero-knowledge-proof-deep-into-zkevm-source-code-mpt-circuit-fb2dba6e8ba3
* Meet with Sogol at 2pm CET Sun 8 Oct.
* Established that we have a new contributor with cryptography and ZKP expertise who may help with Axiom, Linfeng (Daniel) Zhou
* Agreed that I should pivot to focus on trying to use Trin to send a proof between Trin clients
### W13
* [ ] 20231015 W13 Dev update & Standup call & Office hours <a id="w13"></a>
* Goal is to try and use Trin to send a proof between Trin clients. Review code that Sogol has written so far
* Goal is to figure out how nodes in portal communicate and where to add axiom verification
* Reading for Trin:
* https://ethereum.github.io/trin
* Read through most of trin-state on the flight from Madeira to Porto and wrote some notes
* Created issue in Helios repo https://github.com/a16z/helios/issues/282 due to error `Error: out of sync: 1697023721 seconds behind` which the maintainer thought was useful and we discovered that we cannot use example scripts until that issue is resolved, but we are able to embed code in the existing repo and run it when we use the CLI to run a node and that worked
* Rebuilt helios folder in EIP-x repo from scratch in my own clawbird/helios for independent sanity checking and it was all good. Created a PR with all the work here https://github.com/clawbird/helios/pull/1
* Participated in a meeting on 11th Oct at 6:30pm CET with Sogol and M?? with live coding to fetch all transactions from current block using ethers in Rust. After the meeting I created a block_all.rs script that did the same and worked here https://github.com/clawbird/helios/pull/1/files#diff-86f469d42ec4998180192f96ec44f0f4c8ff0a949f45598d21f2f5638185f4d0
* Updated fork of Helios so it is up to date with its upstream https://github.com/sogolmalek/helios/pull/1 and incorporated all our custom Helios work from https://github.com/sogolmalek/EIP-x/tree/main/helios
* Created PR https://github.com/sogolmalek/EIP-x/pull/21 to replace Helios local commits with git submodule that has been moved to https://github.com/sogolmalek/helios
### W14
* [ ] 20231022 W14 Standup call & Office hours <a id="w14"></a>
* [ ] TODO - incorporate Sogol's script that sends an example ZKP between nodes into Trin itself
* [ ] TODO - in our fork of Trin, replace their light client package (which is already a fork of Helios that doesn't require running an execution client alongside the light client and is compatible with Portal Network) with our own work and fork of Helios where we target specific accounts
* [ ] TODO - watch last years DevConnect presentations and prepare presentation, as KaydenML mentioned here https://hackmd.io/@v8QYUEqNQI-q90vwuMaJaw/rkobPsYWp
* https://www.youtube.com/watch?v=oF_BRlXMVNY&t=312s&ab_channel=EthereumFoundation
* [ ] TODO - start preparing 10 minute presentation for DevConnect
* prepare any questions for presentation about security at Office Hours on Tuesday https://github.com/eth-protocol-fellows/cohort-four/issues/466
* [ ] Created PR https://github.com/ltfschoen/trin/pull/2 where I created an example calling `chain_id`, but got `RequestTimeout` errors when calling `get_block_by_hash` and raised the issue in the Discord #trin channel here https://discord.com/channels/890617081744220180/890617129425047583/1165734043371974686
### W15
* [ ] 20231031 W15 Dev update & Standup call & Office hours & Demo day <a id="w15"></a>
* TODO - hard-code the output of querying block_header_by_hash using the latest version of Helios (since that works) into Trin
* TODO - continue trying to incorporate Sogol's script into Trin to transfer ZKP between nodes
* Project showcase
* Plan future contributions to ecosystem
* [X] Fixed PR https://github.com/ltfschoen/trin/pull/2 so it gets a response to `get_block_by_hash` but not sure why i need to change the discovery port CLI option value for it to find peers, see issue https://github.com/clawbird/axiom-dapp/issues/46
* [X] Added extra commits including offer.rs to send a message to another peer that gets accepted https://github.com/ltfschoen/trin/pull/2
* [ ] Need to change it to send a ZKP instead
* [ ] Investigate https://github.com/sogolmalek/zkevm-circuits, which has a witness generator https://github.com/sogolmalek/zkevm-circuits/blob/main/mpt-witness-generator/witness_gen_wrapper.go#L13 and a verify function that we could try to import it as library inside trin
### W16
* [ ] 20231107 W16 Final Dev update <a id="w16"></a>
* Created offer_manual.rs script in https://github.com/ltfschoen/trin/pull/2
* Meeting with Sogol and Noah on 4th Nov for 2 hours
* Noah focussing on generating and verifying ZK, highlighted that the ZK is just a base64 format string that has a size of about 300kB
* Luke to focus on creating PR to Trin that:
* Test fixture with a large string to represent a ZK that has been generated by https://github.com/sogolmalek/zkevm-circuits/tree/main/mpt-witness-generator
* Write tests using peertest to represent each Trin node, since get network timeouts when trying to send offers between actual Trin nodes at the moment
* Wrap the ZK in a new message type to be transferred between Trin nodes, and to be used for verifying the ZK. It needs to store the associated finalised block number, the ZKP from the sending Trin node (which may not have been verified yet). 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
* Obtain latest block headers from History Network
* Use State Network instead of History Network (i.e. StateContentKey) for dealing with the latest state since we are interested in the latest block and otherwise using cache, to to use associated ZKPs to verify the correctness of data across Trin nodes. See https://ethereum.github.io/trin/developers/architecture/workspaces.html#trin-state
* Offer and check ZKP sent to other nearby Trin nodes
* Find other Trin nodes with latest block ZKP
* Verify the ZK by each Trin node that receives a ZK from another Trin node
* Future allow user to adjust how often to send ZKP
### W17
* Meeting on 7 Nov 9:15-10am with Sogol and Noah
* Find where to put our code in Trin and share with team
* ZK proof to be provided from an external source via a Trin API endpoint to all the Trin nodes
* So it will not be necessary to obtain it from the trin-history package block headers
* Possibly also allow Trin nodes to broadcast or find a ZK proof directly from other nearby nodes since that may be a faster way to receive the ZK proof and obtain their consensus
* Each Trin node would verify the ZK proof they have received
* Each Trin node may not need to store the ZK proof in its DB, it may only need it long enough to verify the ZK proof, and then emit an on-chain event that indicates its approval or otherwise
* Consensus vote amongst the majority of Trin nodes to determine whether to accept a specific ZK proof or not
* trin-state package of Trin to verify the correctness of the ZK proof
### Final Development Update
[Link to separate document here](https://hackmd.io/xt3aYxTlQPq4LOuBCUs2PA?view#Final-Development-Update)
### Ethconnect Conference
* [ ] 20231113 Ethconnect Istanbul
* [ ] https://devconnect.org/schedule
* [ ] https://efdn.notion.site/EPF-Devconnect-Istanbul-4f074ffed7f849a589f62e59e723d58d
* [ ] presentation by Sogol https://app.streameth.org/devconnect/epf_day/session/efficient_light_client_for_stateless_verification
* for some reason she didn't list me as a teammate, weird...
### Devconnect Satellite event in Prague (for those not going to Istanbul) 15-21 Nov
* https://dcxprague.org/
## Progress <a id="progress"></a>
* [zk-wave Repository link](https://github.com/ltfschoen/zk)
## Other Links <a id="links"></a>
* EFP
* [EFP 3 Office Hours](https://notes.ethereum.org/@MarioHavel/epf-office-hours)
* [Technical resources](../program-guide/README.md)
* [reading](../program-guide/reading.md)
* Ethereum Protocol Development Roadmap
* https://twitter.com/VitalikButerin/status/1466411377107558402/photo/1
* PoS specs: https://github.com/ethereum/consensus-specs#phase-0
* Sharding: https://notes.ethereum.org/@vbuterin/data_sharding_roadmap
* Verkle trees
* https://notes.ethereum.org/Yn_mwNa2SeeQHnKsRgekKg
* https://github.com/ltfschoen/awesome-verkle
* Expiry: https://eips.ethereum.org/EIPS/eip-4444 (history) + https://notes.ethereum.org/@vbuterin/state_expiry_eip (state)
* EVM simplification: https://hackmd.io/@vbuterin/evm_feature_removing
* EVM obj format: https://eips.ethereum.org/EIPS/eip-3540
* EVM modular ops: https://notes.ethereum.org/@axic/evm384
* Account abstraction: https://eips.ethereum.org/EIPS/eip-4337
* EIP 3074: https://eips.ethereum.org/EIPS/eip-3074
* Single slot confirmations: https://ethresear.ch/t/a-model-for-cumulative-committee-based-finality/10259
* Address space extension: https://ethereum-magicians.org/t/thoughts-on-address-space-extension-ase/6779
* DAS: https://hackmd.io/@vbuterin/das
* PBS: https://notes.ethereum.org/@vbuterin/pbs_censorship_resistance
* EPF Workshop
* https://github.com/ethereum/hive
* https://notes.ethereum.org/@MarioHavel/nodes-workshop
* https://ethereum.org/en/developers/tutorials/monitoring-geth-with-influxdb-and-grafana/
* https://www.coincashew.com/coins/overview-eth/guide-or-how-to-setup-a-validator-on-eth2-mainnet/part-i-installation/monitoring-your-validator-with-grafana-and-prometheus
* https://ethereum.github.io/beacon-APIs/
* private network - https://ephemery.dev/
* [Ethereum Yellow paper video](https://www.youtube.com/watch?v=e84V1MxRlYs)
* [Ethereum VM](https://ethervm.io/)
* [Ethereum Wiki](https://ethereum.org/en/deprecated-software/#documentation-and-information-sources)
* [Ethereum Research forum](https://ethresear.ch/)
* [Ethereum Magicians forum](https://ethereum-magicians.org/)
* [Ethereum Project Management](https://github.com/ethereum/pm)
* ZK
* See README at [https://github.com/ltfschoen/zk](https://github.com/ltfschoen/zk)
* Ethereum
* Sigma Prime https://lighthouse-book.sigmaprime.io
* RETH (Ethereum Protocol implementation)
* https://github.com/paradigmxyz/reth
* Akuna (old Ethereum implementation)
* https://github.com/akula-bft/akula
* EIP-X
* Github Team Project Repo https://github.com/sogolmalek/EIP-x
* ZK Axiom Proof generate https://github.com/axiom-crypto/axiom-eth
* https://github.com/axiom-crypto/axiom-eth/blob/main/axiom-eth/src/bin/README.md
* Axiom Verifier smart contracts https://github.com/axiom-crypto/axiom-eth/blob/main/axiom-eth/src/bin/AxiomV1.md
* Light Client (Helios) Rust implementation https://github.com/a16z/helios
* Light Client (Lodestar) TypeScript implementation https://github.com/ltfschoen/lodestar
* Prototyping Repo using Docker (Axiom + Helios + Lodestar + Trin) https://github.com/ltfschoen/axiom-quickstart
* Axiom resources
* Axiom JavaScript SDK https://github.com/axiom-crypto/axiom-sdk
* zkEVM resources
* zkEVM circuits https://github.com/sogolmalek/zkevm-circuits
* zkEVM specs https://github.com/privacy-scaling-explorations/zkevm-specs
* zETH https://www.risczero.com/news/zeth-release
* ZK resources
* Encode ZK bootcamp resources https://encodeclub.notion.site/ZK-Bootcamp-July-2023-157fcb1fa18d44eaa5d7c29df74ea074
* Halo2
* https://github.com/privacy-scaling-explorations/halo2
* https://github.com/axiom-crypto/halo2-scaffold/blob/main/examples/halo2_lib.rs
* zk Proof of Exploit zkPoEX https://github.com/zkoranges/zkPoEX
* Discussions
* Sogol ZK discussion https://github.com/ethereum/execution-apis/pull/455#discussion_r1308348563
* Portal Network
* Specs https://github.com/ethereum/portal-network-specs
* Other
* Danksharding - https://ethereum.org/en/roadmap/danksharding/
* Tooling wishlist - https://github.com/ethpandaops/tooling-wishlist
* Consensus Guide - https://notes.ethereum.org/@djrtwo/Bkn3zpwxB?type=view#Table-of-contents
* Setup Ethereum Node
* [Proxy over SSH](https://github.com/taxmeifyoucan/eth-rpc-proxy/) where user should not have to touch router settings or publish physical IP tied to their node and for remote access they can use a proxy over ssh. Also using onion is an option for private remote access.
* [Automated Node Setup](https://ethereum.org/en/developers/docs/nodes-and-clients/run-a-node/#automatized-setup)
* Lighthouse Architecture notes - https://hackmd.io/@jimmygchen/Sk9oPHO8s
* Light Clients
* https://ethereum.org/en/developers/docs/nodes-and-clients/light-clients/
* Nimbus consensus layer light client implementation. Altair consensus layer light client specs - https://github.com/ethereum/consensus-specs/tree/dev/specs/altair/light-client
* RETH https://github.com/SorellaLabs/ethers-reth
* zokrates JS example https://github.com/only4sim/zk-base-Moonbeam
Sign in with Wallet
Connect another wallet