Issue 1: introducing new Entity , trustless State provider

[sogolmalek]

State Provider This entity consists of Ethereum light clients providing the latest state, peer-to-peer network, and ZK circuit. We introduce a state provider entity, collaborating to validate and generate ZK-SNARKs proofs for state information.A lightweight client verifies proofs and validates state data from the state provider. Currently, in order to validate a block, light clients must request the state piece by piece. This process often leads to numerous light clients overloading the full node. With this new entity, we can streamline the process. Utilizing Helios light clients, we can validate, generate ZK proofs for the latest state information, and efficiently propagate it to all LC nodes simultaneously.

The state provider entity leverages the Helios light client to query the latest block state in a fully trustless manner. By implying peer-to-peer network, we can ensure the latest state of the block in a fully trustless and decentralized manner. Then we are able to provide succinct and constant-sized proof of the current state and propagate the ZK-proof of witness needed for execution. The current zk-proof of the state can then be propagated to all light clients at once. Light clients can effortlessly verify this proof against the mainnet, improving scalability, and reducing resource requirements for light clients. Users and applications can efficiently interact with the blockchain, relying on the security and integrity of zk-proofs to verify the state. This approach enables more participants to engage with the network without needing the computational resources and storage capacity required for full nodes.

[sogolmalek]

So far following components are implemented:

1. Client in rust has been developed to query the latest state,
2. Helios library has been used to ensure the trustlessness of the state query.
3. temporary database has been developed. the temporary in-memory database is for storing the last synced block checkpoint

[sogolmalek]

Ive implemented a custom protocol for communication between light clients. Ive used a simple message format to request and exchange data. implement a Peer Discovery and Networking: Implement a networking layer that allows light clients to discover and connect to each other. Set up a protocol for light clients to request and exchange data with their peers. for peer discovery, I’ve already used a decentralized peer-to-peer network, libp2p. libp2p, provides a flexible and extensible framework for building peer-to-peer networks.

Note: The actual implementation will require handling various events and messages from the libp2p swarm, ensuring proper error handling, and dealing with security considerations, among other things. Additionally, it may be required to add further optimizations, like using libp2p mDNS for local peer discovery and proper encryption of communication between peers.

[sogolmalek]

cashing mechanism is added

[sogolmalek]

leveraging Axiom ZK circuit to interact with helios and generate a ZKP. this ZKP can be propagated regarding the Trim specs implementations on the Portal network can be a good endovears on POC.