This quarter, we made significant progress across multiple initiatives, laying the groundwork for future innovation and adoption. We finalized the GraphDoc library and improved graphdoc-server for seamless integration with graph-cli, bringing us closer to optimizing the subgraph developer workflow. We also took major steps to support AI developers using The Graph by refining and documenting our research code, which we will soon open-source. On the cryptography front, we advanced Verifiable ELTQ, implementing a Rust proof-of-concept for verifying Arbitrum blocks and developing a plan for verifying Solana blocks. Our work on verifiable querying is progressing well. We’ve started to implement the first pieces of the optimistic protocol we designed. Finally, we continued to refine indexer service and GraphTally for Horizon. We improved testing, fixed bugs, and enhanced documentation to ensure a smooth transition when the time comes. These efforts position us for even greater impact in the coming months.
In February, we were also excited to attend EthDenver, meeting some of you in person and sparking new ideas that we’re bringing to The Graph. We hope to talk a bit more about those in next month’s update, so stay tuned!
AI
GraphDoc
This month, we focused on finalizing the GraphDoc library for release, along with improving the graphdoc-server to support it’s integration with graph-cli. We are eager to incorporate this service into the existing subgraph developer workflow, kicking off our optimization pipeline to continually improve the service as it receives greater adoption. In addition, we have been speaking with many people who wanted guidance on how to use The Graph for their AI agents. To help with this, we cleaned up our research code and documented it thoroughly as a guide for people who want to build AI projects. We’ll soon open source that code and documentation. If you’re curious about that code, keep an eye out on our GitHub. We’ll make an official announcement only when the tooling is officially incorporated in the subgraph development workflow.
Cryptography
Verifiable ELTQ
Verifiable Extraction
We documented a plan for incorporating verification of Arbitrum Blocks into veemon, and toward this end we wrote an example in Rust demonstrating Arbitrum block verification. The core idea is that Arbitrum block information is periodically posted to Ethereum, either directly to the execution layer or to the consensus layer as blob data. Assuming we have a trustworthy source for Ethereum blocks (which we could get using the previously developed VE for Ethreum data), we can use this information to verify extracted Arbitrum blocks, e.g. blocks extracted using Arbitrum Firehose. Next steps for this is to update veemon to enable Arbitrum block verification.
We have documented a plan for VE of Solana data. The core idea is similar to how we verify pre-merge Ethereum execution layer blocks. We will commit to Epochs of Solana blocks using a Merkle tree data structure. The roots of the Merkle trees will become the source of truth for Solana canonical history, e.g. to verify an Epoch of extracted Solana blocks we can recompute the Merkle root given the epoch and compare against the canonical roots. Note that we are making a compromise on trust assumptions here. Because Solana does not have a data structure which affirms the history of the chain we are trusting the roots that are initially calculated as part of the VE Solana effort. The next step for this effort is to demonstrate calculation of the Merkle tree roots using an epoch of extracted Solana data, using Firehose. We will then update veemon to enable Solana verification.
Verifiable Querying
We have continued work on our optimistic protocol for verifiable queries. In particular, the last step in the dispute protocol requires calculating a Merkle inclusion proof to prove that some data is included in Ethereum’s canonical history. We have implemented the Rust types for generating these proofs for Ethereum transaction receipts. Next month, we will deliver a Rust library implementing the core steps of the protocol.
Indexer Stack
GraphTally and indexer-rs
We’re in a good spot with indexer service and GraphTally. v1 is entirely in maintenance mode, and we implemented much of what we needed to for v2 in January. The remaining pieces that we need to implement need to wait on the Horizon smart contracts to be finalized. In the meantime, we have focused on improving testing for what we’ve already built to ensure as bug-free a transition to v2 as possible. Many of our updates to GraphTally and indexer service in February were related to writing new tests, finding and fixing bugs in v2, and improving parts of the code which we suspect could become problematic. We also wanted to make it easier to use and understand the GraphTally code. We’ve updated existing documentation to better clarify common user questions, and we’ve written new developer docs that we’ll soon make public for anyone who would like to contribute to GraphTally.