Subgraphs to ZettaBlock

Generally, a subgraph is a subset of data extracted from a larger blockchain database, specifically tailored for a particular application or use case. It is designed to aggregate and process blockchain data in a way that is more accessible and efficient for developers, especially those working on decentralized applications (dApps). Subgraphs are particularly useful for developers who need to query specific data from the blockchain without having to sift through the entire blockchain data manually.

Creating a subgraph, especially in most platforms, involves a significant amount of work, including understanding the logic behind each event or function call you want to capture from a contract, and designing complex nested schemas to properly aggregate and join the results. This process is crucial for ensuring that the data extracted from the blockchain is structured in a way that is both efficient and useful for the intended application, but also extremely time-consuming!

Differentiation matrix

The section below contains some metrics around the expected performance when using ZettaBlock compared to other Subgraph Projects.

ZettaBlock SQL -> GraphQL API

Other subgraph projects

Programming Language

SQL

AssemblyScript/Typescript

Indexing speed

~ 10.8 k - 4,176k bps*

100 - 50k bps

ABI-based generator

No (soon to come)

Yes

Pre-decoded logs/transactions/traces

Yes

No

Real-time indexing
(unfinalized blocks)

Yes

Yes

Off-chain data joins

Yes

Sometimes

Data targets

Customizable

Customizable/Postgres-only

Customizable DB migrations

Yes

Sometimes

Factory contract indexing

Yes

Sometimes

Multi-contract indexing

Yes

Yes/Limited

Analytical data targets

Athena, Parquet, CSV, JSON, other

Sometimes/Limited

Local setup

No (soon, will not require archival node on the user side)

Yes (requires archival node)

GraphQL API

Automatically generated from a table generated from SQL code

Generated from
schema.graphql

Subscriptions

Yes

Yes/Limited

Hosted service

Yes (enterprise users)

Yes or to be deprecated

Payment

Fiat, subscription-based

Fiat, subscription-based, toke

*For sync sizes > 1 MB and full refresh

Using ZettaBlock SQL -> GraphQL API

Take for example a bridging contract event that we want to track and display in our UI, instead of having to go ahead and create nested structured fields and wait weeks if not months for the blockchain data to be indexed for that contract + event combination, you could use ZettaBlock.

This is how you would get your graphQL API for a particular event + contract combination:

SELECT
    transaction_hash,
    transaction_index,
    block_time,
    block_number,
    block_hash,
    log_index as evt_index,
    lower(argument_values[1]) as inputToken,
    lower(argument_values[2]) as outputToken,
    argument_values[3] as inputAmount,
    argument_values[4] as outputAmount,
    argument_values[5] as destinationChainId,
    argument_values[6] as depositId,
    to_timestamp(CAST(argument_values[7] AS numeric)) as quoteTimestamp,
    to_timestamp(CAST(argument_values[8] as numeric)) as fillDeadline,
    argument_values[9] as exclusivityDeadline,
    lower(argument_values[10]) as depositor,
    lower(argument_values[11]) as recipient,
    lower(argument_values[12]) as exclusiveRelayer,
    argument_values[13] as message,
    block_date
FROM ethereum_mainnet.logs
WHERE contract_address = '0x5c7bcd6e7de5423a257d81b442095a1a6ced35c5'
AND topics[1] = '0xa123dc29aebf7d0c3322c8eeb5b999e859f39937950ed31056532713d0de396f'
ORDER BY block_time DESC;

Now you can go ahead and click the USE button:

You can then check if your GraphQL query works using ZettaBlock’s built-in playground, as such:

And you’re set to keep building your dApp, with zero extra effort required!