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!
Updated 7 months ago