FAQ

Suggest Edits

Business

Why use ZettaBlock if we already built subgraphs?

Comparing ZettaBlock to decentralized query engine solutions like The Graph, there are 4 major differences:

  1. Better performance.
    a. High availability: ZettaBlock provides 99.99% availabilities, 20x better than subgraphs.
    b. Fast indexing ETL: ZettaBlock could process 1 million rows in a few mins, 1000x faster than subgraphs.
    c. API latency: ZettaBlock API's latency is ~20ms, 20x faster than subgraphs.
  2. On-/ off-chain data silo. Data scattered across different platforms, protocols, and formats (e.g. on-chain time-series, off-chain tabular, document & blob, etc).
  3. Security risk. Extremely easy to hack the subgraph and manipulate query results.
  4. Built-in analytics and visualizations. Beyond indexing, users can write arbitrary SQL for analytics and charts directly, thanks to ZettaBlock's data lake.
An example of how a decentralized query engine is disproportionately vulnerable to malicious nodes. The top half depicts the Ethereum network, where all compute resources are working on the same task. Thus, a malicious attack would require the majority (~4000/8000) of nodes to be malicious. For platforms like The Graph, this ratio is much lower, as different subnetworks are computing different tasks. Thus, for certain tasks (e.g., to Service Group 6), only a single malicious node would be needed to corrupt output.

An example of how a decentralized query engine is disproportionately vulnerable to malicious nodes. The top half depicts the Ethereum network, where all compute resources are working on the same task. Thus, a malicious attack would require the majority (~4000/8000) of nodes to be malicious. For platforms like The Graph, this ratio is much lower, as different subnetworks are computing different tasks. Thus, for certain tasks (e.g., to Service Group 6), only a single malicious node would be needed to corrupt output.

Why use ZettaBlock if we already have BigQuery/ Snowflake?

Data warehouse solutions such as BigQuery and Snowflake are good for basic analytics use cases, but customers usually run into their limitations in a few common use cases, for example,

  1. User-facing API support: When users want to serve transformed data as a API stream to dApps/ apps, data warehouses cannot support it due to cost and performance reasons. Instead, users will turn into transactional databases. Of course, the common transactional database solutions such as Postgres can serve the purpose with the small data size. However, once the data size is beyond 1TB, users will run into DB scalability issues.
  2. Streaming needs: When users need to serve the latest transactions to the desired locations, the data freshness is extremely important. To achieve sub-second data freshness, users need to build and maintain a streaming architecture, which can be very difficult and costly.
  3. Data transformation: this is very common that the data analytics team will generate many intermediate tables for the final gold layer business logic tables, in order to reduce compute cost & SQL logic discrepancy. BigQuery, for example, cannot handle table dependency, scheduling, and orchestration for data transformation.

What’s the cost for data ingestion and storage?

No cost! Feel free to bring your own data into ZettaBlock.

Development

How to get results from curl request once the query is done

curl -X GET -u {username}:{password}

https://api.zettablock.com/qugate/v1/stream/queryruns/{queryrun_id}/result//?includeColumnName=true

replace the queryrun_id with the right one

What is the rate limit for user queries?

For a community user, we set no hard limit on the number of queries a user can execute concurrently, as long as it's within the rate limit that is shared with all community users:

  • Analytics query: max concurrency is 400.
  • GraphQL API: 1000 requests per second.

For enterprise users, we provide dedicated environments with custom rate limits.

Data

What’s ZettaBlock’s coverage of ERC20 tokens?

As of Oct 17th, 2022, we have collected 435K ERC20 tokens in ethereum_mainnet.erc20_tokens and have 99.9% of all token transfer events covered. In comparison, Dune only has 21K ERC20 tokens, which cover 70% of token transfer events. FYI: Etherscan has 659K ERC20 tokens as of the same day.

We fully automated the erc20_tokens and nft_tokens pipeline to read the most traded tokens for which we have not had the metadata and automatically fetch the data from node API on a daily basis.

Updated 5 months ago