On the Decentralization of Subsquid
So far, the Subsquid project has released three primary products: the Subsquid SDK, the Aquarium web application, and Archives.
Subsquid SDK is a set of open-source libraries and tools for building squids, which are data indexing projects that encapsulate on-chain data ingestion, transformation, and presentation as GraphQL APIs. When we say in our marketing materials that Subsquid enables the developments of ‘powerful APIs for Web3,’ this is what we’re talking about.
Aquarium is a SaaS (which we jokingly expand as ‘squid-as-a-service’) platform that enables users of the Subsquid SDK to run their squids without needing to maintain data infrastructure themselves. Many developers choose to publish their squids to Aquarium, enabling other Web3 users to access the data endpoints for whatever purposes they see fit.
Archives are services that ingest raw on-chain data, store it in persistent storage in a normalized way, and expose it through an API for downstream data pipelines, including squids. Thanks to rich batching and filtering capabilities, these ‘pre-indexers’ allow Web3 users to access data in a granular fashion and from multiple blocks at once. In very simple terms, Archives do the ‘heavy-lifting’ for squids, allowing much more flexibility for Subsquid SDK users.
Until now, in our marketing materials and documentation, we’ve largely focused on providing information about these three main Subsquid products. Today, with this blog article, we’d like to begin to reveal our plans in terms of building the other very important aspect of the Subsquid project — the Subsquid Network. More specifically, we aim to outline our logic behind starting network decentralization from the ‘Archive layer’ of the Subsquid stack.
An Open Infrastructure Network
Subsquid Network will be an open infrastructure network. By this, we mean that we are building a trustless network that any infrastructure provider or end-user (developers and other Web3 users) may join in order to sell or purchase data resources.
As the initial bootstrappers of the Subsquid Network, we at Subsquid Labs Gmbh have determined that the best place to start the decentralization of Subsquid is at the Archive layer of Subsquid architecture.
We have made this decision for the following reasons:
1 | Ease of node deployment for operators:
In the early days of Subsquid Network, network growth will at least in part be driven by the onboarding of infrastructure providers. It is therefore in the Network’s interest to decentralize in a way that is as user-friendly as possible for these network participants.
Unlike squids, Archives have static codebases, which will be much easier for our core team to package into a ‘set-and-forget’ setup for operators. The onboarding process should be no more complicated than in any other well-known decentralized network.
2 | Archives are deterministic:
The major breakthrough of Subsquid is the flexibility that its modular architecture allows for developers. While it is wonderful that squids include such fantastic features as external API calls, custom databases, custom database migrations, and custom API extensions, the decentralization of deterministic services is far more straightforward.
Fortunately, the data that Archives serve is always static — it should be possible to ensure reproducible query responses from independent nodes no matter the hardware used. In other words, many node operators on different machines can run Archives for the same blockchain and produce the same results.
3 | Trustless pricing:
With the technology that is currently available to us, it is difficult to predict the amount of computing resources required by squids in a trustless way. As a result, it would be quite complicated to define a fair and noncustodial pricing model for a network of squids. Archives, on the other hand, require a very predictable amount of computing resources. Automating a marketplace for data resources among operators of Archives, therefore, is far more manageable. We expect to elaborate on our thoughts on this issue on this blog in the near future.
The Roles of SQD and Stablecoins
In our publications, we have yet to go into much detail regarding the use-cases of SQD, the Subsquid Network’s native token. In addition to serving as a trustless payment medium and work token within the decentralized network of Archives, SQD will also serve a role in governance. SQD holders will periodically vote on resolutions relating to the protocol and the SDK.
Squids (and any other application based on the Subsquid SDK) will need to acquire SQD in order to pay for access to the data provided by Archives. Our protocol developers are still working on the specifics of how this will work, but it will most likely be a query-fee market that functions in a similar manner to gas fees on Ethereum.
Despite the fact that Archives only accept SQD tokens, a very important point is that end-users will be able to pay in stablecoins. This will be enabled by service providers utilizing the Archive network. For example, our own company, Subsquid Labs GmbH (which maintains the Aquarium), may decide to accept payments in USDC for its services.
The ability to pay for services in stablecoins, we believe, is essential. This will provide end users and their businesses with predictability when budgeting for computing resources.
Conclusion and Disclaimer
The purpose of this blog was to provide just a bit more clarity about the Subsquid Network. A disclaimer, however, is necessary:The network is still very much a work in progress.
We have recently grown our protocol development team and are busy doing research and testing features. For now, we welcome your feedback in the comments section below or in direct messages via any of our official channels.
Official Channels
Twitter | Discord | LinkedIn | Telegram | GitHub | Newsletter | Subsocial
