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 APIOther subgraph projects
Programming LanguageSQLAssemblyScript/Typescript
Indexing speed~ 10.8 k - 4,176k bps*100 - 50k bps
ABI-based generatorNo (soon to come)Yes
Pre-decoded logs/transactions/tracesYesNo
Real-time indexing
(unfinalized blocks)
YesYes
Off-chain data joinsYesSometimes
Data targetsCustomizableCustomizable/Postgres-only
Customizable DB migrationsYesSometimes
Factory contract indexingYesSometimes
Multi-contract indexingYesYes/Limited
Analytical data targetsAthena, Parquet, CSV, JSON, otherSometimes/Limited
Local setupNo (soon, will not require archival node on the user side)Yes (requires archival node)
GraphQL APIAutomatically generated from a table generated from SQL codeGenerated from
schema.graphql
SubscriptionsYesYes/Limited
Hosted serviceYes (enterprise users)Yes or to be deprecated
PaymentFiat, subscription-basedFiat, 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!