Introduction

We at Hyper Oracle have recently been building a Subgraph-like zkGraph for developers to write data mapping that can be converted into ZK circuits.

In developing zkGraph, I've drawn inspiration and experience from a number of components in The Graph, as well as attempting to make it backward-compatible to Subgraph.

I've taken a closer look at graph-ts, a library developed for Subgraph, and have some thoughts on it.

1. Usage

If you follow the documentation in their repo to download the npm library and use it in an AssemblyScript project, you'll find that there's no way to use it directly without the other graph cli.

This is related to the following point. There is no way to use this library on its own, which is confusing.

2. Implementation Language

Most of graph-ts is implemented in AssemblyScript, but there are a lot of functions that are just defined in AssemblyScript and not implemented. The implementation is in the Graph Node, which is in Rust.

The main reason for this may be performance, or problems with the AssemblyScript language in early days. See discussion here. Side note: AssemblyScript is sponsored by Near, The Graph, and Shopify, so they are basically the early and the only adopters lol.

As a result of having more than one implementation language, you can't compile the whole graph-ts individually. Also for developers like me who want to achieve Subgraph compatibility, it's very difficult to guess all the functionality and behavior.

3. Naming of Math Operators

People are saying BigInt api is not cool. BigInt's math operations are called plus, minus, times, not add, sub, mul as is the normal JS convention. It's possible to use operators like "+, -, *" directly, but the IDE tends to complain.

In the zkGraph implementation, we support both plus and add operators for Math, so both can be used.

4. Endian

little-endian is the default in graph-ts. But in reality, all of Ethereum's scenarios use big-endian. I think The Graph may have adopted little-endian, which is more common in all scenarios, for the sake of generality.

In zkGraph, we have implemented a similar little-endian function and an additional big-endian version.

5. Conversions

Some conversion functions are weird. For example, toHex and toHexString behave the same, which is redundant. It’s probably, again, the legacy of AssemblyScript.

I submitted a pr, but it’s still pending. In zkGraph, toHexString can take a prefix as input, or if there’s no input, then it’s the same as toHex.

6. Documentation

Overall, the documentation is very good, but it always feels like it was good in the first version and has not been updated accordingly.

For example, there are many functions that are in the implementation, but not in the documentation.