From 94f9dc16fee2f42f2ea4fa98b5f831a68c31dce7 Mon Sep 17 00:00:00 2001 From: Marc Puig Date: Wed, 20 Apr 2022 18:50:26 +0200 Subject: [PATCH 01/13] First draft of the Cosmos documentation --- navigation/navigation.ts | 3 + pages/es/supported-networks/cosmos.mdx | 191 +++++++++++++++++++++++++ 2 files changed, 194 insertions(+) create mode 100644 pages/es/supported-networks/cosmos.mdx diff --git a/navigation/navigation.ts b/navigation/navigation.ts index 4c36d8678255..85d9b60e9596 100644 --- a/navigation/navigation.ts +++ b/navigation/navigation.ts @@ -132,6 +132,9 @@ export const navigation: (locale: AppLocale) => NavItemDefinition[] = (locale) = { slug: 'near', }, + { + slug: 'cosmos', + }, ], }, ] diff --git a/pages/es/supported-networks/cosmos.mdx b/pages/es/supported-networks/cosmos.mdx new file mode 100644 index 000000000000..f7a29ab1f62a --- /dev/null +++ b/pages/es/supported-networks/cosmos.mdx @@ -0,0 +1,191 @@ +--- +title: Building Subgraphs on Cosmos Hub +--- + +This guide is an introduction on building subgraphs indexing the [Cosmos Hub blockchain](https://hub.cosmos.network/). + +## What is Cosmos Hub? + +[Cosmos](https://cosmos.network/) is an ecosystem of blockchains that can scale and interoperate with each other. Cosmos Hub is the first blockchain in the ecosystem. You can visit the [official documentation](https://docs.cosmos.network/) for more information. + +## What are Cosmos subgraphs? + +Cosmos subgraphs are a new type of subgraph that [Graph Node](https://github.com/graphprotocol/graph-node) is now able to process. This allows to index and store data inside the Cosmos Hub blockchain, and make that resulting data easily available via GraphQL API. + +Cosmos subgraphs will differ from other implementations, such as Ethereum, in that there is no need to specify a smart contract from which events and data will be indexed from. In this case, Graph Node is monitoring all data appended to the chain. + +There are currently three types of handlers supported for the Cosmos Hub subgraphs: + +- Block handlers. +- [Event](https://docs.cosmos.network/master/core/events.html) handlers. +- [Transaction](https://docs.cosmos.network/master/core/transactions.html) handlers. + +Based on the [official Cosmos documentation](https://docs.cosmos.network/): + +> Events are objects that contain information about the execution of the application. They are mainly used by service providers like block explorers and wallet to track the execution of various messages and index transactions. + +> Transactions are objects created by end-users to trigger state changes in the application. + +## Building a Cosmos Hub subgraph + +### Subgraph Dependencies + +[graph-cli](https://github.com/graphprotocol/graph-cli) is a CLI tool to build and deploy subgraphs, version `>=0.23.0` is required in order to work with Cosmos Hub subgraphs. + +[graph-ts](https://github.com/graphprotocol/graph-ts) is a library of subgraph-specific types, version `>=0.23.0` is required in order to work with Cosmos Hub subgraphs. + +### Subgraph Main Components + +There are three main key parts or files when it comes to define a subgraph: + +**subgraph.yaml**: a YAML file containing the subgraph manifest. + +**schema.graphql**: a GraphQL schema that defines what data is stored for your subgraph, and how to query it via GraphQL. + +**AssemblyScript Mappings**: [AssemblyScript](https://github.com/AssemblyScript/assemblyscript) code that translates from the event data to the entities defined in your schema. + +### Subgraph Manifest Definition + +The subgraph manifest (`subgraph.yaml`) identifies the data sources for the subgraph, the triggers of interest, and the functions that should be run in response to those triggers. See below for an example subgraph manifest for a Cosmos Hub subgraph: + +```yaml +specVersion: 0.0.2 +description: Cosmos Subgraph Example +schema: + file: ./schema.graphql # link to the schema file +dataSources: + - kind: cosmos + network: cosmoshub-4 + source: + startBlock: 0 # Required for Cosmos, set this to 0 to start indexing from chain genesis + mapping: + apiVersion: 0.0.5 + language: wasm/assemblyscript + blockHandlers: + - handler: handleNewBlock # the function name in the mapping file + eventHandlers: + - event: rewards # the type of the event that will be handled + handler: handleReward # the function name in the mapping file + transactionHandlers: + - handler: handleTransaction # the function name in the mapping file + file: ./src/mapping.ts # link to the file with the Assemblyscript mappings +``` + +- Cosmos Hub subgraphs introduce a new `kind` of data source (`cosmos`). +- The `network` should correspond to a network on the hosting Graph Node. Cosmos Hub mainnet is `cosmoshub-4`. Other Cosmos Hub networks, i.e. `cosmoshub-3`, are halted, therefore no data is provided for them. + +Cosmos Hub data sources support three types of handlers: + +- `blockHandlers`: run on every new block appended to the chain. The handler will receive a full block and all its data containing, among other things, all the events and transactions. +- `eventHandlers`: run on every event, except if there is an event type specified in the handler definition, in that case only events of that type are processed. Block data is also passed onto the mapping in order to have context of the event within the chain. +- `transactionHandlers`: run for every transaction executed. The mapping is provided with all the relevant data related to the transaction and a block abstraction that can be used to acquire context of the transaction within a block and within the chain. + +Event and Transaction handlers are a way to process meaningful data from the chain without the need of processing a whole block. The data processed by them can also be found in the block handlers, since events and transactions are also part of a block, but removes the need of processing unnecessary data. + +### Schema Definition + +Schema definition describes the structure of the resulting subgraph database, and the relationships between entities. This is agnostic of the original data source. There are more details on subgraph schema definition [here](https://thegraph.com/docs/en/developer/create-subgraph-hosted/#the-graph-ql-schema). + +### AssemblyScript Mappings + +The handlers for processing events are written in [AssemblyScript](https://www.assemblyscript.org/). + +Cosmos Hub indexing introduces Cosmos-specific data types to the [AssemblyScript API](https://thegraph.com/docs/en/developer/assemblyscript-api/). + +```tsx +class EventList { + newBlock: EventBlock + transaction: Array + validatorSetUpdates: EventValidatorSetUpdates +} + +class EventData { + event: Event + block: EventBlock +} + +class TransactionData { + tx: TxResult + block: EventBlock +} + +class EventBlock { + block: Block + blockId: BlockID + resultBeginBlock: ResponseBeginBlock + resultEndBlock: ResponseEndBlock +} + +class EventTx { + txResult: TxResult +} + +class TxResult { + height: u64 + index: u32 + tx: Bytes + result: ResponseDeliverTx + hash: Bytes +} + +class Event { + eventType: string + attributes: Array +} +``` + +The types above are just the general ones that mappings use. You can find the full list of types for the Cosmos Hub integration [here](https://github.com/graphprotocol/graph-ts/blob/main/chain/tendermint.ts). + +Each type of handler will receive a different type based on the relevant data. For both event and transaction handlers, a reference to the block they are contained in is passed as well. These are the exact types that are passed as a parameter to each mapping function: + +`EventList` is passed to the blockHandler. + +`EventData` is passed to the eventHandler. + +`TransactionData` is passed to the transactionHandler. + +## Creating and building a Cosmos Hub subgraph + +The first step before starting to write the subgraph mappings is to generate the type bindings based on the entities that have been defined in the subgraph schema file (`schema.graphql`). This will allow the mapping functions to create new objects of those types and save them to the store. This is done by using the `codegen` CLI command: + +```bash +$ graph codegen +``` + +Once the mappings are ready, the subgraph needs to be built. This step will highlight any errors the manifest or the mappings might have. A subgraph needs to build successfully in order to be deployed to the Graph Node. It can be done using the `build` CLI command: + +```bash +$ graph build +``` + +## Deploying a Cosmos Hub subgraph + +When the subgraph builds successfully, it is time to deploy it to a Graph Node instance for indexing. Cosmos subgraphs can be deployed to any Graph Node on version `>=v0.26.x`. + +The first thing to do is create the subgraph in the node, this only has to be done once via the `create` CLI command: + +```bash +$ graph create subgraph-name --node +``` + +After the subgraph has been created, it can be deployed by using the graph `deploy` CLI command: + +```bash +$ graph deploy subgraph-name --ipfs --node +``` + +Once your subgraph has been deployed, it will be indexed by Graph Node. You can check its progress by querying the subgraph itself at the exposed endpoint. + +## Querying a Cosmos Hub subgraph + +The GraphQL endpoint for Cosmos Hub subgraphs is determined by the schema definition, with the existing API interface. Please visit the [GraphQL API documentation](https://thegraph.com/docs/en/developer/graphql-api/) for more information. + +## Example Subgraphs + +Here are some example subgraphs for reference: + +Cosmos Hub Block Subgraph + +Cosmos Hub Event Subgraph + +Cosmos Hub Transaction Subgraph From c1c50a8b1a8ed24c3b65b896b80388a63c4e84f6 Mon Sep 17 00:00:00 2001 From: Marc Puig Date: Wed, 27 Apr 2022 16:52:15 +0200 Subject: [PATCH 02/13] Apply feedback --- pages/ar/supported-networks/cosmos.mdx | 209 +++++++++++++++++++++++++ pages/en/supported-networks/cosmos.mdx | 209 +++++++++++++++++++++++++ pages/es/supported-networks/cosmos.mdx | 78 +++++---- pages/ja/supported-networks/cosmos.mdx | 209 +++++++++++++++++++++++++ pages/ko/supported-networks/cosmos.mdx | 209 +++++++++++++++++++++++++ pages/vi/supported-networks/cosmos.mdx | 209 +++++++++++++++++++++++++ pages/zh/supported-networks/cosmos.mdx | 209 +++++++++++++++++++++++++ 7 files changed, 1302 insertions(+), 30 deletions(-) create mode 100644 pages/ar/supported-networks/cosmos.mdx create mode 100644 pages/en/supported-networks/cosmos.mdx create mode 100644 pages/ja/supported-networks/cosmos.mdx create mode 100644 pages/ko/supported-networks/cosmos.mdx create mode 100644 pages/vi/supported-networks/cosmos.mdx create mode 100644 pages/zh/supported-networks/cosmos.mdx diff --git a/pages/ar/supported-networks/cosmos.mdx b/pages/ar/supported-networks/cosmos.mdx new file mode 100644 index 000000000000..05bc2f69935f --- /dev/null +++ b/pages/ar/supported-networks/cosmos.mdx @@ -0,0 +1,209 @@ +--- +title: Building Subgraphs on Cosmos Hub +--- + +This guide is an introduction on building subgraphs indexing the [Cosmos Hub blockchain](https://hub.cosmos.network/). + +## What is Cosmos Hub? + +[Cosmos](https://cosmos.network/) is an ecosystem of blockchains that can scale and interoperate with each other. Cosmos Hub is the first blockchain in the ecosystem. You can visit the [official documentation](https://docs.cosmos.network/) for more information. + +## What are Cosmos subgraphs? + +Cosmos subgraphs are a new type of subgraph that [Graph Node](https://github.com/graphprotocol/graph-node) is now able to process. This allows Cosmos Hub developers to easily index on-chain events into a useful data set, easily available to query via GraphQL. + +There are currently three types of handlers supported for the Cosmos Hub subgraphs: + +- Block handlers. +- [Event](https://docs.cosmos.network/master/core/events.html) handlers. +- [Transaction](https://docs.cosmos.network/master/core/transactions.html) handlers. + +Based on the [official Cosmos documentation](https://docs.cosmos.network/): + +> Events are objects that contain information about the execution of the application. They are mainly used by service providers like block explorers and wallet to track the execution of various messages and index transactions. + +> Transactions are objects created by end-users to trigger state changes in the application. + +## Building a Cosmos Hub subgraph + +### Subgraph Dependencies + +[graph-cli](https://github.com/graphprotocol/graph-cli) is a CLI tool to build and deploy subgraphs, version `>=0.30.0` is required in order to work with Cosmos Hub subgraphs. + +[graph-ts](https://github.com/graphprotocol/graph-ts) is a library of subgraph-specific types, version `>=0.27.0` is required in order to work with Cosmos Hub subgraphs. + +### Subgraph Main Components + +There are three main key parts or files when it comes to defining a subgraph: + +**subgraph.yaml**: a YAML file containing the subgraph manifest, which identifies which events to track and how to process them. + +**schema.graphql**: a GraphQL schema that defines what data is stored for your subgraph, and how to query it via GraphQL. + +**AssemblyScript Mappings**: [AssemblyScript](https://github.com/AssemblyScript/assemblyscript) code that translates from the event data to the entities defined in your schema. + +### Subgraph Manifest Definition + +The subgraph manifest (`subgraph.yaml`) identifies the data sources for the subgraph, the triggers of interest, and the functions that should be run in response to those triggers. See below for an example subgraph manifest for a Cosmos Hub subgraph: + +```yaml +specVersion: 0.0.5 +description: Cosmos Subgraph Example +schema: + file: ./schema.graphql # link to the schema file +dataSources: + - kind: cosmos + network: cosmoshub-4 + source: + startBlock: 0 # Required for Cosmos, set this to 0 to start indexing from chain genesis + mapping: + apiVersion: 0.0.7 + language: wasm/assemblyscript + blockHandlers: + - handler: handleNewBlock # the function name in the mapping file + eventHandlers: + - event: rewards # the type of the event that will be handled + handler: handleReward # the function name in the mapping file + transactionHandlers: + - handler: handleTransaction # the function name in the mapping file + file: ./src/mapping.ts # link to the file with the Assemblyscript mappings +``` + +- Cosmos Hub subgraphs introduce a new `kind` of data source (`cosmos`). +- The `network` should correspond to a network on the hosting Graph Node. Cosmos Hub mainnet is `cosmoshub-4`. Cosmos Hub current testnet is `theta-testnet-001`. Other Cosmos Hub networks, i.e. `cosmoshub-3`, are halted, therefore no data is provided for them. + +Cosmos Hub data sources support three types of handlers: + +- `blockHandlers`: run on every new block appended to the chain. The handler will receive a full block and all its data containing, among other things, all the events and transactions. +- `eventHandlers`: run on every event, except if there is an event type specified in the handler definition, in that case only events of that type are processed. Block data is also passed onto the mapping in order to have context of the event within the chain. +- `transactionHandlers`: run for every transaction executed. The mapping is provided with all the relevant data related to the transaction and a block abstraction that can be used to acquire context of the transaction within a block and within the chain. + +Event and Transaction handlers are a way to process meaningful data from the chain without the need of processing a whole block. The data processed by them can also be found in the block handlers, since events and transactions are also part of a block, but removes the need of processing unnecessary data. + +### Schema Definition + +Schema definition describes the structure of the resulting subgraph database, and the relationships between entities. This is agnostic of the original data source. There are more details on subgraph schema definition [here](https://thegraph.com/docs/en/developer/create-subgraph-hosted/#the-graph-ql-schema). + +### AssemblyScript Mappings + +The handlers for processing events are written in [AssemblyScript](https://www.assemblyscript.org/). + +Cosmos Hub indexing introduces Cosmos-specific data types to the [AssemblyScript API](https://thegraph.com/docs/en/developer/assemblyscript-api/). + +```tsx +class Block { + header: Header + evidence: EvidenceList + resultBeginBlock: ResponseBeginBlock + resultEndBlock: ResponseEndBlock + transactions: Array + validatorUpdates: Array +} + +class EventData { + event: Event + block: HeaderOnlyBlock +} + +class TransactionData { + tx: TxResult + block: HeaderOnlyBlock +} + +// HeaderOnlyBlock is a standard [Block] structure where all other fields are +// removed so that hydrating that object from a [Block] bytes payload will +// drastically reduce allocated memory required to hold the full block. +// +// This can be used to unpack a [Block] when only the [Header] information +// is required and greatly reduce required memory. +class HeaderOnlyBlock { + header: Header +} + +class Header { + version: Consensus + chainId: string + height: u64 + time: Timestamp + lastBlockId: BlockID + lastCommitHash: Bytes + dataHash: Bytes + validatorsHash: Bytes + nextValidatorsHash: Bytes + consensusHash: Bytes + appHash: Bytes + lastResultsHash: Bytes + evidenceHash: Bytes + proposerAddress: Bytes + hash: Bytes +} + +class TxResult { + height: u64 + index: u32 + tx: Bytes + result: ResponseDeliverTx + hash: Bytes +} + +class Event { + eventType: string + attributes: Array +} +``` + +The types above are just the general ones that mappings use. You can find the full list of types for the Cosmos Hub integration [here](https://github.com/graphprotocol/graph-ts/blob/main/chain/cosmos.ts). + +Each type of handler will receive a different type based on the relevant data. For both event and transaction handlers, a reference to the block they are contained in is passed as well. These are the exact types that are passed as a parameter to each mapping function: + +`Block` is passed to the blockHandler. + +`EventData` is passed to the eventHandler. + +`TransactionData` is passed to the transactionHandler. + +## Creating and building a Cosmos Hub subgraph + +The first step before starting to write the subgraph mappings is to generate the type bindings based on the entities that have been defined in the subgraph schema file (`schema.graphql`). This will allow the mapping functions to create new objects of those types and save them to the store. This is done by using the `codegen` CLI command: + +```bash +$ graph codegen +``` + +Once the mappings are ready, the subgraph needs to be built. This step will highlight any errors the manifest or the mappings might have. A subgraph needs to build successfully in order to be deployed to the Graph Node. It can be done using the `build` CLI command: + +```bash +$ graph build +``` + +## Deploying a Cosmos Hub subgraph + +When the subgraph builds successfully, it is time to deploy it to a Graph Node instance for indexing. Cosmos subgraphs can be deployed to any Graph Node on version `>=v0.26.0`. + +The first thing to do is create the subgraph in the node, this only has to be done once via the `create` CLI command: + +```bash +$ graph create subgraph-name --node +``` + +After the subgraph has been created, it can be deployed by using the graph `deploy` CLI command: + +```bash +$ graph deploy subgraph-name --ipfs --node +``` + +Once your subgraph has been deployed, it will be indexed by Graph Node. You can check its progress by querying the subgraph itself at the exposed endpoint. + +## Querying a Cosmos Hub subgraph + +The GraphQL endpoint for Cosmos Hub subgraphs is determined by the schema definition, with the existing API interface. Please visit the [GraphQL API documentation](https://thegraph.com/docs/en/developer/graphql-api/) for more information. + +## Example Subgraphs + +Here are some example subgraphs for reference: + +[Cosmos Hub Block Subgraph](https://github.com/graphprotocol/example-subgraph/tree/cosmos-block-example) + +[Cosmos Hub Event Subgraph](https://github.com/graphprotocol/example-subgraph/tree/cosmos-event-example) + +[Cosmos Hub Transaction Subgraph](https://github.com/graphprotocol/example-subgraph/tree/cosmos-transaction-example) diff --git a/pages/en/supported-networks/cosmos.mdx b/pages/en/supported-networks/cosmos.mdx new file mode 100644 index 000000000000..05bc2f69935f --- /dev/null +++ b/pages/en/supported-networks/cosmos.mdx @@ -0,0 +1,209 @@ +--- +title: Building Subgraphs on Cosmos Hub +--- + +This guide is an introduction on building subgraphs indexing the [Cosmos Hub blockchain](https://hub.cosmos.network/). + +## What is Cosmos Hub? + +[Cosmos](https://cosmos.network/) is an ecosystem of blockchains that can scale and interoperate with each other. Cosmos Hub is the first blockchain in the ecosystem. You can visit the [official documentation](https://docs.cosmos.network/) for more information. + +## What are Cosmos subgraphs? + +Cosmos subgraphs are a new type of subgraph that [Graph Node](https://github.com/graphprotocol/graph-node) is now able to process. This allows Cosmos Hub developers to easily index on-chain events into a useful data set, easily available to query via GraphQL. + +There are currently three types of handlers supported for the Cosmos Hub subgraphs: + +- Block handlers. +- [Event](https://docs.cosmos.network/master/core/events.html) handlers. +- [Transaction](https://docs.cosmos.network/master/core/transactions.html) handlers. + +Based on the [official Cosmos documentation](https://docs.cosmos.network/): + +> Events are objects that contain information about the execution of the application. They are mainly used by service providers like block explorers and wallet to track the execution of various messages and index transactions. + +> Transactions are objects created by end-users to trigger state changes in the application. + +## Building a Cosmos Hub subgraph + +### Subgraph Dependencies + +[graph-cli](https://github.com/graphprotocol/graph-cli) is a CLI tool to build and deploy subgraphs, version `>=0.30.0` is required in order to work with Cosmos Hub subgraphs. + +[graph-ts](https://github.com/graphprotocol/graph-ts) is a library of subgraph-specific types, version `>=0.27.0` is required in order to work with Cosmos Hub subgraphs. + +### Subgraph Main Components + +There are three main key parts or files when it comes to defining a subgraph: + +**subgraph.yaml**: a YAML file containing the subgraph manifest, which identifies which events to track and how to process them. + +**schema.graphql**: a GraphQL schema that defines what data is stored for your subgraph, and how to query it via GraphQL. + +**AssemblyScript Mappings**: [AssemblyScript](https://github.com/AssemblyScript/assemblyscript) code that translates from the event data to the entities defined in your schema. + +### Subgraph Manifest Definition + +The subgraph manifest (`subgraph.yaml`) identifies the data sources for the subgraph, the triggers of interest, and the functions that should be run in response to those triggers. See below for an example subgraph manifest for a Cosmos Hub subgraph: + +```yaml +specVersion: 0.0.5 +description: Cosmos Subgraph Example +schema: + file: ./schema.graphql # link to the schema file +dataSources: + - kind: cosmos + network: cosmoshub-4 + source: + startBlock: 0 # Required for Cosmos, set this to 0 to start indexing from chain genesis + mapping: + apiVersion: 0.0.7 + language: wasm/assemblyscript + blockHandlers: + - handler: handleNewBlock # the function name in the mapping file + eventHandlers: + - event: rewards # the type of the event that will be handled + handler: handleReward # the function name in the mapping file + transactionHandlers: + - handler: handleTransaction # the function name in the mapping file + file: ./src/mapping.ts # link to the file with the Assemblyscript mappings +``` + +- Cosmos Hub subgraphs introduce a new `kind` of data source (`cosmos`). +- The `network` should correspond to a network on the hosting Graph Node. Cosmos Hub mainnet is `cosmoshub-4`. Cosmos Hub current testnet is `theta-testnet-001`. Other Cosmos Hub networks, i.e. `cosmoshub-3`, are halted, therefore no data is provided for them. + +Cosmos Hub data sources support three types of handlers: + +- `blockHandlers`: run on every new block appended to the chain. The handler will receive a full block and all its data containing, among other things, all the events and transactions. +- `eventHandlers`: run on every event, except if there is an event type specified in the handler definition, in that case only events of that type are processed. Block data is also passed onto the mapping in order to have context of the event within the chain. +- `transactionHandlers`: run for every transaction executed. The mapping is provided with all the relevant data related to the transaction and a block abstraction that can be used to acquire context of the transaction within a block and within the chain. + +Event and Transaction handlers are a way to process meaningful data from the chain without the need of processing a whole block. The data processed by them can also be found in the block handlers, since events and transactions are also part of a block, but removes the need of processing unnecessary data. + +### Schema Definition + +Schema definition describes the structure of the resulting subgraph database, and the relationships between entities. This is agnostic of the original data source. There are more details on subgraph schema definition [here](https://thegraph.com/docs/en/developer/create-subgraph-hosted/#the-graph-ql-schema). + +### AssemblyScript Mappings + +The handlers for processing events are written in [AssemblyScript](https://www.assemblyscript.org/). + +Cosmos Hub indexing introduces Cosmos-specific data types to the [AssemblyScript API](https://thegraph.com/docs/en/developer/assemblyscript-api/). + +```tsx +class Block { + header: Header + evidence: EvidenceList + resultBeginBlock: ResponseBeginBlock + resultEndBlock: ResponseEndBlock + transactions: Array + validatorUpdates: Array +} + +class EventData { + event: Event + block: HeaderOnlyBlock +} + +class TransactionData { + tx: TxResult + block: HeaderOnlyBlock +} + +// HeaderOnlyBlock is a standard [Block] structure where all other fields are +// removed so that hydrating that object from a [Block] bytes payload will +// drastically reduce allocated memory required to hold the full block. +// +// This can be used to unpack a [Block] when only the [Header] information +// is required and greatly reduce required memory. +class HeaderOnlyBlock { + header: Header +} + +class Header { + version: Consensus + chainId: string + height: u64 + time: Timestamp + lastBlockId: BlockID + lastCommitHash: Bytes + dataHash: Bytes + validatorsHash: Bytes + nextValidatorsHash: Bytes + consensusHash: Bytes + appHash: Bytes + lastResultsHash: Bytes + evidenceHash: Bytes + proposerAddress: Bytes + hash: Bytes +} + +class TxResult { + height: u64 + index: u32 + tx: Bytes + result: ResponseDeliverTx + hash: Bytes +} + +class Event { + eventType: string + attributes: Array +} +``` + +The types above are just the general ones that mappings use. You can find the full list of types for the Cosmos Hub integration [here](https://github.com/graphprotocol/graph-ts/blob/main/chain/cosmos.ts). + +Each type of handler will receive a different type based on the relevant data. For both event and transaction handlers, a reference to the block they are contained in is passed as well. These are the exact types that are passed as a parameter to each mapping function: + +`Block` is passed to the blockHandler. + +`EventData` is passed to the eventHandler. + +`TransactionData` is passed to the transactionHandler. + +## Creating and building a Cosmos Hub subgraph + +The first step before starting to write the subgraph mappings is to generate the type bindings based on the entities that have been defined in the subgraph schema file (`schema.graphql`). This will allow the mapping functions to create new objects of those types and save them to the store. This is done by using the `codegen` CLI command: + +```bash +$ graph codegen +``` + +Once the mappings are ready, the subgraph needs to be built. This step will highlight any errors the manifest or the mappings might have. A subgraph needs to build successfully in order to be deployed to the Graph Node. It can be done using the `build` CLI command: + +```bash +$ graph build +``` + +## Deploying a Cosmos Hub subgraph + +When the subgraph builds successfully, it is time to deploy it to a Graph Node instance for indexing. Cosmos subgraphs can be deployed to any Graph Node on version `>=v0.26.0`. + +The first thing to do is create the subgraph in the node, this only has to be done once via the `create` CLI command: + +```bash +$ graph create subgraph-name --node +``` + +After the subgraph has been created, it can be deployed by using the graph `deploy` CLI command: + +```bash +$ graph deploy subgraph-name --ipfs --node +``` + +Once your subgraph has been deployed, it will be indexed by Graph Node. You can check its progress by querying the subgraph itself at the exposed endpoint. + +## Querying a Cosmos Hub subgraph + +The GraphQL endpoint for Cosmos Hub subgraphs is determined by the schema definition, with the existing API interface. Please visit the [GraphQL API documentation](https://thegraph.com/docs/en/developer/graphql-api/) for more information. + +## Example Subgraphs + +Here are some example subgraphs for reference: + +[Cosmos Hub Block Subgraph](https://github.com/graphprotocol/example-subgraph/tree/cosmos-block-example) + +[Cosmos Hub Event Subgraph](https://github.com/graphprotocol/example-subgraph/tree/cosmos-event-example) + +[Cosmos Hub Transaction Subgraph](https://github.com/graphprotocol/example-subgraph/tree/cosmos-transaction-example) diff --git a/pages/es/supported-networks/cosmos.mdx b/pages/es/supported-networks/cosmos.mdx index f7a29ab1f62a..05bc2f69935f 100644 --- a/pages/es/supported-networks/cosmos.mdx +++ b/pages/es/supported-networks/cosmos.mdx @@ -10,9 +10,7 @@ This guide is an introduction on building subgraphs indexing the [Cosmos Hub blo ## What are Cosmos subgraphs? -Cosmos subgraphs are a new type of subgraph that [Graph Node](https://github.com/graphprotocol/graph-node) is now able to process. This allows to index and store data inside the Cosmos Hub blockchain, and make that resulting data easily available via GraphQL API. - -Cosmos subgraphs will differ from other implementations, such as Ethereum, in that there is no need to specify a smart contract from which events and data will be indexed from. In this case, Graph Node is monitoring all data appended to the chain. +Cosmos subgraphs are a new type of subgraph that [Graph Node](https://github.com/graphprotocol/graph-node) is now able to process. This allows Cosmos Hub developers to easily index on-chain events into a useful data set, easily available to query via GraphQL. There are currently three types of handlers supported for the Cosmos Hub subgraphs: @@ -30,15 +28,15 @@ Based on the [official Cosmos documentation](https://docs.cosmos.network/): ### Subgraph Dependencies -[graph-cli](https://github.com/graphprotocol/graph-cli) is a CLI tool to build and deploy subgraphs, version `>=0.23.0` is required in order to work with Cosmos Hub subgraphs. +[graph-cli](https://github.com/graphprotocol/graph-cli) is a CLI tool to build and deploy subgraphs, version `>=0.30.0` is required in order to work with Cosmos Hub subgraphs. -[graph-ts](https://github.com/graphprotocol/graph-ts) is a library of subgraph-specific types, version `>=0.23.0` is required in order to work with Cosmos Hub subgraphs. +[graph-ts](https://github.com/graphprotocol/graph-ts) is a library of subgraph-specific types, version `>=0.27.0` is required in order to work with Cosmos Hub subgraphs. ### Subgraph Main Components -There are three main key parts or files when it comes to define a subgraph: +There are three main key parts or files when it comes to defining a subgraph: -**subgraph.yaml**: a YAML file containing the subgraph manifest. +**subgraph.yaml**: a YAML file containing the subgraph manifest, which identifies which events to track and how to process them. **schema.graphql**: a GraphQL schema that defines what data is stored for your subgraph, and how to query it via GraphQL. @@ -49,7 +47,7 @@ There are three main key parts or files when it comes to define a subgraph: The subgraph manifest (`subgraph.yaml`) identifies the data sources for the subgraph, the triggers of interest, and the functions that should be run in response to those triggers. See below for an example subgraph manifest for a Cosmos Hub subgraph: ```yaml -specVersion: 0.0.2 +specVersion: 0.0.5 description: Cosmos Subgraph Example schema: file: ./schema.graphql # link to the schema file @@ -59,7 +57,7 @@ dataSources: source: startBlock: 0 # Required for Cosmos, set this to 0 to start indexing from chain genesis mapping: - apiVersion: 0.0.5 + apiVersion: 0.0.7 language: wasm/assemblyscript blockHandlers: - handler: handleNewBlock # the function name in the mapping file @@ -72,7 +70,7 @@ dataSources: ``` - Cosmos Hub subgraphs introduce a new `kind` of data source (`cosmos`). -- The `network` should correspond to a network on the hosting Graph Node. Cosmos Hub mainnet is `cosmoshub-4`. Other Cosmos Hub networks, i.e. `cosmoshub-3`, are halted, therefore no data is provided for them. +- The `network` should correspond to a network on the hosting Graph Node. Cosmos Hub mainnet is `cosmoshub-4`. Cosmos Hub current testnet is `theta-testnet-001`. Other Cosmos Hub networks, i.e. `cosmoshub-3`, are halted, therefore no data is provided for them. Cosmos Hub data sources support three types of handlers: @@ -93,35 +91,55 @@ The handlers for processing events are written in [AssemblyScript](https://www. Cosmos Hub indexing introduces Cosmos-specific data types to the [AssemblyScript API](https://thegraph.com/docs/en/developer/assemblyscript-api/). ```tsx -class EventList { - newBlock: EventBlock - transaction: Array - validatorSetUpdates: EventValidatorSetUpdates +class Block { + header: Header + evidence: EvidenceList + resultBeginBlock: ResponseBeginBlock + resultEndBlock: ResponseEndBlock + transactions: Array + validatorUpdates: Array } class EventData { event: Event - block: EventBlock + block: HeaderOnlyBlock } class TransactionData { tx: TxResult - block: EventBlock + block: HeaderOnlyBlock } -class EventBlock { - block: Block - blockId: BlockID - resultBeginBlock: ResponseBeginBlock - resultEndBlock: ResponseEndBlock +// HeaderOnlyBlock is a standard [Block] structure where all other fields are +// removed so that hydrating that object from a [Block] bytes payload will +// drastically reduce allocated memory required to hold the full block. +// +// This can be used to unpack a [Block] when only the [Header] information +// is required and greatly reduce required memory. +class HeaderOnlyBlock { + header: Header } -class EventTx { - txResult: TxResult +class Header { + version: Consensus + chainId: string + height: u64 + time: Timestamp + lastBlockId: BlockID + lastCommitHash: Bytes + dataHash: Bytes + validatorsHash: Bytes + nextValidatorsHash: Bytes + consensusHash: Bytes + appHash: Bytes + lastResultsHash: Bytes + evidenceHash: Bytes + proposerAddress: Bytes + hash: Bytes } class TxResult { - height: u64 + height: u64 index: u32 tx: Bytes result: ResponseDeliverTx @@ -134,11 +152,11 @@ class Event { } ``` -The types above are just the general ones that mappings use. You can find the full list of types for the Cosmos Hub integration [here](https://github.com/graphprotocol/graph-ts/blob/main/chain/tendermint.ts). +The types above are just the general ones that mappings use. You can find the full list of types for the Cosmos Hub integration [here](https://github.com/graphprotocol/graph-ts/blob/main/chain/cosmos.ts). Each type of handler will receive a different type based on the relevant data. For both event and transaction handlers, a reference to the block they are contained in is passed as well. These are the exact types that are passed as a parameter to each mapping function: -`EventList` is passed to the blockHandler. +`Block` is passed to the blockHandler. `EventData` is passed to the eventHandler. @@ -160,7 +178,7 @@ $ graph build ## Deploying a Cosmos Hub subgraph -When the subgraph builds successfully, it is time to deploy it to a Graph Node instance for indexing. Cosmos subgraphs can be deployed to any Graph Node on version `>=v0.26.x`. +When the subgraph builds successfully, it is time to deploy it to a Graph Node instance for indexing. Cosmos subgraphs can be deployed to any Graph Node on version `>=v0.26.0`. The first thing to do is create the subgraph in the node, this only has to be done once via the `create` CLI command: @@ -184,8 +202,8 @@ The GraphQL endpoint for Cosmos Hub subgraphs is determined by the schema defini Here are some example subgraphs for reference: -Cosmos Hub Block Subgraph +[Cosmos Hub Block Subgraph](https://github.com/graphprotocol/example-subgraph/tree/cosmos-block-example) -Cosmos Hub Event Subgraph +[Cosmos Hub Event Subgraph](https://github.com/graphprotocol/example-subgraph/tree/cosmos-event-example) -Cosmos Hub Transaction Subgraph +[Cosmos Hub Transaction Subgraph](https://github.com/graphprotocol/example-subgraph/tree/cosmos-transaction-example) diff --git a/pages/ja/supported-networks/cosmos.mdx b/pages/ja/supported-networks/cosmos.mdx new file mode 100644 index 000000000000..05bc2f69935f --- /dev/null +++ b/pages/ja/supported-networks/cosmos.mdx @@ -0,0 +1,209 @@ +--- +title: Building Subgraphs on Cosmos Hub +--- + +This guide is an introduction on building subgraphs indexing the [Cosmos Hub blockchain](https://hub.cosmos.network/). + +## What is Cosmos Hub? + +[Cosmos](https://cosmos.network/) is an ecosystem of blockchains that can scale and interoperate with each other. Cosmos Hub is the first blockchain in the ecosystem. You can visit the [official documentation](https://docs.cosmos.network/) for more information. + +## What are Cosmos subgraphs? + +Cosmos subgraphs are a new type of subgraph that [Graph Node](https://github.com/graphprotocol/graph-node) is now able to process. This allows Cosmos Hub developers to easily index on-chain events into a useful data set, easily available to query via GraphQL. + +There are currently three types of handlers supported for the Cosmos Hub subgraphs: + +- Block handlers. +- [Event](https://docs.cosmos.network/master/core/events.html) handlers. +- [Transaction](https://docs.cosmos.network/master/core/transactions.html) handlers. + +Based on the [official Cosmos documentation](https://docs.cosmos.network/): + +> Events are objects that contain information about the execution of the application. They are mainly used by service providers like block explorers and wallet to track the execution of various messages and index transactions. + +> Transactions are objects created by end-users to trigger state changes in the application. + +## Building a Cosmos Hub subgraph + +### Subgraph Dependencies + +[graph-cli](https://github.com/graphprotocol/graph-cli) is a CLI tool to build and deploy subgraphs, version `>=0.30.0` is required in order to work with Cosmos Hub subgraphs. + +[graph-ts](https://github.com/graphprotocol/graph-ts) is a library of subgraph-specific types, version `>=0.27.0` is required in order to work with Cosmos Hub subgraphs. + +### Subgraph Main Components + +There are three main key parts or files when it comes to defining a subgraph: + +**subgraph.yaml**: a YAML file containing the subgraph manifest, which identifies which events to track and how to process them. + +**schema.graphql**: a GraphQL schema that defines what data is stored for your subgraph, and how to query it via GraphQL. + +**AssemblyScript Mappings**: [AssemblyScript](https://github.com/AssemblyScript/assemblyscript) code that translates from the event data to the entities defined in your schema. + +### Subgraph Manifest Definition + +The subgraph manifest (`subgraph.yaml`) identifies the data sources for the subgraph, the triggers of interest, and the functions that should be run in response to those triggers. See below for an example subgraph manifest for a Cosmos Hub subgraph: + +```yaml +specVersion: 0.0.5 +description: Cosmos Subgraph Example +schema: + file: ./schema.graphql # link to the schema file +dataSources: + - kind: cosmos + network: cosmoshub-4 + source: + startBlock: 0 # Required for Cosmos, set this to 0 to start indexing from chain genesis + mapping: + apiVersion: 0.0.7 + language: wasm/assemblyscript + blockHandlers: + - handler: handleNewBlock # the function name in the mapping file + eventHandlers: + - event: rewards # the type of the event that will be handled + handler: handleReward # the function name in the mapping file + transactionHandlers: + - handler: handleTransaction # the function name in the mapping file + file: ./src/mapping.ts # link to the file with the Assemblyscript mappings +``` + +- Cosmos Hub subgraphs introduce a new `kind` of data source (`cosmos`). +- The `network` should correspond to a network on the hosting Graph Node. Cosmos Hub mainnet is `cosmoshub-4`. Cosmos Hub current testnet is `theta-testnet-001`. Other Cosmos Hub networks, i.e. `cosmoshub-3`, are halted, therefore no data is provided for them. + +Cosmos Hub data sources support three types of handlers: + +- `blockHandlers`: run on every new block appended to the chain. The handler will receive a full block and all its data containing, among other things, all the events and transactions. +- `eventHandlers`: run on every event, except if there is an event type specified in the handler definition, in that case only events of that type are processed. Block data is also passed onto the mapping in order to have context of the event within the chain. +- `transactionHandlers`: run for every transaction executed. The mapping is provided with all the relevant data related to the transaction and a block abstraction that can be used to acquire context of the transaction within a block and within the chain. + +Event and Transaction handlers are a way to process meaningful data from the chain without the need of processing a whole block. The data processed by them can also be found in the block handlers, since events and transactions are also part of a block, but removes the need of processing unnecessary data. + +### Schema Definition + +Schema definition describes the structure of the resulting subgraph database, and the relationships between entities. This is agnostic of the original data source. There are more details on subgraph schema definition [here](https://thegraph.com/docs/en/developer/create-subgraph-hosted/#the-graph-ql-schema). + +### AssemblyScript Mappings + +The handlers for processing events are written in [AssemblyScript](https://www.assemblyscript.org/). + +Cosmos Hub indexing introduces Cosmos-specific data types to the [AssemblyScript API](https://thegraph.com/docs/en/developer/assemblyscript-api/). + +```tsx +class Block { + header: Header + evidence: EvidenceList + resultBeginBlock: ResponseBeginBlock + resultEndBlock: ResponseEndBlock + transactions: Array + validatorUpdates: Array +} + +class EventData { + event: Event + block: HeaderOnlyBlock +} + +class TransactionData { + tx: TxResult + block: HeaderOnlyBlock +} + +// HeaderOnlyBlock is a standard [Block] structure where all other fields are +// removed so that hydrating that object from a [Block] bytes payload will +// drastically reduce allocated memory required to hold the full block. +// +// This can be used to unpack a [Block] when only the [Header] information +// is required and greatly reduce required memory. +class HeaderOnlyBlock { + header: Header +} + +class Header { + version: Consensus + chainId: string + height: u64 + time: Timestamp + lastBlockId: BlockID + lastCommitHash: Bytes + dataHash: Bytes + validatorsHash: Bytes + nextValidatorsHash: Bytes + consensusHash: Bytes + appHash: Bytes + lastResultsHash: Bytes + evidenceHash: Bytes + proposerAddress: Bytes + hash: Bytes +} + +class TxResult { + height: u64 + index: u32 + tx: Bytes + result: ResponseDeliverTx + hash: Bytes +} + +class Event { + eventType: string + attributes: Array +} +``` + +The types above are just the general ones that mappings use. You can find the full list of types for the Cosmos Hub integration [here](https://github.com/graphprotocol/graph-ts/blob/main/chain/cosmos.ts). + +Each type of handler will receive a different type based on the relevant data. For both event and transaction handlers, a reference to the block they are contained in is passed as well. These are the exact types that are passed as a parameter to each mapping function: + +`Block` is passed to the blockHandler. + +`EventData` is passed to the eventHandler. + +`TransactionData` is passed to the transactionHandler. + +## Creating and building a Cosmos Hub subgraph + +The first step before starting to write the subgraph mappings is to generate the type bindings based on the entities that have been defined in the subgraph schema file (`schema.graphql`). This will allow the mapping functions to create new objects of those types and save them to the store. This is done by using the `codegen` CLI command: + +```bash +$ graph codegen +``` + +Once the mappings are ready, the subgraph needs to be built. This step will highlight any errors the manifest or the mappings might have. A subgraph needs to build successfully in order to be deployed to the Graph Node. It can be done using the `build` CLI command: + +```bash +$ graph build +``` + +## Deploying a Cosmos Hub subgraph + +When the subgraph builds successfully, it is time to deploy it to a Graph Node instance for indexing. Cosmos subgraphs can be deployed to any Graph Node on version `>=v0.26.0`. + +The first thing to do is create the subgraph in the node, this only has to be done once via the `create` CLI command: + +```bash +$ graph create subgraph-name --node +``` + +After the subgraph has been created, it can be deployed by using the graph `deploy` CLI command: + +```bash +$ graph deploy subgraph-name --ipfs --node +``` + +Once your subgraph has been deployed, it will be indexed by Graph Node. You can check its progress by querying the subgraph itself at the exposed endpoint. + +## Querying a Cosmos Hub subgraph + +The GraphQL endpoint for Cosmos Hub subgraphs is determined by the schema definition, with the existing API interface. Please visit the [GraphQL API documentation](https://thegraph.com/docs/en/developer/graphql-api/) for more information. + +## Example Subgraphs + +Here are some example subgraphs for reference: + +[Cosmos Hub Block Subgraph](https://github.com/graphprotocol/example-subgraph/tree/cosmos-block-example) + +[Cosmos Hub Event Subgraph](https://github.com/graphprotocol/example-subgraph/tree/cosmos-event-example) + +[Cosmos Hub Transaction Subgraph](https://github.com/graphprotocol/example-subgraph/tree/cosmos-transaction-example) diff --git a/pages/ko/supported-networks/cosmos.mdx b/pages/ko/supported-networks/cosmos.mdx new file mode 100644 index 000000000000..05bc2f69935f --- /dev/null +++ b/pages/ko/supported-networks/cosmos.mdx @@ -0,0 +1,209 @@ +--- +title: Building Subgraphs on Cosmos Hub +--- + +This guide is an introduction on building subgraphs indexing the [Cosmos Hub blockchain](https://hub.cosmos.network/). + +## What is Cosmos Hub? + +[Cosmos](https://cosmos.network/) is an ecosystem of blockchains that can scale and interoperate with each other. Cosmos Hub is the first blockchain in the ecosystem. You can visit the [official documentation](https://docs.cosmos.network/) for more information. + +## What are Cosmos subgraphs? + +Cosmos subgraphs are a new type of subgraph that [Graph Node](https://github.com/graphprotocol/graph-node) is now able to process. This allows Cosmos Hub developers to easily index on-chain events into a useful data set, easily available to query via GraphQL. + +There are currently three types of handlers supported for the Cosmos Hub subgraphs: + +- Block handlers. +- [Event](https://docs.cosmos.network/master/core/events.html) handlers. +- [Transaction](https://docs.cosmos.network/master/core/transactions.html) handlers. + +Based on the [official Cosmos documentation](https://docs.cosmos.network/): + +> Events are objects that contain information about the execution of the application. They are mainly used by service providers like block explorers and wallet to track the execution of various messages and index transactions. + +> Transactions are objects created by end-users to trigger state changes in the application. + +## Building a Cosmos Hub subgraph + +### Subgraph Dependencies + +[graph-cli](https://github.com/graphprotocol/graph-cli) is a CLI tool to build and deploy subgraphs, version `>=0.30.0` is required in order to work with Cosmos Hub subgraphs. + +[graph-ts](https://github.com/graphprotocol/graph-ts) is a library of subgraph-specific types, version `>=0.27.0` is required in order to work with Cosmos Hub subgraphs. + +### Subgraph Main Components + +There are three main key parts or files when it comes to defining a subgraph: + +**subgraph.yaml**: a YAML file containing the subgraph manifest, which identifies which events to track and how to process them. + +**schema.graphql**: a GraphQL schema that defines what data is stored for your subgraph, and how to query it via GraphQL. + +**AssemblyScript Mappings**: [AssemblyScript](https://github.com/AssemblyScript/assemblyscript) code that translates from the event data to the entities defined in your schema. + +### Subgraph Manifest Definition + +The subgraph manifest (`subgraph.yaml`) identifies the data sources for the subgraph, the triggers of interest, and the functions that should be run in response to those triggers. See below for an example subgraph manifest for a Cosmos Hub subgraph: + +```yaml +specVersion: 0.0.5 +description: Cosmos Subgraph Example +schema: + file: ./schema.graphql # link to the schema file +dataSources: + - kind: cosmos + network: cosmoshub-4 + source: + startBlock: 0 # Required for Cosmos, set this to 0 to start indexing from chain genesis + mapping: + apiVersion: 0.0.7 + language: wasm/assemblyscript + blockHandlers: + - handler: handleNewBlock # the function name in the mapping file + eventHandlers: + - event: rewards # the type of the event that will be handled + handler: handleReward # the function name in the mapping file + transactionHandlers: + - handler: handleTransaction # the function name in the mapping file + file: ./src/mapping.ts # link to the file with the Assemblyscript mappings +``` + +- Cosmos Hub subgraphs introduce a new `kind` of data source (`cosmos`). +- The `network` should correspond to a network on the hosting Graph Node. Cosmos Hub mainnet is `cosmoshub-4`. Cosmos Hub current testnet is `theta-testnet-001`. Other Cosmos Hub networks, i.e. `cosmoshub-3`, are halted, therefore no data is provided for them. + +Cosmos Hub data sources support three types of handlers: + +- `blockHandlers`: run on every new block appended to the chain. The handler will receive a full block and all its data containing, among other things, all the events and transactions. +- `eventHandlers`: run on every event, except if there is an event type specified in the handler definition, in that case only events of that type are processed. Block data is also passed onto the mapping in order to have context of the event within the chain. +- `transactionHandlers`: run for every transaction executed. The mapping is provided with all the relevant data related to the transaction and a block abstraction that can be used to acquire context of the transaction within a block and within the chain. + +Event and Transaction handlers are a way to process meaningful data from the chain without the need of processing a whole block. The data processed by them can also be found in the block handlers, since events and transactions are also part of a block, but removes the need of processing unnecessary data. + +### Schema Definition + +Schema definition describes the structure of the resulting subgraph database, and the relationships between entities. This is agnostic of the original data source. There are more details on subgraph schema definition [here](https://thegraph.com/docs/en/developer/create-subgraph-hosted/#the-graph-ql-schema). + +### AssemblyScript Mappings + +The handlers for processing events are written in [AssemblyScript](https://www.assemblyscript.org/). + +Cosmos Hub indexing introduces Cosmos-specific data types to the [AssemblyScript API](https://thegraph.com/docs/en/developer/assemblyscript-api/). + +```tsx +class Block { + header: Header + evidence: EvidenceList + resultBeginBlock: ResponseBeginBlock + resultEndBlock: ResponseEndBlock + transactions: Array + validatorUpdates: Array +} + +class EventData { + event: Event + block: HeaderOnlyBlock +} + +class TransactionData { + tx: TxResult + block: HeaderOnlyBlock +} + +// HeaderOnlyBlock is a standard [Block] structure where all other fields are +// removed so that hydrating that object from a [Block] bytes payload will +// drastically reduce allocated memory required to hold the full block. +// +// This can be used to unpack a [Block] when only the [Header] information +// is required and greatly reduce required memory. +class HeaderOnlyBlock { + header: Header +} + +class Header { + version: Consensus + chainId: string + height: u64 + time: Timestamp + lastBlockId: BlockID + lastCommitHash: Bytes + dataHash: Bytes + validatorsHash: Bytes + nextValidatorsHash: Bytes + consensusHash: Bytes + appHash: Bytes + lastResultsHash: Bytes + evidenceHash: Bytes + proposerAddress: Bytes + hash: Bytes +} + +class TxResult { + height: u64 + index: u32 + tx: Bytes + result: ResponseDeliverTx + hash: Bytes +} + +class Event { + eventType: string + attributes: Array +} +``` + +The types above are just the general ones that mappings use. You can find the full list of types for the Cosmos Hub integration [here](https://github.com/graphprotocol/graph-ts/blob/main/chain/cosmos.ts). + +Each type of handler will receive a different type based on the relevant data. For both event and transaction handlers, a reference to the block they are contained in is passed as well. These are the exact types that are passed as a parameter to each mapping function: + +`Block` is passed to the blockHandler. + +`EventData` is passed to the eventHandler. + +`TransactionData` is passed to the transactionHandler. + +## Creating and building a Cosmos Hub subgraph + +The first step before starting to write the subgraph mappings is to generate the type bindings based on the entities that have been defined in the subgraph schema file (`schema.graphql`). This will allow the mapping functions to create new objects of those types and save them to the store. This is done by using the `codegen` CLI command: + +```bash +$ graph codegen +``` + +Once the mappings are ready, the subgraph needs to be built. This step will highlight any errors the manifest or the mappings might have. A subgraph needs to build successfully in order to be deployed to the Graph Node. It can be done using the `build` CLI command: + +```bash +$ graph build +``` + +## Deploying a Cosmos Hub subgraph + +When the subgraph builds successfully, it is time to deploy it to a Graph Node instance for indexing. Cosmos subgraphs can be deployed to any Graph Node on version `>=v0.26.0`. + +The first thing to do is create the subgraph in the node, this only has to be done once via the `create` CLI command: + +```bash +$ graph create subgraph-name --node +``` + +After the subgraph has been created, it can be deployed by using the graph `deploy` CLI command: + +```bash +$ graph deploy subgraph-name --ipfs --node +``` + +Once your subgraph has been deployed, it will be indexed by Graph Node. You can check its progress by querying the subgraph itself at the exposed endpoint. + +## Querying a Cosmos Hub subgraph + +The GraphQL endpoint for Cosmos Hub subgraphs is determined by the schema definition, with the existing API interface. Please visit the [GraphQL API documentation](https://thegraph.com/docs/en/developer/graphql-api/) for more information. + +## Example Subgraphs + +Here are some example subgraphs for reference: + +[Cosmos Hub Block Subgraph](https://github.com/graphprotocol/example-subgraph/tree/cosmos-block-example) + +[Cosmos Hub Event Subgraph](https://github.com/graphprotocol/example-subgraph/tree/cosmos-event-example) + +[Cosmos Hub Transaction Subgraph](https://github.com/graphprotocol/example-subgraph/tree/cosmos-transaction-example) diff --git a/pages/vi/supported-networks/cosmos.mdx b/pages/vi/supported-networks/cosmos.mdx new file mode 100644 index 000000000000..05bc2f69935f --- /dev/null +++ b/pages/vi/supported-networks/cosmos.mdx @@ -0,0 +1,209 @@ +--- +title: Building Subgraphs on Cosmos Hub +--- + +This guide is an introduction on building subgraphs indexing the [Cosmos Hub blockchain](https://hub.cosmos.network/). + +## What is Cosmos Hub? + +[Cosmos](https://cosmos.network/) is an ecosystem of blockchains that can scale and interoperate with each other. Cosmos Hub is the first blockchain in the ecosystem. You can visit the [official documentation](https://docs.cosmos.network/) for more information. + +## What are Cosmos subgraphs? + +Cosmos subgraphs are a new type of subgraph that [Graph Node](https://github.com/graphprotocol/graph-node) is now able to process. This allows Cosmos Hub developers to easily index on-chain events into a useful data set, easily available to query via GraphQL. + +There are currently three types of handlers supported for the Cosmos Hub subgraphs: + +- Block handlers. +- [Event](https://docs.cosmos.network/master/core/events.html) handlers. +- [Transaction](https://docs.cosmos.network/master/core/transactions.html) handlers. + +Based on the [official Cosmos documentation](https://docs.cosmos.network/): + +> Events are objects that contain information about the execution of the application. They are mainly used by service providers like block explorers and wallet to track the execution of various messages and index transactions. + +> Transactions are objects created by end-users to trigger state changes in the application. + +## Building a Cosmos Hub subgraph + +### Subgraph Dependencies + +[graph-cli](https://github.com/graphprotocol/graph-cli) is a CLI tool to build and deploy subgraphs, version `>=0.30.0` is required in order to work with Cosmos Hub subgraphs. + +[graph-ts](https://github.com/graphprotocol/graph-ts) is a library of subgraph-specific types, version `>=0.27.0` is required in order to work with Cosmos Hub subgraphs. + +### Subgraph Main Components + +There are three main key parts or files when it comes to defining a subgraph: + +**subgraph.yaml**: a YAML file containing the subgraph manifest, which identifies which events to track and how to process them. + +**schema.graphql**: a GraphQL schema that defines what data is stored for your subgraph, and how to query it via GraphQL. + +**AssemblyScript Mappings**: [AssemblyScript](https://github.com/AssemblyScript/assemblyscript) code that translates from the event data to the entities defined in your schema. + +### Subgraph Manifest Definition + +The subgraph manifest (`subgraph.yaml`) identifies the data sources for the subgraph, the triggers of interest, and the functions that should be run in response to those triggers. See below for an example subgraph manifest for a Cosmos Hub subgraph: + +```yaml +specVersion: 0.0.5 +description: Cosmos Subgraph Example +schema: + file: ./schema.graphql # link to the schema file +dataSources: + - kind: cosmos + network: cosmoshub-4 + source: + startBlock: 0 # Required for Cosmos, set this to 0 to start indexing from chain genesis + mapping: + apiVersion: 0.0.7 + language: wasm/assemblyscript + blockHandlers: + - handler: handleNewBlock # the function name in the mapping file + eventHandlers: + - event: rewards # the type of the event that will be handled + handler: handleReward # the function name in the mapping file + transactionHandlers: + - handler: handleTransaction # the function name in the mapping file + file: ./src/mapping.ts # link to the file with the Assemblyscript mappings +``` + +- Cosmos Hub subgraphs introduce a new `kind` of data source (`cosmos`). +- The `network` should correspond to a network on the hosting Graph Node. Cosmos Hub mainnet is `cosmoshub-4`. Cosmos Hub current testnet is `theta-testnet-001`. Other Cosmos Hub networks, i.e. `cosmoshub-3`, are halted, therefore no data is provided for them. + +Cosmos Hub data sources support three types of handlers: + +- `blockHandlers`: run on every new block appended to the chain. The handler will receive a full block and all its data containing, among other things, all the events and transactions. +- `eventHandlers`: run on every event, except if there is an event type specified in the handler definition, in that case only events of that type are processed. Block data is also passed onto the mapping in order to have context of the event within the chain. +- `transactionHandlers`: run for every transaction executed. The mapping is provided with all the relevant data related to the transaction and a block abstraction that can be used to acquire context of the transaction within a block and within the chain. + +Event and Transaction handlers are a way to process meaningful data from the chain without the need of processing a whole block. The data processed by them can also be found in the block handlers, since events and transactions are also part of a block, but removes the need of processing unnecessary data. + +### Schema Definition + +Schema definition describes the structure of the resulting subgraph database, and the relationships between entities. This is agnostic of the original data source. There are more details on subgraph schema definition [here](https://thegraph.com/docs/en/developer/create-subgraph-hosted/#the-graph-ql-schema). + +### AssemblyScript Mappings + +The handlers for processing events are written in [AssemblyScript](https://www.assemblyscript.org/). + +Cosmos Hub indexing introduces Cosmos-specific data types to the [AssemblyScript API](https://thegraph.com/docs/en/developer/assemblyscript-api/). + +```tsx +class Block { + header: Header + evidence: EvidenceList + resultBeginBlock: ResponseBeginBlock + resultEndBlock: ResponseEndBlock + transactions: Array + validatorUpdates: Array +} + +class EventData { + event: Event + block: HeaderOnlyBlock +} + +class TransactionData { + tx: TxResult + block: HeaderOnlyBlock +} + +// HeaderOnlyBlock is a standard [Block] structure where all other fields are +// removed so that hydrating that object from a [Block] bytes payload will +// drastically reduce allocated memory required to hold the full block. +// +// This can be used to unpack a [Block] when only the [Header] information +// is required and greatly reduce required memory. +class HeaderOnlyBlock { + header: Header +} + +class Header { + version: Consensus + chainId: string + height: u64 + time: Timestamp + lastBlockId: BlockID + lastCommitHash: Bytes + dataHash: Bytes + validatorsHash: Bytes + nextValidatorsHash: Bytes + consensusHash: Bytes + appHash: Bytes + lastResultsHash: Bytes + evidenceHash: Bytes + proposerAddress: Bytes + hash: Bytes +} + +class TxResult { + height: u64 + index: u32 + tx: Bytes + result: ResponseDeliverTx + hash: Bytes +} + +class Event { + eventType: string + attributes: Array +} +``` + +The types above are just the general ones that mappings use. You can find the full list of types for the Cosmos Hub integration [here](https://github.com/graphprotocol/graph-ts/blob/main/chain/cosmos.ts). + +Each type of handler will receive a different type based on the relevant data. For both event and transaction handlers, a reference to the block they are contained in is passed as well. These are the exact types that are passed as a parameter to each mapping function: + +`Block` is passed to the blockHandler. + +`EventData` is passed to the eventHandler. + +`TransactionData` is passed to the transactionHandler. + +## Creating and building a Cosmos Hub subgraph + +The first step before starting to write the subgraph mappings is to generate the type bindings based on the entities that have been defined in the subgraph schema file (`schema.graphql`). This will allow the mapping functions to create new objects of those types and save them to the store. This is done by using the `codegen` CLI command: + +```bash +$ graph codegen +``` + +Once the mappings are ready, the subgraph needs to be built. This step will highlight any errors the manifest or the mappings might have. A subgraph needs to build successfully in order to be deployed to the Graph Node. It can be done using the `build` CLI command: + +```bash +$ graph build +``` + +## Deploying a Cosmos Hub subgraph + +When the subgraph builds successfully, it is time to deploy it to a Graph Node instance for indexing. Cosmos subgraphs can be deployed to any Graph Node on version `>=v0.26.0`. + +The first thing to do is create the subgraph in the node, this only has to be done once via the `create` CLI command: + +```bash +$ graph create subgraph-name --node +``` + +After the subgraph has been created, it can be deployed by using the graph `deploy` CLI command: + +```bash +$ graph deploy subgraph-name --ipfs --node +``` + +Once your subgraph has been deployed, it will be indexed by Graph Node. You can check its progress by querying the subgraph itself at the exposed endpoint. + +## Querying a Cosmos Hub subgraph + +The GraphQL endpoint for Cosmos Hub subgraphs is determined by the schema definition, with the existing API interface. Please visit the [GraphQL API documentation](https://thegraph.com/docs/en/developer/graphql-api/) for more information. + +## Example Subgraphs + +Here are some example subgraphs for reference: + +[Cosmos Hub Block Subgraph](https://github.com/graphprotocol/example-subgraph/tree/cosmos-block-example) + +[Cosmos Hub Event Subgraph](https://github.com/graphprotocol/example-subgraph/tree/cosmos-event-example) + +[Cosmos Hub Transaction Subgraph](https://github.com/graphprotocol/example-subgraph/tree/cosmos-transaction-example) diff --git a/pages/zh/supported-networks/cosmos.mdx b/pages/zh/supported-networks/cosmos.mdx new file mode 100644 index 000000000000..05bc2f69935f --- /dev/null +++ b/pages/zh/supported-networks/cosmos.mdx @@ -0,0 +1,209 @@ +--- +title: Building Subgraphs on Cosmos Hub +--- + +This guide is an introduction on building subgraphs indexing the [Cosmos Hub blockchain](https://hub.cosmos.network/). + +## What is Cosmos Hub? + +[Cosmos](https://cosmos.network/) is an ecosystem of blockchains that can scale and interoperate with each other. Cosmos Hub is the first blockchain in the ecosystem. You can visit the [official documentation](https://docs.cosmos.network/) for more information. + +## What are Cosmos subgraphs? + +Cosmos subgraphs are a new type of subgraph that [Graph Node](https://github.com/graphprotocol/graph-node) is now able to process. This allows Cosmos Hub developers to easily index on-chain events into a useful data set, easily available to query via GraphQL. + +There are currently three types of handlers supported for the Cosmos Hub subgraphs: + +- Block handlers. +- [Event](https://docs.cosmos.network/master/core/events.html) handlers. +- [Transaction](https://docs.cosmos.network/master/core/transactions.html) handlers. + +Based on the [official Cosmos documentation](https://docs.cosmos.network/): + +> Events are objects that contain information about the execution of the application. They are mainly used by service providers like block explorers and wallet to track the execution of various messages and index transactions. + +> Transactions are objects created by end-users to trigger state changes in the application. + +## Building a Cosmos Hub subgraph + +### Subgraph Dependencies + +[graph-cli](https://github.com/graphprotocol/graph-cli) is a CLI tool to build and deploy subgraphs, version `>=0.30.0` is required in order to work with Cosmos Hub subgraphs. + +[graph-ts](https://github.com/graphprotocol/graph-ts) is a library of subgraph-specific types, version `>=0.27.0` is required in order to work with Cosmos Hub subgraphs. + +### Subgraph Main Components + +There are three main key parts or files when it comes to defining a subgraph: + +**subgraph.yaml**: a YAML file containing the subgraph manifest, which identifies which events to track and how to process them. + +**schema.graphql**: a GraphQL schema that defines what data is stored for your subgraph, and how to query it via GraphQL. + +**AssemblyScript Mappings**: [AssemblyScript](https://github.com/AssemblyScript/assemblyscript) code that translates from the event data to the entities defined in your schema. + +### Subgraph Manifest Definition + +The subgraph manifest (`subgraph.yaml`) identifies the data sources for the subgraph, the triggers of interest, and the functions that should be run in response to those triggers. See below for an example subgraph manifest for a Cosmos Hub subgraph: + +```yaml +specVersion: 0.0.5 +description: Cosmos Subgraph Example +schema: + file: ./schema.graphql # link to the schema file +dataSources: + - kind: cosmos + network: cosmoshub-4 + source: + startBlock: 0 # Required for Cosmos, set this to 0 to start indexing from chain genesis + mapping: + apiVersion: 0.0.7 + language: wasm/assemblyscript + blockHandlers: + - handler: handleNewBlock # the function name in the mapping file + eventHandlers: + - event: rewards # the type of the event that will be handled + handler: handleReward # the function name in the mapping file + transactionHandlers: + - handler: handleTransaction # the function name in the mapping file + file: ./src/mapping.ts # link to the file with the Assemblyscript mappings +``` + +- Cosmos Hub subgraphs introduce a new `kind` of data source (`cosmos`). +- The `network` should correspond to a network on the hosting Graph Node. Cosmos Hub mainnet is `cosmoshub-4`. Cosmos Hub current testnet is `theta-testnet-001`. Other Cosmos Hub networks, i.e. `cosmoshub-3`, are halted, therefore no data is provided for them. + +Cosmos Hub data sources support three types of handlers: + +- `blockHandlers`: run on every new block appended to the chain. The handler will receive a full block and all its data containing, among other things, all the events and transactions. +- `eventHandlers`: run on every event, except if there is an event type specified in the handler definition, in that case only events of that type are processed. Block data is also passed onto the mapping in order to have context of the event within the chain. +- `transactionHandlers`: run for every transaction executed. The mapping is provided with all the relevant data related to the transaction and a block abstraction that can be used to acquire context of the transaction within a block and within the chain. + +Event and Transaction handlers are a way to process meaningful data from the chain without the need of processing a whole block. The data processed by them can also be found in the block handlers, since events and transactions are also part of a block, but removes the need of processing unnecessary data. + +### Schema Definition + +Schema definition describes the structure of the resulting subgraph database, and the relationships between entities. This is agnostic of the original data source. There are more details on subgraph schema definition [here](https://thegraph.com/docs/en/developer/create-subgraph-hosted/#the-graph-ql-schema). + +### AssemblyScript Mappings + +The handlers for processing events are written in [AssemblyScript](https://www.assemblyscript.org/). + +Cosmos Hub indexing introduces Cosmos-specific data types to the [AssemblyScript API](https://thegraph.com/docs/en/developer/assemblyscript-api/). + +```tsx +class Block { + header: Header + evidence: EvidenceList + resultBeginBlock: ResponseBeginBlock + resultEndBlock: ResponseEndBlock + transactions: Array + validatorUpdates: Array +} + +class EventData { + event: Event + block: HeaderOnlyBlock +} + +class TransactionData { + tx: TxResult + block: HeaderOnlyBlock +} + +// HeaderOnlyBlock is a standard [Block] structure where all other fields are +// removed so that hydrating that object from a [Block] bytes payload will +// drastically reduce allocated memory required to hold the full block. +// +// This can be used to unpack a [Block] when only the [Header] information +// is required and greatly reduce required memory. +class HeaderOnlyBlock { + header: Header +} + +class Header { + version: Consensus + chainId: string + height: u64 + time: Timestamp + lastBlockId: BlockID + lastCommitHash: Bytes + dataHash: Bytes + validatorsHash: Bytes + nextValidatorsHash: Bytes + consensusHash: Bytes + appHash: Bytes + lastResultsHash: Bytes + evidenceHash: Bytes + proposerAddress: Bytes + hash: Bytes +} + +class TxResult { + height: u64 + index: u32 + tx: Bytes + result: ResponseDeliverTx + hash: Bytes +} + +class Event { + eventType: string + attributes: Array +} +``` + +The types above are just the general ones that mappings use. You can find the full list of types for the Cosmos Hub integration [here](https://github.com/graphprotocol/graph-ts/blob/main/chain/cosmos.ts). + +Each type of handler will receive a different type based on the relevant data. For both event and transaction handlers, a reference to the block they are contained in is passed as well. These are the exact types that are passed as a parameter to each mapping function: + +`Block` is passed to the blockHandler. + +`EventData` is passed to the eventHandler. + +`TransactionData` is passed to the transactionHandler. + +## Creating and building a Cosmos Hub subgraph + +The first step before starting to write the subgraph mappings is to generate the type bindings based on the entities that have been defined in the subgraph schema file (`schema.graphql`). This will allow the mapping functions to create new objects of those types and save them to the store. This is done by using the `codegen` CLI command: + +```bash +$ graph codegen +``` + +Once the mappings are ready, the subgraph needs to be built. This step will highlight any errors the manifest or the mappings might have. A subgraph needs to build successfully in order to be deployed to the Graph Node. It can be done using the `build` CLI command: + +```bash +$ graph build +``` + +## Deploying a Cosmos Hub subgraph + +When the subgraph builds successfully, it is time to deploy it to a Graph Node instance for indexing. Cosmos subgraphs can be deployed to any Graph Node on version `>=v0.26.0`. + +The first thing to do is create the subgraph in the node, this only has to be done once via the `create` CLI command: + +```bash +$ graph create subgraph-name --node +``` + +After the subgraph has been created, it can be deployed by using the graph `deploy` CLI command: + +```bash +$ graph deploy subgraph-name --ipfs --node +``` + +Once your subgraph has been deployed, it will be indexed by Graph Node. You can check its progress by querying the subgraph itself at the exposed endpoint. + +## Querying a Cosmos Hub subgraph + +The GraphQL endpoint for Cosmos Hub subgraphs is determined by the schema definition, with the existing API interface. Please visit the [GraphQL API documentation](https://thegraph.com/docs/en/developer/graphql-api/) for more information. + +## Example Subgraphs + +Here are some example subgraphs for reference: + +[Cosmos Hub Block Subgraph](https://github.com/graphprotocol/example-subgraph/tree/cosmos-block-example) + +[Cosmos Hub Event Subgraph](https://github.com/graphprotocol/example-subgraph/tree/cosmos-event-example) + +[Cosmos Hub Transaction Subgraph](https://github.com/graphprotocol/example-subgraph/tree/cosmos-transaction-example) From 0b426d9c3f6d6af981fe52defe012a18ad9c87e7 Mon Sep 17 00:00:00 2001 From: Marc Puig Date: Tue, 24 May 2022 11:43:44 +0200 Subject: [PATCH 03/13] Remove translated pages --- pages/ar/supported-networks/cosmos.mdx | 209 ------------------------- pages/es/supported-networks/cosmos.mdx | 209 ------------------------- pages/ja/supported-networks/cosmos.mdx | 209 ------------------------- pages/ko/supported-networks/cosmos.mdx | 209 ------------------------- pages/vi/supported-networks/cosmos.mdx | 209 ------------------------- pages/zh/supported-networks/cosmos.mdx | 209 ------------------------- 6 files changed, 1254 deletions(-) delete mode 100644 pages/ar/supported-networks/cosmos.mdx delete mode 100644 pages/es/supported-networks/cosmos.mdx delete mode 100644 pages/ja/supported-networks/cosmos.mdx delete mode 100644 pages/ko/supported-networks/cosmos.mdx delete mode 100644 pages/vi/supported-networks/cosmos.mdx delete mode 100644 pages/zh/supported-networks/cosmos.mdx diff --git a/pages/ar/supported-networks/cosmos.mdx b/pages/ar/supported-networks/cosmos.mdx deleted file mode 100644 index 05bc2f69935f..000000000000 --- a/pages/ar/supported-networks/cosmos.mdx +++ /dev/null @@ -1,209 +0,0 @@ ---- -title: Building Subgraphs on Cosmos Hub ---- - -This guide is an introduction on building subgraphs indexing the [Cosmos Hub blockchain](https://hub.cosmos.network/). - -## What is Cosmos Hub? - -[Cosmos](https://cosmos.network/) is an ecosystem of blockchains that can scale and interoperate with each other. Cosmos Hub is the first blockchain in the ecosystem. You can visit the [official documentation](https://docs.cosmos.network/) for more information. - -## What are Cosmos subgraphs? - -Cosmos subgraphs are a new type of subgraph that [Graph Node](https://github.com/graphprotocol/graph-node) is now able to process. This allows Cosmos Hub developers to easily index on-chain events into a useful data set, easily available to query via GraphQL. - -There are currently three types of handlers supported for the Cosmos Hub subgraphs: - -- Block handlers. -- [Event](https://docs.cosmos.network/master/core/events.html) handlers. -- [Transaction](https://docs.cosmos.network/master/core/transactions.html) handlers. - -Based on the [official Cosmos documentation](https://docs.cosmos.network/): - -> Events are objects that contain information about the execution of the application. They are mainly used by service providers like block explorers and wallet to track the execution of various messages and index transactions. - -> Transactions are objects created by end-users to trigger state changes in the application. - -## Building a Cosmos Hub subgraph - -### Subgraph Dependencies - -[graph-cli](https://github.com/graphprotocol/graph-cli) is a CLI tool to build and deploy subgraphs, version `>=0.30.0` is required in order to work with Cosmos Hub subgraphs. - -[graph-ts](https://github.com/graphprotocol/graph-ts) is a library of subgraph-specific types, version `>=0.27.0` is required in order to work with Cosmos Hub subgraphs. - -### Subgraph Main Components - -There are three main key parts or files when it comes to defining a subgraph: - -**subgraph.yaml**: a YAML file containing the subgraph manifest, which identifies which events to track and how to process them. - -**schema.graphql**: a GraphQL schema that defines what data is stored for your subgraph, and how to query it via GraphQL. - -**AssemblyScript Mappings**: [AssemblyScript](https://github.com/AssemblyScript/assemblyscript) code that translates from the event data to the entities defined in your schema. - -### Subgraph Manifest Definition - -The subgraph manifest (`subgraph.yaml`) identifies the data sources for the subgraph, the triggers of interest, and the functions that should be run in response to those triggers. See below for an example subgraph manifest for a Cosmos Hub subgraph: - -```yaml -specVersion: 0.0.5 -description: Cosmos Subgraph Example -schema: - file: ./schema.graphql # link to the schema file -dataSources: - - kind: cosmos - network: cosmoshub-4 - source: - startBlock: 0 # Required for Cosmos, set this to 0 to start indexing from chain genesis - mapping: - apiVersion: 0.0.7 - language: wasm/assemblyscript - blockHandlers: - - handler: handleNewBlock # the function name in the mapping file - eventHandlers: - - event: rewards # the type of the event that will be handled - handler: handleReward # the function name in the mapping file - transactionHandlers: - - handler: handleTransaction # the function name in the mapping file - file: ./src/mapping.ts # link to the file with the Assemblyscript mappings -``` - -- Cosmos Hub subgraphs introduce a new `kind` of data source (`cosmos`). -- The `network` should correspond to a network on the hosting Graph Node. Cosmos Hub mainnet is `cosmoshub-4`. Cosmos Hub current testnet is `theta-testnet-001`. Other Cosmos Hub networks, i.e. `cosmoshub-3`, are halted, therefore no data is provided for them. - -Cosmos Hub data sources support three types of handlers: - -- `blockHandlers`: run on every new block appended to the chain. The handler will receive a full block and all its data containing, among other things, all the events and transactions. -- `eventHandlers`: run on every event, except if there is an event type specified in the handler definition, in that case only events of that type are processed. Block data is also passed onto the mapping in order to have context of the event within the chain. -- `transactionHandlers`: run for every transaction executed. The mapping is provided with all the relevant data related to the transaction and a block abstraction that can be used to acquire context of the transaction within a block and within the chain. - -Event and Transaction handlers are a way to process meaningful data from the chain without the need of processing a whole block. The data processed by them can also be found in the block handlers, since events and transactions are also part of a block, but removes the need of processing unnecessary data. - -### Schema Definition - -Schema definition describes the structure of the resulting subgraph database, and the relationships between entities. This is agnostic of the original data source. There are more details on subgraph schema definition [here](https://thegraph.com/docs/en/developer/create-subgraph-hosted/#the-graph-ql-schema). - -### AssemblyScript Mappings - -The handlers for processing events are written in [AssemblyScript](https://www.assemblyscript.org/). - -Cosmos Hub indexing introduces Cosmos-specific data types to the [AssemblyScript API](https://thegraph.com/docs/en/developer/assemblyscript-api/). - -```tsx -class Block { - header: Header - evidence: EvidenceList - resultBeginBlock: ResponseBeginBlock - resultEndBlock: ResponseEndBlock - transactions: Array - validatorUpdates: Array -} - -class EventData { - event: Event - block: HeaderOnlyBlock -} - -class TransactionData { - tx: TxResult - block: HeaderOnlyBlock -} - -// HeaderOnlyBlock is a standard [Block] structure where all other fields are -// removed so that hydrating that object from a [Block] bytes payload will -// drastically reduce allocated memory required to hold the full block. -// -// This can be used to unpack a [Block] when only the [Header] information -// is required and greatly reduce required memory. -class HeaderOnlyBlock { - header: Header -} - -class Header { - version: Consensus - chainId: string - height: u64 - time: Timestamp - lastBlockId: BlockID - lastCommitHash: Bytes - dataHash: Bytes - validatorsHash: Bytes - nextValidatorsHash: Bytes - consensusHash: Bytes - appHash: Bytes - lastResultsHash: Bytes - evidenceHash: Bytes - proposerAddress: Bytes - hash: Bytes -} - -class TxResult { - height: u64 - index: u32 - tx: Bytes - result: ResponseDeliverTx - hash: Bytes -} - -class Event { - eventType: string - attributes: Array -} -``` - -The types above are just the general ones that mappings use. You can find the full list of types for the Cosmos Hub integration [here](https://github.com/graphprotocol/graph-ts/blob/main/chain/cosmos.ts). - -Each type of handler will receive a different type based on the relevant data. For both event and transaction handlers, a reference to the block they are contained in is passed as well. These are the exact types that are passed as a parameter to each mapping function: - -`Block` is passed to the blockHandler. - -`EventData` is passed to the eventHandler. - -`TransactionData` is passed to the transactionHandler. - -## Creating and building a Cosmos Hub subgraph - -The first step before starting to write the subgraph mappings is to generate the type bindings based on the entities that have been defined in the subgraph schema file (`schema.graphql`). This will allow the mapping functions to create new objects of those types and save them to the store. This is done by using the `codegen` CLI command: - -```bash -$ graph codegen -``` - -Once the mappings are ready, the subgraph needs to be built. This step will highlight any errors the manifest or the mappings might have. A subgraph needs to build successfully in order to be deployed to the Graph Node. It can be done using the `build` CLI command: - -```bash -$ graph build -``` - -## Deploying a Cosmos Hub subgraph - -When the subgraph builds successfully, it is time to deploy it to a Graph Node instance for indexing. Cosmos subgraphs can be deployed to any Graph Node on version `>=v0.26.0`. - -The first thing to do is create the subgraph in the node, this only has to be done once via the `create` CLI command: - -```bash -$ graph create subgraph-name --node -``` - -After the subgraph has been created, it can be deployed by using the graph `deploy` CLI command: - -```bash -$ graph deploy subgraph-name --ipfs --node -``` - -Once your subgraph has been deployed, it will be indexed by Graph Node. You can check its progress by querying the subgraph itself at the exposed endpoint. - -## Querying a Cosmos Hub subgraph - -The GraphQL endpoint for Cosmos Hub subgraphs is determined by the schema definition, with the existing API interface. Please visit the [GraphQL API documentation](https://thegraph.com/docs/en/developer/graphql-api/) for more information. - -## Example Subgraphs - -Here are some example subgraphs for reference: - -[Cosmos Hub Block Subgraph](https://github.com/graphprotocol/example-subgraph/tree/cosmos-block-example) - -[Cosmos Hub Event Subgraph](https://github.com/graphprotocol/example-subgraph/tree/cosmos-event-example) - -[Cosmos Hub Transaction Subgraph](https://github.com/graphprotocol/example-subgraph/tree/cosmos-transaction-example) diff --git a/pages/es/supported-networks/cosmos.mdx b/pages/es/supported-networks/cosmos.mdx deleted file mode 100644 index 05bc2f69935f..000000000000 --- a/pages/es/supported-networks/cosmos.mdx +++ /dev/null @@ -1,209 +0,0 @@ ---- -title: Building Subgraphs on Cosmos Hub ---- - -This guide is an introduction on building subgraphs indexing the [Cosmos Hub blockchain](https://hub.cosmos.network/). - -## What is Cosmos Hub? - -[Cosmos](https://cosmos.network/) is an ecosystem of blockchains that can scale and interoperate with each other. Cosmos Hub is the first blockchain in the ecosystem. You can visit the [official documentation](https://docs.cosmos.network/) for more information. - -## What are Cosmos subgraphs? - -Cosmos subgraphs are a new type of subgraph that [Graph Node](https://github.com/graphprotocol/graph-node) is now able to process. This allows Cosmos Hub developers to easily index on-chain events into a useful data set, easily available to query via GraphQL. - -There are currently three types of handlers supported for the Cosmos Hub subgraphs: - -- Block handlers. -- [Event](https://docs.cosmos.network/master/core/events.html) handlers. -- [Transaction](https://docs.cosmos.network/master/core/transactions.html) handlers. - -Based on the [official Cosmos documentation](https://docs.cosmos.network/): - -> Events are objects that contain information about the execution of the application. They are mainly used by service providers like block explorers and wallet to track the execution of various messages and index transactions. - -> Transactions are objects created by end-users to trigger state changes in the application. - -## Building a Cosmos Hub subgraph - -### Subgraph Dependencies - -[graph-cli](https://github.com/graphprotocol/graph-cli) is a CLI tool to build and deploy subgraphs, version `>=0.30.0` is required in order to work with Cosmos Hub subgraphs. - -[graph-ts](https://github.com/graphprotocol/graph-ts) is a library of subgraph-specific types, version `>=0.27.0` is required in order to work with Cosmos Hub subgraphs. - -### Subgraph Main Components - -There are three main key parts or files when it comes to defining a subgraph: - -**subgraph.yaml**: a YAML file containing the subgraph manifest, which identifies which events to track and how to process them. - -**schema.graphql**: a GraphQL schema that defines what data is stored for your subgraph, and how to query it via GraphQL. - -**AssemblyScript Mappings**: [AssemblyScript](https://github.com/AssemblyScript/assemblyscript) code that translates from the event data to the entities defined in your schema. - -### Subgraph Manifest Definition - -The subgraph manifest (`subgraph.yaml`) identifies the data sources for the subgraph, the triggers of interest, and the functions that should be run in response to those triggers. See below for an example subgraph manifest for a Cosmos Hub subgraph: - -```yaml -specVersion: 0.0.5 -description: Cosmos Subgraph Example -schema: - file: ./schema.graphql # link to the schema file -dataSources: - - kind: cosmos - network: cosmoshub-4 - source: - startBlock: 0 # Required for Cosmos, set this to 0 to start indexing from chain genesis - mapping: - apiVersion: 0.0.7 - language: wasm/assemblyscript - blockHandlers: - - handler: handleNewBlock # the function name in the mapping file - eventHandlers: - - event: rewards # the type of the event that will be handled - handler: handleReward # the function name in the mapping file - transactionHandlers: - - handler: handleTransaction # the function name in the mapping file - file: ./src/mapping.ts # link to the file with the Assemblyscript mappings -``` - -- Cosmos Hub subgraphs introduce a new `kind` of data source (`cosmos`). -- The `network` should correspond to a network on the hosting Graph Node. Cosmos Hub mainnet is `cosmoshub-4`. Cosmos Hub current testnet is `theta-testnet-001`. Other Cosmos Hub networks, i.e. `cosmoshub-3`, are halted, therefore no data is provided for them. - -Cosmos Hub data sources support three types of handlers: - -- `blockHandlers`: run on every new block appended to the chain. The handler will receive a full block and all its data containing, among other things, all the events and transactions. -- `eventHandlers`: run on every event, except if there is an event type specified in the handler definition, in that case only events of that type are processed. Block data is also passed onto the mapping in order to have context of the event within the chain. -- `transactionHandlers`: run for every transaction executed. The mapping is provided with all the relevant data related to the transaction and a block abstraction that can be used to acquire context of the transaction within a block and within the chain. - -Event and Transaction handlers are a way to process meaningful data from the chain without the need of processing a whole block. The data processed by them can also be found in the block handlers, since events and transactions are also part of a block, but removes the need of processing unnecessary data. - -### Schema Definition - -Schema definition describes the structure of the resulting subgraph database, and the relationships between entities. This is agnostic of the original data source. There are more details on subgraph schema definition [here](https://thegraph.com/docs/en/developer/create-subgraph-hosted/#the-graph-ql-schema). - -### AssemblyScript Mappings - -The handlers for processing events are written in [AssemblyScript](https://www.assemblyscript.org/). - -Cosmos Hub indexing introduces Cosmos-specific data types to the [AssemblyScript API](https://thegraph.com/docs/en/developer/assemblyscript-api/). - -```tsx -class Block { - header: Header - evidence: EvidenceList - resultBeginBlock: ResponseBeginBlock - resultEndBlock: ResponseEndBlock - transactions: Array - validatorUpdates: Array -} - -class EventData { - event: Event - block: HeaderOnlyBlock -} - -class TransactionData { - tx: TxResult - block: HeaderOnlyBlock -} - -// HeaderOnlyBlock is a standard [Block] structure where all other fields are -// removed so that hydrating that object from a [Block] bytes payload will -// drastically reduce allocated memory required to hold the full block. -// -// This can be used to unpack a [Block] when only the [Header] information -// is required and greatly reduce required memory. -class HeaderOnlyBlock { - header: Header -} - -class Header { - version: Consensus - chainId: string - height: u64 - time: Timestamp - lastBlockId: BlockID - lastCommitHash: Bytes - dataHash: Bytes - validatorsHash: Bytes - nextValidatorsHash: Bytes - consensusHash: Bytes - appHash: Bytes - lastResultsHash: Bytes - evidenceHash: Bytes - proposerAddress: Bytes - hash: Bytes -} - -class TxResult { - height: u64 - index: u32 - tx: Bytes - result: ResponseDeliverTx - hash: Bytes -} - -class Event { - eventType: string - attributes: Array -} -``` - -The types above are just the general ones that mappings use. You can find the full list of types for the Cosmos Hub integration [here](https://github.com/graphprotocol/graph-ts/blob/main/chain/cosmos.ts). - -Each type of handler will receive a different type based on the relevant data. For both event and transaction handlers, a reference to the block they are contained in is passed as well. These are the exact types that are passed as a parameter to each mapping function: - -`Block` is passed to the blockHandler. - -`EventData` is passed to the eventHandler. - -`TransactionData` is passed to the transactionHandler. - -## Creating and building a Cosmos Hub subgraph - -The first step before starting to write the subgraph mappings is to generate the type bindings based on the entities that have been defined in the subgraph schema file (`schema.graphql`). This will allow the mapping functions to create new objects of those types and save them to the store. This is done by using the `codegen` CLI command: - -```bash -$ graph codegen -``` - -Once the mappings are ready, the subgraph needs to be built. This step will highlight any errors the manifest or the mappings might have. A subgraph needs to build successfully in order to be deployed to the Graph Node. It can be done using the `build` CLI command: - -```bash -$ graph build -``` - -## Deploying a Cosmos Hub subgraph - -When the subgraph builds successfully, it is time to deploy it to a Graph Node instance for indexing. Cosmos subgraphs can be deployed to any Graph Node on version `>=v0.26.0`. - -The first thing to do is create the subgraph in the node, this only has to be done once via the `create` CLI command: - -```bash -$ graph create subgraph-name --node -``` - -After the subgraph has been created, it can be deployed by using the graph `deploy` CLI command: - -```bash -$ graph deploy subgraph-name --ipfs --node -``` - -Once your subgraph has been deployed, it will be indexed by Graph Node. You can check its progress by querying the subgraph itself at the exposed endpoint. - -## Querying a Cosmos Hub subgraph - -The GraphQL endpoint for Cosmos Hub subgraphs is determined by the schema definition, with the existing API interface. Please visit the [GraphQL API documentation](https://thegraph.com/docs/en/developer/graphql-api/) for more information. - -## Example Subgraphs - -Here are some example subgraphs for reference: - -[Cosmos Hub Block Subgraph](https://github.com/graphprotocol/example-subgraph/tree/cosmos-block-example) - -[Cosmos Hub Event Subgraph](https://github.com/graphprotocol/example-subgraph/tree/cosmos-event-example) - -[Cosmos Hub Transaction Subgraph](https://github.com/graphprotocol/example-subgraph/tree/cosmos-transaction-example) diff --git a/pages/ja/supported-networks/cosmos.mdx b/pages/ja/supported-networks/cosmos.mdx deleted file mode 100644 index 05bc2f69935f..000000000000 --- a/pages/ja/supported-networks/cosmos.mdx +++ /dev/null @@ -1,209 +0,0 @@ ---- -title: Building Subgraphs on Cosmos Hub ---- - -This guide is an introduction on building subgraphs indexing the [Cosmos Hub blockchain](https://hub.cosmos.network/). - -## What is Cosmos Hub? - -[Cosmos](https://cosmos.network/) is an ecosystem of blockchains that can scale and interoperate with each other. Cosmos Hub is the first blockchain in the ecosystem. You can visit the [official documentation](https://docs.cosmos.network/) for more information. - -## What are Cosmos subgraphs? - -Cosmos subgraphs are a new type of subgraph that [Graph Node](https://github.com/graphprotocol/graph-node) is now able to process. This allows Cosmos Hub developers to easily index on-chain events into a useful data set, easily available to query via GraphQL. - -There are currently three types of handlers supported for the Cosmos Hub subgraphs: - -- Block handlers. -- [Event](https://docs.cosmos.network/master/core/events.html) handlers. -- [Transaction](https://docs.cosmos.network/master/core/transactions.html) handlers. - -Based on the [official Cosmos documentation](https://docs.cosmos.network/): - -> Events are objects that contain information about the execution of the application. They are mainly used by service providers like block explorers and wallet to track the execution of various messages and index transactions. - -> Transactions are objects created by end-users to trigger state changes in the application. - -## Building a Cosmos Hub subgraph - -### Subgraph Dependencies - -[graph-cli](https://github.com/graphprotocol/graph-cli) is a CLI tool to build and deploy subgraphs, version `>=0.30.0` is required in order to work with Cosmos Hub subgraphs. - -[graph-ts](https://github.com/graphprotocol/graph-ts) is a library of subgraph-specific types, version `>=0.27.0` is required in order to work with Cosmos Hub subgraphs. - -### Subgraph Main Components - -There are three main key parts or files when it comes to defining a subgraph: - -**subgraph.yaml**: a YAML file containing the subgraph manifest, which identifies which events to track and how to process them. - -**schema.graphql**: a GraphQL schema that defines what data is stored for your subgraph, and how to query it via GraphQL. - -**AssemblyScript Mappings**: [AssemblyScript](https://github.com/AssemblyScript/assemblyscript) code that translates from the event data to the entities defined in your schema. - -### Subgraph Manifest Definition - -The subgraph manifest (`subgraph.yaml`) identifies the data sources for the subgraph, the triggers of interest, and the functions that should be run in response to those triggers. See below for an example subgraph manifest for a Cosmos Hub subgraph: - -```yaml -specVersion: 0.0.5 -description: Cosmos Subgraph Example -schema: - file: ./schema.graphql # link to the schema file -dataSources: - - kind: cosmos - network: cosmoshub-4 - source: - startBlock: 0 # Required for Cosmos, set this to 0 to start indexing from chain genesis - mapping: - apiVersion: 0.0.7 - language: wasm/assemblyscript - blockHandlers: - - handler: handleNewBlock # the function name in the mapping file - eventHandlers: - - event: rewards # the type of the event that will be handled - handler: handleReward # the function name in the mapping file - transactionHandlers: - - handler: handleTransaction # the function name in the mapping file - file: ./src/mapping.ts # link to the file with the Assemblyscript mappings -``` - -- Cosmos Hub subgraphs introduce a new `kind` of data source (`cosmos`). -- The `network` should correspond to a network on the hosting Graph Node. Cosmos Hub mainnet is `cosmoshub-4`. Cosmos Hub current testnet is `theta-testnet-001`. Other Cosmos Hub networks, i.e. `cosmoshub-3`, are halted, therefore no data is provided for them. - -Cosmos Hub data sources support three types of handlers: - -- `blockHandlers`: run on every new block appended to the chain. The handler will receive a full block and all its data containing, among other things, all the events and transactions. -- `eventHandlers`: run on every event, except if there is an event type specified in the handler definition, in that case only events of that type are processed. Block data is also passed onto the mapping in order to have context of the event within the chain. -- `transactionHandlers`: run for every transaction executed. The mapping is provided with all the relevant data related to the transaction and a block abstraction that can be used to acquire context of the transaction within a block and within the chain. - -Event and Transaction handlers are a way to process meaningful data from the chain without the need of processing a whole block. The data processed by them can also be found in the block handlers, since events and transactions are also part of a block, but removes the need of processing unnecessary data. - -### Schema Definition - -Schema definition describes the structure of the resulting subgraph database, and the relationships between entities. This is agnostic of the original data source. There are more details on subgraph schema definition [here](https://thegraph.com/docs/en/developer/create-subgraph-hosted/#the-graph-ql-schema). - -### AssemblyScript Mappings - -The handlers for processing events are written in [AssemblyScript](https://www.assemblyscript.org/). - -Cosmos Hub indexing introduces Cosmos-specific data types to the [AssemblyScript API](https://thegraph.com/docs/en/developer/assemblyscript-api/). - -```tsx -class Block { - header: Header - evidence: EvidenceList - resultBeginBlock: ResponseBeginBlock - resultEndBlock: ResponseEndBlock - transactions: Array - validatorUpdates: Array -} - -class EventData { - event: Event - block: HeaderOnlyBlock -} - -class TransactionData { - tx: TxResult - block: HeaderOnlyBlock -} - -// HeaderOnlyBlock is a standard [Block] structure where all other fields are -// removed so that hydrating that object from a [Block] bytes payload will -// drastically reduce allocated memory required to hold the full block. -// -// This can be used to unpack a [Block] when only the [Header] information -// is required and greatly reduce required memory. -class HeaderOnlyBlock { - header: Header -} - -class Header { - version: Consensus - chainId: string - height: u64 - time: Timestamp - lastBlockId: BlockID - lastCommitHash: Bytes - dataHash: Bytes - validatorsHash: Bytes - nextValidatorsHash: Bytes - consensusHash: Bytes - appHash: Bytes - lastResultsHash: Bytes - evidenceHash: Bytes - proposerAddress: Bytes - hash: Bytes -} - -class TxResult { - height: u64 - index: u32 - tx: Bytes - result: ResponseDeliverTx - hash: Bytes -} - -class Event { - eventType: string - attributes: Array -} -``` - -The types above are just the general ones that mappings use. You can find the full list of types for the Cosmos Hub integration [here](https://github.com/graphprotocol/graph-ts/blob/main/chain/cosmos.ts). - -Each type of handler will receive a different type based on the relevant data. For both event and transaction handlers, a reference to the block they are contained in is passed as well. These are the exact types that are passed as a parameter to each mapping function: - -`Block` is passed to the blockHandler. - -`EventData` is passed to the eventHandler. - -`TransactionData` is passed to the transactionHandler. - -## Creating and building a Cosmos Hub subgraph - -The first step before starting to write the subgraph mappings is to generate the type bindings based on the entities that have been defined in the subgraph schema file (`schema.graphql`). This will allow the mapping functions to create new objects of those types and save them to the store. This is done by using the `codegen` CLI command: - -```bash -$ graph codegen -``` - -Once the mappings are ready, the subgraph needs to be built. This step will highlight any errors the manifest or the mappings might have. A subgraph needs to build successfully in order to be deployed to the Graph Node. It can be done using the `build` CLI command: - -```bash -$ graph build -``` - -## Deploying a Cosmos Hub subgraph - -When the subgraph builds successfully, it is time to deploy it to a Graph Node instance for indexing. Cosmos subgraphs can be deployed to any Graph Node on version `>=v0.26.0`. - -The first thing to do is create the subgraph in the node, this only has to be done once via the `create` CLI command: - -```bash -$ graph create subgraph-name --node -``` - -After the subgraph has been created, it can be deployed by using the graph `deploy` CLI command: - -```bash -$ graph deploy subgraph-name --ipfs --node -``` - -Once your subgraph has been deployed, it will be indexed by Graph Node. You can check its progress by querying the subgraph itself at the exposed endpoint. - -## Querying a Cosmos Hub subgraph - -The GraphQL endpoint for Cosmos Hub subgraphs is determined by the schema definition, with the existing API interface. Please visit the [GraphQL API documentation](https://thegraph.com/docs/en/developer/graphql-api/) for more information. - -## Example Subgraphs - -Here are some example subgraphs for reference: - -[Cosmos Hub Block Subgraph](https://github.com/graphprotocol/example-subgraph/tree/cosmos-block-example) - -[Cosmos Hub Event Subgraph](https://github.com/graphprotocol/example-subgraph/tree/cosmos-event-example) - -[Cosmos Hub Transaction Subgraph](https://github.com/graphprotocol/example-subgraph/tree/cosmos-transaction-example) diff --git a/pages/ko/supported-networks/cosmos.mdx b/pages/ko/supported-networks/cosmos.mdx deleted file mode 100644 index 05bc2f69935f..000000000000 --- a/pages/ko/supported-networks/cosmos.mdx +++ /dev/null @@ -1,209 +0,0 @@ ---- -title: Building Subgraphs on Cosmos Hub ---- - -This guide is an introduction on building subgraphs indexing the [Cosmos Hub blockchain](https://hub.cosmos.network/). - -## What is Cosmos Hub? - -[Cosmos](https://cosmos.network/) is an ecosystem of blockchains that can scale and interoperate with each other. Cosmos Hub is the first blockchain in the ecosystem. You can visit the [official documentation](https://docs.cosmos.network/) for more information. - -## What are Cosmos subgraphs? - -Cosmos subgraphs are a new type of subgraph that [Graph Node](https://github.com/graphprotocol/graph-node) is now able to process. This allows Cosmos Hub developers to easily index on-chain events into a useful data set, easily available to query via GraphQL. - -There are currently three types of handlers supported for the Cosmos Hub subgraphs: - -- Block handlers. -- [Event](https://docs.cosmos.network/master/core/events.html) handlers. -- [Transaction](https://docs.cosmos.network/master/core/transactions.html) handlers. - -Based on the [official Cosmos documentation](https://docs.cosmos.network/): - -> Events are objects that contain information about the execution of the application. They are mainly used by service providers like block explorers and wallet to track the execution of various messages and index transactions. - -> Transactions are objects created by end-users to trigger state changes in the application. - -## Building a Cosmos Hub subgraph - -### Subgraph Dependencies - -[graph-cli](https://github.com/graphprotocol/graph-cli) is a CLI tool to build and deploy subgraphs, version `>=0.30.0` is required in order to work with Cosmos Hub subgraphs. - -[graph-ts](https://github.com/graphprotocol/graph-ts) is a library of subgraph-specific types, version `>=0.27.0` is required in order to work with Cosmos Hub subgraphs. - -### Subgraph Main Components - -There are three main key parts or files when it comes to defining a subgraph: - -**subgraph.yaml**: a YAML file containing the subgraph manifest, which identifies which events to track and how to process them. - -**schema.graphql**: a GraphQL schema that defines what data is stored for your subgraph, and how to query it via GraphQL. - -**AssemblyScript Mappings**: [AssemblyScript](https://github.com/AssemblyScript/assemblyscript) code that translates from the event data to the entities defined in your schema. - -### Subgraph Manifest Definition - -The subgraph manifest (`subgraph.yaml`) identifies the data sources for the subgraph, the triggers of interest, and the functions that should be run in response to those triggers. See below for an example subgraph manifest for a Cosmos Hub subgraph: - -```yaml -specVersion: 0.0.5 -description: Cosmos Subgraph Example -schema: - file: ./schema.graphql # link to the schema file -dataSources: - - kind: cosmos - network: cosmoshub-4 - source: - startBlock: 0 # Required for Cosmos, set this to 0 to start indexing from chain genesis - mapping: - apiVersion: 0.0.7 - language: wasm/assemblyscript - blockHandlers: - - handler: handleNewBlock # the function name in the mapping file - eventHandlers: - - event: rewards # the type of the event that will be handled - handler: handleReward # the function name in the mapping file - transactionHandlers: - - handler: handleTransaction # the function name in the mapping file - file: ./src/mapping.ts # link to the file with the Assemblyscript mappings -``` - -- Cosmos Hub subgraphs introduce a new `kind` of data source (`cosmos`). -- The `network` should correspond to a network on the hosting Graph Node. Cosmos Hub mainnet is `cosmoshub-4`. Cosmos Hub current testnet is `theta-testnet-001`. Other Cosmos Hub networks, i.e. `cosmoshub-3`, are halted, therefore no data is provided for them. - -Cosmos Hub data sources support three types of handlers: - -- `blockHandlers`: run on every new block appended to the chain. The handler will receive a full block and all its data containing, among other things, all the events and transactions. -- `eventHandlers`: run on every event, except if there is an event type specified in the handler definition, in that case only events of that type are processed. Block data is also passed onto the mapping in order to have context of the event within the chain. -- `transactionHandlers`: run for every transaction executed. The mapping is provided with all the relevant data related to the transaction and a block abstraction that can be used to acquire context of the transaction within a block and within the chain. - -Event and Transaction handlers are a way to process meaningful data from the chain without the need of processing a whole block. The data processed by them can also be found in the block handlers, since events and transactions are also part of a block, but removes the need of processing unnecessary data. - -### Schema Definition - -Schema definition describes the structure of the resulting subgraph database, and the relationships between entities. This is agnostic of the original data source. There are more details on subgraph schema definition [here](https://thegraph.com/docs/en/developer/create-subgraph-hosted/#the-graph-ql-schema). - -### AssemblyScript Mappings - -The handlers for processing events are written in [AssemblyScript](https://www.assemblyscript.org/). - -Cosmos Hub indexing introduces Cosmos-specific data types to the [AssemblyScript API](https://thegraph.com/docs/en/developer/assemblyscript-api/). - -```tsx -class Block { - header: Header - evidence: EvidenceList - resultBeginBlock: ResponseBeginBlock - resultEndBlock: ResponseEndBlock - transactions: Array - validatorUpdates: Array -} - -class EventData { - event: Event - block: HeaderOnlyBlock -} - -class TransactionData { - tx: TxResult - block: HeaderOnlyBlock -} - -// HeaderOnlyBlock is a standard [Block] structure where all other fields are -// removed so that hydrating that object from a [Block] bytes payload will -// drastically reduce allocated memory required to hold the full block. -// -// This can be used to unpack a [Block] when only the [Header] information -// is required and greatly reduce required memory. -class HeaderOnlyBlock { - header: Header -} - -class Header { - version: Consensus - chainId: string - height: u64 - time: Timestamp - lastBlockId: BlockID - lastCommitHash: Bytes - dataHash: Bytes - validatorsHash: Bytes - nextValidatorsHash: Bytes - consensusHash: Bytes - appHash: Bytes - lastResultsHash: Bytes - evidenceHash: Bytes - proposerAddress: Bytes - hash: Bytes -} - -class TxResult { - height: u64 - index: u32 - tx: Bytes - result: ResponseDeliverTx - hash: Bytes -} - -class Event { - eventType: string - attributes: Array -} -``` - -The types above are just the general ones that mappings use. You can find the full list of types for the Cosmos Hub integration [here](https://github.com/graphprotocol/graph-ts/blob/main/chain/cosmos.ts). - -Each type of handler will receive a different type based on the relevant data. For both event and transaction handlers, a reference to the block they are contained in is passed as well. These are the exact types that are passed as a parameter to each mapping function: - -`Block` is passed to the blockHandler. - -`EventData` is passed to the eventHandler. - -`TransactionData` is passed to the transactionHandler. - -## Creating and building a Cosmos Hub subgraph - -The first step before starting to write the subgraph mappings is to generate the type bindings based on the entities that have been defined in the subgraph schema file (`schema.graphql`). This will allow the mapping functions to create new objects of those types and save them to the store. This is done by using the `codegen` CLI command: - -```bash -$ graph codegen -``` - -Once the mappings are ready, the subgraph needs to be built. This step will highlight any errors the manifest or the mappings might have. A subgraph needs to build successfully in order to be deployed to the Graph Node. It can be done using the `build` CLI command: - -```bash -$ graph build -``` - -## Deploying a Cosmos Hub subgraph - -When the subgraph builds successfully, it is time to deploy it to a Graph Node instance for indexing. Cosmos subgraphs can be deployed to any Graph Node on version `>=v0.26.0`. - -The first thing to do is create the subgraph in the node, this only has to be done once via the `create` CLI command: - -```bash -$ graph create subgraph-name --node -``` - -After the subgraph has been created, it can be deployed by using the graph `deploy` CLI command: - -```bash -$ graph deploy subgraph-name --ipfs --node -``` - -Once your subgraph has been deployed, it will be indexed by Graph Node. You can check its progress by querying the subgraph itself at the exposed endpoint. - -## Querying a Cosmos Hub subgraph - -The GraphQL endpoint for Cosmos Hub subgraphs is determined by the schema definition, with the existing API interface. Please visit the [GraphQL API documentation](https://thegraph.com/docs/en/developer/graphql-api/) for more information. - -## Example Subgraphs - -Here are some example subgraphs for reference: - -[Cosmos Hub Block Subgraph](https://github.com/graphprotocol/example-subgraph/tree/cosmos-block-example) - -[Cosmos Hub Event Subgraph](https://github.com/graphprotocol/example-subgraph/tree/cosmos-event-example) - -[Cosmos Hub Transaction Subgraph](https://github.com/graphprotocol/example-subgraph/tree/cosmos-transaction-example) diff --git a/pages/vi/supported-networks/cosmos.mdx b/pages/vi/supported-networks/cosmos.mdx deleted file mode 100644 index 05bc2f69935f..000000000000 --- a/pages/vi/supported-networks/cosmos.mdx +++ /dev/null @@ -1,209 +0,0 @@ ---- -title: Building Subgraphs on Cosmos Hub ---- - -This guide is an introduction on building subgraphs indexing the [Cosmos Hub blockchain](https://hub.cosmos.network/). - -## What is Cosmos Hub? - -[Cosmos](https://cosmos.network/) is an ecosystem of blockchains that can scale and interoperate with each other. Cosmos Hub is the first blockchain in the ecosystem. You can visit the [official documentation](https://docs.cosmos.network/) for more information. - -## What are Cosmos subgraphs? - -Cosmos subgraphs are a new type of subgraph that [Graph Node](https://github.com/graphprotocol/graph-node) is now able to process. This allows Cosmos Hub developers to easily index on-chain events into a useful data set, easily available to query via GraphQL. - -There are currently three types of handlers supported for the Cosmos Hub subgraphs: - -- Block handlers. -- [Event](https://docs.cosmos.network/master/core/events.html) handlers. -- [Transaction](https://docs.cosmos.network/master/core/transactions.html) handlers. - -Based on the [official Cosmos documentation](https://docs.cosmos.network/): - -> Events are objects that contain information about the execution of the application. They are mainly used by service providers like block explorers and wallet to track the execution of various messages and index transactions. - -> Transactions are objects created by end-users to trigger state changes in the application. - -## Building a Cosmos Hub subgraph - -### Subgraph Dependencies - -[graph-cli](https://github.com/graphprotocol/graph-cli) is a CLI tool to build and deploy subgraphs, version `>=0.30.0` is required in order to work with Cosmos Hub subgraphs. - -[graph-ts](https://github.com/graphprotocol/graph-ts) is a library of subgraph-specific types, version `>=0.27.0` is required in order to work with Cosmos Hub subgraphs. - -### Subgraph Main Components - -There are three main key parts or files when it comes to defining a subgraph: - -**subgraph.yaml**: a YAML file containing the subgraph manifest, which identifies which events to track and how to process them. - -**schema.graphql**: a GraphQL schema that defines what data is stored for your subgraph, and how to query it via GraphQL. - -**AssemblyScript Mappings**: [AssemblyScript](https://github.com/AssemblyScript/assemblyscript) code that translates from the event data to the entities defined in your schema. - -### Subgraph Manifest Definition - -The subgraph manifest (`subgraph.yaml`) identifies the data sources for the subgraph, the triggers of interest, and the functions that should be run in response to those triggers. See below for an example subgraph manifest for a Cosmos Hub subgraph: - -```yaml -specVersion: 0.0.5 -description: Cosmos Subgraph Example -schema: - file: ./schema.graphql # link to the schema file -dataSources: - - kind: cosmos - network: cosmoshub-4 - source: - startBlock: 0 # Required for Cosmos, set this to 0 to start indexing from chain genesis - mapping: - apiVersion: 0.0.7 - language: wasm/assemblyscript - blockHandlers: - - handler: handleNewBlock # the function name in the mapping file - eventHandlers: - - event: rewards # the type of the event that will be handled - handler: handleReward # the function name in the mapping file - transactionHandlers: - - handler: handleTransaction # the function name in the mapping file - file: ./src/mapping.ts # link to the file with the Assemblyscript mappings -``` - -- Cosmos Hub subgraphs introduce a new `kind` of data source (`cosmos`). -- The `network` should correspond to a network on the hosting Graph Node. Cosmos Hub mainnet is `cosmoshub-4`. Cosmos Hub current testnet is `theta-testnet-001`. Other Cosmos Hub networks, i.e. `cosmoshub-3`, are halted, therefore no data is provided for them. - -Cosmos Hub data sources support three types of handlers: - -- `blockHandlers`: run on every new block appended to the chain. The handler will receive a full block and all its data containing, among other things, all the events and transactions. -- `eventHandlers`: run on every event, except if there is an event type specified in the handler definition, in that case only events of that type are processed. Block data is also passed onto the mapping in order to have context of the event within the chain. -- `transactionHandlers`: run for every transaction executed. The mapping is provided with all the relevant data related to the transaction and a block abstraction that can be used to acquire context of the transaction within a block and within the chain. - -Event and Transaction handlers are a way to process meaningful data from the chain without the need of processing a whole block. The data processed by them can also be found in the block handlers, since events and transactions are also part of a block, but removes the need of processing unnecessary data. - -### Schema Definition - -Schema definition describes the structure of the resulting subgraph database, and the relationships between entities. This is agnostic of the original data source. There are more details on subgraph schema definition [here](https://thegraph.com/docs/en/developer/create-subgraph-hosted/#the-graph-ql-schema). - -### AssemblyScript Mappings - -The handlers for processing events are written in [AssemblyScript](https://www.assemblyscript.org/). - -Cosmos Hub indexing introduces Cosmos-specific data types to the [AssemblyScript API](https://thegraph.com/docs/en/developer/assemblyscript-api/). - -```tsx -class Block { - header: Header - evidence: EvidenceList - resultBeginBlock: ResponseBeginBlock - resultEndBlock: ResponseEndBlock - transactions: Array - validatorUpdates: Array -} - -class EventData { - event: Event - block: HeaderOnlyBlock -} - -class TransactionData { - tx: TxResult - block: HeaderOnlyBlock -} - -// HeaderOnlyBlock is a standard [Block] structure where all other fields are -// removed so that hydrating that object from a [Block] bytes payload will -// drastically reduce allocated memory required to hold the full block. -// -// This can be used to unpack a [Block] when only the [Header] information -// is required and greatly reduce required memory. -class HeaderOnlyBlock { - header: Header -} - -class Header { - version: Consensus - chainId: string - height: u64 - time: Timestamp - lastBlockId: BlockID - lastCommitHash: Bytes - dataHash: Bytes - validatorsHash: Bytes - nextValidatorsHash: Bytes - consensusHash: Bytes - appHash: Bytes - lastResultsHash: Bytes - evidenceHash: Bytes - proposerAddress: Bytes - hash: Bytes -} - -class TxResult { - height: u64 - index: u32 - tx: Bytes - result: ResponseDeliverTx - hash: Bytes -} - -class Event { - eventType: string - attributes: Array -} -``` - -The types above are just the general ones that mappings use. You can find the full list of types for the Cosmos Hub integration [here](https://github.com/graphprotocol/graph-ts/blob/main/chain/cosmos.ts). - -Each type of handler will receive a different type based on the relevant data. For both event and transaction handlers, a reference to the block they are contained in is passed as well. These are the exact types that are passed as a parameter to each mapping function: - -`Block` is passed to the blockHandler. - -`EventData` is passed to the eventHandler. - -`TransactionData` is passed to the transactionHandler. - -## Creating and building a Cosmos Hub subgraph - -The first step before starting to write the subgraph mappings is to generate the type bindings based on the entities that have been defined in the subgraph schema file (`schema.graphql`). This will allow the mapping functions to create new objects of those types and save them to the store. This is done by using the `codegen` CLI command: - -```bash -$ graph codegen -``` - -Once the mappings are ready, the subgraph needs to be built. This step will highlight any errors the manifest or the mappings might have. A subgraph needs to build successfully in order to be deployed to the Graph Node. It can be done using the `build` CLI command: - -```bash -$ graph build -``` - -## Deploying a Cosmos Hub subgraph - -When the subgraph builds successfully, it is time to deploy it to a Graph Node instance for indexing. Cosmos subgraphs can be deployed to any Graph Node on version `>=v0.26.0`. - -The first thing to do is create the subgraph in the node, this only has to be done once via the `create` CLI command: - -```bash -$ graph create subgraph-name --node -``` - -After the subgraph has been created, it can be deployed by using the graph `deploy` CLI command: - -```bash -$ graph deploy subgraph-name --ipfs --node -``` - -Once your subgraph has been deployed, it will be indexed by Graph Node. You can check its progress by querying the subgraph itself at the exposed endpoint. - -## Querying a Cosmos Hub subgraph - -The GraphQL endpoint for Cosmos Hub subgraphs is determined by the schema definition, with the existing API interface. Please visit the [GraphQL API documentation](https://thegraph.com/docs/en/developer/graphql-api/) for more information. - -## Example Subgraphs - -Here are some example subgraphs for reference: - -[Cosmos Hub Block Subgraph](https://github.com/graphprotocol/example-subgraph/tree/cosmos-block-example) - -[Cosmos Hub Event Subgraph](https://github.com/graphprotocol/example-subgraph/tree/cosmos-event-example) - -[Cosmos Hub Transaction Subgraph](https://github.com/graphprotocol/example-subgraph/tree/cosmos-transaction-example) diff --git a/pages/zh/supported-networks/cosmos.mdx b/pages/zh/supported-networks/cosmos.mdx deleted file mode 100644 index 05bc2f69935f..000000000000 --- a/pages/zh/supported-networks/cosmos.mdx +++ /dev/null @@ -1,209 +0,0 @@ ---- -title: Building Subgraphs on Cosmos Hub ---- - -This guide is an introduction on building subgraphs indexing the [Cosmos Hub blockchain](https://hub.cosmos.network/). - -## What is Cosmos Hub? - -[Cosmos](https://cosmos.network/) is an ecosystem of blockchains that can scale and interoperate with each other. Cosmos Hub is the first blockchain in the ecosystem. You can visit the [official documentation](https://docs.cosmos.network/) for more information. - -## What are Cosmos subgraphs? - -Cosmos subgraphs are a new type of subgraph that [Graph Node](https://github.com/graphprotocol/graph-node) is now able to process. This allows Cosmos Hub developers to easily index on-chain events into a useful data set, easily available to query via GraphQL. - -There are currently three types of handlers supported for the Cosmos Hub subgraphs: - -- Block handlers. -- [Event](https://docs.cosmos.network/master/core/events.html) handlers. -- [Transaction](https://docs.cosmos.network/master/core/transactions.html) handlers. - -Based on the [official Cosmos documentation](https://docs.cosmos.network/): - -> Events are objects that contain information about the execution of the application. They are mainly used by service providers like block explorers and wallet to track the execution of various messages and index transactions. - -> Transactions are objects created by end-users to trigger state changes in the application. - -## Building a Cosmos Hub subgraph - -### Subgraph Dependencies - -[graph-cli](https://github.com/graphprotocol/graph-cli) is a CLI tool to build and deploy subgraphs, version `>=0.30.0` is required in order to work with Cosmos Hub subgraphs. - -[graph-ts](https://github.com/graphprotocol/graph-ts) is a library of subgraph-specific types, version `>=0.27.0` is required in order to work with Cosmos Hub subgraphs. - -### Subgraph Main Components - -There are three main key parts or files when it comes to defining a subgraph: - -**subgraph.yaml**: a YAML file containing the subgraph manifest, which identifies which events to track and how to process them. - -**schema.graphql**: a GraphQL schema that defines what data is stored for your subgraph, and how to query it via GraphQL. - -**AssemblyScript Mappings**: [AssemblyScript](https://github.com/AssemblyScript/assemblyscript) code that translates from the event data to the entities defined in your schema. - -### Subgraph Manifest Definition - -The subgraph manifest (`subgraph.yaml`) identifies the data sources for the subgraph, the triggers of interest, and the functions that should be run in response to those triggers. See below for an example subgraph manifest for a Cosmos Hub subgraph: - -```yaml -specVersion: 0.0.5 -description: Cosmos Subgraph Example -schema: - file: ./schema.graphql # link to the schema file -dataSources: - - kind: cosmos - network: cosmoshub-4 - source: - startBlock: 0 # Required for Cosmos, set this to 0 to start indexing from chain genesis - mapping: - apiVersion: 0.0.7 - language: wasm/assemblyscript - blockHandlers: - - handler: handleNewBlock # the function name in the mapping file - eventHandlers: - - event: rewards # the type of the event that will be handled - handler: handleReward # the function name in the mapping file - transactionHandlers: - - handler: handleTransaction # the function name in the mapping file - file: ./src/mapping.ts # link to the file with the Assemblyscript mappings -``` - -- Cosmos Hub subgraphs introduce a new `kind` of data source (`cosmos`). -- The `network` should correspond to a network on the hosting Graph Node. Cosmos Hub mainnet is `cosmoshub-4`. Cosmos Hub current testnet is `theta-testnet-001`. Other Cosmos Hub networks, i.e. `cosmoshub-3`, are halted, therefore no data is provided for them. - -Cosmos Hub data sources support three types of handlers: - -- `blockHandlers`: run on every new block appended to the chain. The handler will receive a full block and all its data containing, among other things, all the events and transactions. -- `eventHandlers`: run on every event, except if there is an event type specified in the handler definition, in that case only events of that type are processed. Block data is also passed onto the mapping in order to have context of the event within the chain. -- `transactionHandlers`: run for every transaction executed. The mapping is provided with all the relevant data related to the transaction and a block abstraction that can be used to acquire context of the transaction within a block and within the chain. - -Event and Transaction handlers are a way to process meaningful data from the chain without the need of processing a whole block. The data processed by them can also be found in the block handlers, since events and transactions are also part of a block, but removes the need of processing unnecessary data. - -### Schema Definition - -Schema definition describes the structure of the resulting subgraph database, and the relationships between entities. This is agnostic of the original data source. There are more details on subgraph schema definition [here](https://thegraph.com/docs/en/developer/create-subgraph-hosted/#the-graph-ql-schema). - -### AssemblyScript Mappings - -The handlers for processing events are written in [AssemblyScript](https://www.assemblyscript.org/). - -Cosmos Hub indexing introduces Cosmos-specific data types to the [AssemblyScript API](https://thegraph.com/docs/en/developer/assemblyscript-api/). - -```tsx -class Block { - header: Header - evidence: EvidenceList - resultBeginBlock: ResponseBeginBlock - resultEndBlock: ResponseEndBlock - transactions: Array - validatorUpdates: Array -} - -class EventData { - event: Event - block: HeaderOnlyBlock -} - -class TransactionData { - tx: TxResult - block: HeaderOnlyBlock -} - -// HeaderOnlyBlock is a standard [Block] structure where all other fields are -// removed so that hydrating that object from a [Block] bytes payload will -// drastically reduce allocated memory required to hold the full block. -// -// This can be used to unpack a [Block] when only the [Header] information -// is required and greatly reduce required memory. -class HeaderOnlyBlock { - header: Header -} - -class Header { - version: Consensus - chainId: string - height: u64 - time: Timestamp - lastBlockId: BlockID - lastCommitHash: Bytes - dataHash: Bytes - validatorsHash: Bytes - nextValidatorsHash: Bytes - consensusHash: Bytes - appHash: Bytes - lastResultsHash: Bytes - evidenceHash: Bytes - proposerAddress: Bytes - hash: Bytes -} - -class TxResult { - height: u64 - index: u32 - tx: Bytes - result: ResponseDeliverTx - hash: Bytes -} - -class Event { - eventType: string - attributes: Array -} -``` - -The types above are just the general ones that mappings use. You can find the full list of types for the Cosmos Hub integration [here](https://github.com/graphprotocol/graph-ts/blob/main/chain/cosmos.ts). - -Each type of handler will receive a different type based on the relevant data. For both event and transaction handlers, a reference to the block they are contained in is passed as well. These are the exact types that are passed as a parameter to each mapping function: - -`Block` is passed to the blockHandler. - -`EventData` is passed to the eventHandler. - -`TransactionData` is passed to the transactionHandler. - -## Creating and building a Cosmos Hub subgraph - -The first step before starting to write the subgraph mappings is to generate the type bindings based on the entities that have been defined in the subgraph schema file (`schema.graphql`). This will allow the mapping functions to create new objects of those types and save them to the store. This is done by using the `codegen` CLI command: - -```bash -$ graph codegen -``` - -Once the mappings are ready, the subgraph needs to be built. This step will highlight any errors the manifest or the mappings might have. A subgraph needs to build successfully in order to be deployed to the Graph Node. It can be done using the `build` CLI command: - -```bash -$ graph build -``` - -## Deploying a Cosmos Hub subgraph - -When the subgraph builds successfully, it is time to deploy it to a Graph Node instance for indexing. Cosmos subgraphs can be deployed to any Graph Node on version `>=v0.26.0`. - -The first thing to do is create the subgraph in the node, this only has to be done once via the `create` CLI command: - -```bash -$ graph create subgraph-name --node -``` - -After the subgraph has been created, it can be deployed by using the graph `deploy` CLI command: - -```bash -$ graph deploy subgraph-name --ipfs --node -``` - -Once your subgraph has been deployed, it will be indexed by Graph Node. You can check its progress by querying the subgraph itself at the exposed endpoint. - -## Querying a Cosmos Hub subgraph - -The GraphQL endpoint for Cosmos Hub subgraphs is determined by the schema definition, with the existing API interface. Please visit the [GraphQL API documentation](https://thegraph.com/docs/en/developer/graphql-api/) for more information. - -## Example Subgraphs - -Here are some example subgraphs for reference: - -[Cosmos Hub Block Subgraph](https://github.com/graphprotocol/example-subgraph/tree/cosmos-block-example) - -[Cosmos Hub Event Subgraph](https://github.com/graphprotocol/example-subgraph/tree/cosmos-event-example) - -[Cosmos Hub Transaction Subgraph](https://github.com/graphprotocol/example-subgraph/tree/cosmos-transaction-example) From fe2acbceeeff68590f9c5834ceacd28b11b4d57b Mon Sep 17 00:00:00 2001 From: Marc Puig Date: Tue, 24 May 2022 11:58:59 +0200 Subject: [PATCH 04/13] Apply feedback --- pages/en/supported-networks/cosmos.mdx | 95 +++++++++++++------------- 1 file changed, 49 insertions(+), 46 deletions(-) diff --git a/pages/en/supported-networks/cosmos.mdx b/pages/en/supported-networks/cosmos.mdx index 05bc2f69935f..db3e635575d7 100644 --- a/pages/en/supported-networks/cosmos.mdx +++ b/pages/en/supported-networks/cosmos.mdx @@ -40,11 +40,11 @@ There are three main key parts or files when it comes to defining a subgraph: **schema.graphql**: a GraphQL schema that defines what data is stored for your subgraph, and how to query it via GraphQL. -**AssemblyScript Mappings**: [AssemblyScript](https://github.com/AssemblyScript/assemblyscript) code that translates from the event data to the entities defined in your schema. +**AssemblyScript Mappings**: [AssemblyScript](https://github.com/AssemblyScript/assemblyscript) code that translates from blockchain data to the entities defined in your schema. ### Subgraph Manifest Definition -The subgraph manifest (`subgraph.yaml`) identifies the data sources for the subgraph, the triggers of interest, and the functions that should be run in response to those triggers. See below for an example subgraph manifest for a Cosmos Hub subgraph: +The subgraph manifest (`subgraph.yaml`) identifies the data sources for the subgraph, the triggers of interest, and the functions (`handlers`) that should be run in response to those triggers. See below for an example subgraph manifest for a Cosmos Hub subgraph: ```yaml specVersion: 0.0.5 @@ -53,6 +53,7 @@ schema: file: ./schema.graphql # link to the schema file dataSources: - kind: cosmos + name: CosmosHub network: cosmoshub-4 source: startBlock: 0 # Required for Cosmos, set this to 0 to start indexing from chain genesis @@ -69,13 +70,13 @@ dataSources: file: ./src/mapping.ts # link to the file with the Assemblyscript mappings ``` -- Cosmos Hub subgraphs introduce a new `kind` of data source (`cosmos`). +- Cosmos subgraphs introduce a new `kind` of data source (`cosmos`). - The `network` should correspond to a network on the hosting Graph Node. Cosmos Hub mainnet is `cosmoshub-4`. Cosmos Hub current testnet is `theta-testnet-001`. Other Cosmos Hub networks, i.e. `cosmoshub-3`, are halted, therefore no data is provided for them. -Cosmos Hub data sources support three types of handlers: +Cosmos data sources support three types of handlers: - `blockHandlers`: run on every new block appended to the chain. The handler will receive a full block and all its data containing, among other things, all the events and transactions. -- `eventHandlers`: run on every event, except if there is an event type specified in the handler definition, in that case only events of that type are processed. Block data is also passed onto the mapping in order to have context of the event within the chain. +- `eventHandlers`: run on every event contained in a block that matches the event type specified in the manifest. Block data is also passed onto the mapping in order to have context of the event within the chain. - `transactionHandlers`: run for every transaction executed. The mapping is provided with all the relevant data related to the transaction and a block abstraction that can be used to acquire context of the transaction within a block and within the chain. Event and Transaction handlers are a way to process meaningful data from the chain without the need of processing a whole block. The data processed by them can also be found in the block handlers, since events and transactions are also part of a block, but removes the need of processing unnecessary data. @@ -92,67 +93,61 @@ Cosmos Hub indexing introduces Cosmos-specific data types to the [AssemblyScrip ```tsx class Block { - header: Header - evidence: EvidenceList - resultBeginBlock: ResponseBeginBlock - resultEndBlock: ResponseEndBlock - transactions: Array - validatorUpdates: Array + header: Header + evidence: EvidenceList + resultBeginBlock: ResponseBeginBlock + resultEndBlock: ResponseEndBlock + transactions: Array + validatorUpdates: Array } class EventData { - event: Event - block: HeaderOnlyBlock + event: Event + block: HeaderOnlyBlock } class TransactionData { - tx: TxResult - block: HeaderOnlyBlock + tx: TxResult + block: HeaderOnlyBlock } -// HeaderOnlyBlock is a standard [Block] structure where all other fields are -// removed so that hydrating that object from a [Block] bytes payload will -// drastically reduce allocated memory required to hold the full block. -// -// This can be used to unpack a [Block] when only the [Header] information -// is required and greatly reduce required memory. class HeaderOnlyBlock { - header: Header + header: Header } class Header { - version: Consensus - chainId: string - height: u64 - time: Timestamp - lastBlockId: BlockID - lastCommitHash: Bytes - dataHash: Bytes - validatorsHash: Bytes - nextValidatorsHash: Bytes - consensusHash: Bytes - appHash: Bytes - lastResultsHash: Bytes - evidenceHash: Bytes - proposerAddress: Bytes - hash: Bytes + version: Consensus + chainId: string + height: u64 + time: Timestamp + lastBlockId: BlockID + lastCommitHash: Bytes + dataHash: Bytes + validatorsHash: Bytes + nextValidatorsHash: Bytes + consensusHash: Bytes + appHash: Bytes + lastResultsHash: Bytes + evidenceHash: Bytes + proposerAddress: Bytes + hash: Bytes } class TxResult { - height: u64 - index: u32 - tx: Bytes - result: ResponseDeliverTx - hash: Bytes + height: u64 + index: u32 + tx: Bytes + result: ResponseDeliverTx + hash: Bytes } class Event { - eventType: string - attributes: Array + eventType: string + attributes: Array } ``` -The types above are just the general ones that mappings use. You can find the full list of types for the Cosmos Hub integration [here](https://github.com/graphprotocol/graph-ts/blob/main/chain/cosmos.ts). +The types above are just the general ones that mappings use. You can find the full list of types for the Cosmos integration [here](https://github.com/graphprotocol/graph-ts/blob/main/chain/cosmos.ts). Each type of handler will receive a different type based on the relevant data. For both event and transaction handlers, a reference to the block they are contained in is passed as well. These are the exact types that are passed as a parameter to each mapping function: @@ -162,7 +157,7 @@ Each type of handler will receive a different type based on the relevant data. F `TransactionData` is passed to the transactionHandler. -## Creating and building a Cosmos Hub subgraph +## Creating and building a Cosmos subgraph The first step before starting to write the subgraph mappings is to generate the type bindings based on the entities that have been defined in the subgraph schema file (`schema.graphql`). This will allow the mapping functions to create new objects of those types and save them to the store. This is done by using the `codegen` CLI command: @@ -183,13 +178,21 @@ When the subgraph builds successfully, it is time to deploy it to a Graph Node i The first thing to do is create the subgraph in the node, this only has to be done once via the `create` CLI command: ```bash +Local deployment: $ graph create subgraph-name --node + +Hosted service deployment: +$ graph create subgraph-name --node https://api.thegraph.com/deploy/ ``` After the subgraph has been created, it can be deployed by using the graph `deploy` CLI command: ```bash +Local deployment: $ graph deploy subgraph-name --ipfs --node + +Hosted service deployment: +$ graph deploy subgraph-name --ipfs https://api.thegraph.com/ipfs/ --node https://api.thegraph.com/deploy/ ``` Once your subgraph has been deployed, it will be indexed by Graph Node. You can check its progress by querying the subgraph itself at the exposed endpoint. From f2c8088f4bd28ff7387abc72fbb1291cac1f24a9 Mon Sep 17 00:00:00 2001 From: Marc Puig Date: Tue, 24 May 2022 16:06:28 +0200 Subject: [PATCH 05/13] Update naming from Cosmos Hub to Cosmos --- pages/en/supported-networks/cosmos.mdx | 34 +++++++++++++------------- 1 file changed, 17 insertions(+), 17 deletions(-) diff --git a/pages/en/supported-networks/cosmos.mdx b/pages/en/supported-networks/cosmos.mdx index db3e635575d7..52fb3baecb48 100644 --- a/pages/en/supported-networks/cosmos.mdx +++ b/pages/en/supported-networks/cosmos.mdx @@ -1,12 +1,12 @@ --- -title: Building Subgraphs on Cosmos Hub +title: Building Subgraphs on Cosmos --- -This guide is an introduction on building subgraphs indexing the [Cosmos Hub blockchain](https://hub.cosmos.network/). +This guide is an introduction on building subgraphs indexing [Cosmos](https://docs.cosmos.network/) based blockchains. The first Cosmos blockchain available to subgraph developers is Cosmos Hub, hence this document will focus on it while describing how to build Cosmos subgraphs. ## What is Cosmos Hub? -[Cosmos](https://cosmos.network/) is an ecosystem of blockchains that can scale and interoperate with each other. Cosmos Hub is the first blockchain in the ecosystem. You can visit the [official documentation](https://docs.cosmos.network/) for more information. +[Cosmos](https://cosmos.network/) is an ecosystem of blockchains that can scale and interoperate with each other. [Cosmos Hub](https://hub.cosmos.network/) is the first blockchain in the ecosystem. You can visit the [official documentation](https://docs.cosmos.network/) for more information. ## What are Cosmos subgraphs? @@ -24,13 +24,13 @@ Based on the [official Cosmos documentation](https://docs.cosmos.network/): > Transactions are objects created by end-users to trigger state changes in the application. -## Building a Cosmos Hub subgraph +## Building a Cosmos subgraph ### Subgraph Dependencies -[graph-cli](https://github.com/graphprotocol/graph-cli) is a CLI tool to build and deploy subgraphs, version `>=0.30.0` is required in order to work with Cosmos Hub subgraphs. +[graph-cli](https://github.com/graphprotocol/graph-cli) is a CLI tool to build and deploy subgraphs, version `>=0.30.0` is required in order to work with Cosmos subgraphs. -[graph-ts](https://github.com/graphprotocol/graph-ts) is a library of subgraph-specific types, version `>=0.27.0` is required in order to work with Cosmos Hub subgraphs. +[graph-ts](https://github.com/graphprotocol/graph-ts) is a library of subgraph-specific types, version `>=0.27.0` is required in order to work with Cosmos subgraphs. ### Subgraph Main Components @@ -44,7 +44,7 @@ There are three main key parts or files when it comes to defining a subgraph: ### Subgraph Manifest Definition -The subgraph manifest (`subgraph.yaml`) identifies the data sources for the subgraph, the triggers of interest, and the functions (`handlers`) that should be run in response to those triggers. See below for an example subgraph manifest for a Cosmos Hub subgraph: +The subgraph manifest (`subgraph.yaml`) identifies the data sources for the subgraph, the triggers of interest, and the functions (`handlers`) that should be run in response to those triggers. See below for an example subgraph manifest for a Cosmos subgraph: ```yaml specVersion: 0.0.5 @@ -70,8 +70,8 @@ dataSources: file: ./src/mapping.ts # link to the file with the Assemblyscript mappings ``` -- Cosmos subgraphs introduce a new `kind` of data source (`cosmos`). -- The `network` should correspond to a network on the hosting Graph Node. Cosmos Hub mainnet is `cosmoshub-4`. Cosmos Hub current testnet is `theta-testnet-001`. Other Cosmos Hub networks, i.e. `cosmoshub-3`, are halted, therefore no data is provided for them. +- Cosmos subgraphs introduce a new `kind` of data source (`cosmos`). +- The `network` should correspond to a network on the hosting Graph Node. In the example, the Cosmos Hub network is used. Cosmos Hub mainnet is `cosmoshub-4`. Cosmos Hub current testnet is `theta-testnet-001`. Cosmos data sources support three types of handlers: @@ -83,13 +83,13 @@ Event and Transaction handlers are a way to process meaningful data from the cha ### Schema Definition -Schema definition describes the structure of the resulting subgraph database, and the relationships between entities. This is agnostic of the original data source. There are more details on subgraph schema definition [here](https://thegraph.com/docs/en/developer/create-subgraph-hosted/#the-graph-ql-schema). +Schema definition describes the structure of the resulting subgraph database, and the relationships between entities. This is agnostic of the original data source. There are more details on subgraph schema definition [here](https://thegraph.com/docs/en/developer/create-subgraph-hosted/#the-graph-ql-schema). ### AssemblyScript Mappings -The handlers for processing events are written in [AssemblyScript](https://www.assemblyscript.org/). +The handlers for processing events are written in [AssemblyScript](https://www.assemblyscript.org/). -Cosmos Hub indexing introduces Cosmos-specific data types to the [AssemblyScript API](https://thegraph.com/docs/en/developer/assemblyscript-api/). +Cosmos indexing introduces Cosmos-specific data types to the [AssemblyScript API](https://thegraph.com/docs/en/developer/assemblyscript-api/). ```tsx class Block { @@ -171,9 +171,9 @@ Once the mappings are ready, the subgraph needs to be built. This step will high $ graph build ``` -## Deploying a Cosmos Hub subgraph +## Deploying a Cosmos subgraph -When the subgraph builds successfully, it is time to deploy it to a Graph Node instance for indexing. Cosmos subgraphs can be deployed to any Graph Node on version `>=v0.26.0`. +When the subgraph builds successfully, it is time to deploy it to a Graph Node instance for indexing. Cosmos subgraphs can be deployed to any Graph Node on version `>=v0.26.0`. The first thing to do is create the subgraph in the node, this only has to be done once via the `create` CLI command: @@ -197,11 +197,11 @@ $ graph deploy subgraph-name --ipfs https://api.thegraph.com/ipfs/ --node https: Once your subgraph has been deployed, it will be indexed by Graph Node. You can check its progress by querying the subgraph itself at the exposed endpoint. -## Querying a Cosmos Hub subgraph +## Querying a Cosmos subgraph -The GraphQL endpoint for Cosmos Hub subgraphs is determined by the schema definition, with the existing API interface. Please visit the [GraphQL API documentation](https://thegraph.com/docs/en/developer/graphql-api/) for more information. +The GraphQL endpoint for Cosmos subgraphs is determined by the schema definition, with the existing API interface. Please visit the [GraphQL API documentation](https://thegraph.com/docs/en/developer/graphql-api/) for more information. -## Example Subgraphs +## Cosmos Hub Example Subgraphs Here are some example subgraphs for reference: From c147a8992fdf44ae9a7d77ec4d8a37ce2dc56085 Mon Sep 17 00:00:00 2001 From: Marc Puig Date: Tue, 24 May 2022 16:56:00 +0200 Subject: [PATCH 06/13] Rework to a general Cosmos document, adding blockchains at the bottom. --- pages/en/supported-networks/cosmos.mdx | 48 +++++++++++++++----------- 1 file changed, 28 insertions(+), 20 deletions(-) diff --git a/pages/en/supported-networks/cosmos.mdx b/pages/en/supported-networks/cosmos.mdx index 52fb3baecb48..4139064a8440 100644 --- a/pages/en/supported-networks/cosmos.mdx +++ b/pages/en/supported-networks/cosmos.mdx @@ -2,17 +2,13 @@ title: Building Subgraphs on Cosmos --- -This guide is an introduction on building subgraphs indexing [Cosmos](https://docs.cosmos.network/) based blockchains. The first Cosmos blockchain available to subgraph developers is Cosmos Hub, hence this document will focus on it while describing how to build Cosmos subgraphs. - -## What is Cosmos Hub? - -[Cosmos](https://cosmos.network/) is an ecosystem of blockchains that can scale and interoperate with each other. [Cosmos Hub](https://hub.cosmos.network/) is the first blockchain in the ecosystem. You can visit the [official documentation](https://docs.cosmos.network/) for more information. +This guide is an introduction on building subgraphs indexing [Cosmos](https://docs.cosmos.network/) based blockchains. ## What are Cosmos subgraphs? -Cosmos subgraphs are a new type of subgraph that [Graph Node](https://github.com/graphprotocol/graph-node) is now able to process. This allows Cosmos Hub developers to easily index on-chain events into a useful data set, easily available to query via GraphQL. +Cosmos subgraphs are a new type of subgraph that [Graph Node](https://github.com/graphprotocol/graph-node) is now able to process. This allows Cosmos-based blockchain developers to easily index on-chain events into a useful data set, easily available to query via GraphQL. -There are currently three types of handlers supported for the Cosmos Hub subgraphs: +There are currently three types of handlers supported for the Cosmos subgraphs: - Block handlers. - [Event](https://docs.cosmos.network/master/core/events.html) handlers. @@ -26,12 +22,6 @@ Based on the [official Cosmos documentation](https://docs.cosmos.network/): ## Building a Cosmos subgraph -### Subgraph Dependencies - -[graph-cli](https://github.com/graphprotocol/graph-cli) is a CLI tool to build and deploy subgraphs, version `>=0.30.0` is required in order to work with Cosmos subgraphs. - -[graph-ts](https://github.com/graphprotocol/graph-ts) is a library of subgraph-specific types, version `>=0.27.0` is required in order to work with Cosmos subgraphs. - ### Subgraph Main Components There are three main key parts or files when it comes to defining a subgraph: @@ -54,7 +44,7 @@ schema: dataSources: - kind: cosmos name: CosmosHub - network: cosmoshub-4 + network: cosmoshub-4 # This will change for each cosmos-based blockchain. In this case the example uses the CosmosHub mainnet. source: startBlock: 0 # Required for Cosmos, set this to 0 to start indexing from chain genesis mapping: @@ -71,7 +61,7 @@ dataSources: ``` - Cosmos subgraphs introduce a new `kind` of data source (`cosmos`). -- The `network` should correspond to a network on the hosting Graph Node. In the example, the Cosmos Hub network is used. Cosmos Hub mainnet is `cosmoshub-4`. Cosmos Hub current testnet is `theta-testnet-001`. +- The `network` should correspond to a network on the hosting Graph Node. In the example, the CosmosHub mainnet is used. Cosmos data sources support three types of handlers: @@ -185,7 +175,7 @@ Hosted service deployment: $ graph create subgraph-name --node https://api.thegraph.com/deploy/ ``` -After the subgraph has been created, it can be deployed by using the graph `deploy` CLI command: +After the subgraph has been created, it can be deployed by using the graph `deploy` CLI command: ```bash Local deployment: @@ -201,12 +191,30 @@ Once your subgraph has been deployed, it will be indexed by Graph Node. You can The GraphQL endpoint for Cosmos subgraphs is determined by the schema definition, with the existing API interface. Please visit the [GraphQL API documentation](https://thegraph.com/docs/en/developer/graphql-api/) for more information. -## Cosmos Hub Example Subgraphs +## Supported Cosmos Blockchains + +### Cosmos Hub + +##### What is Cosmos Hub? + +The [Cosmos Hub blockchain](https://hub.cosmos.network/) is the first blockchain in the [Cosmos](https://cosmos.network/) ecosystem. You can visit the [official documentation](https://docs.cosmos.network/) for more information. + +##### Subgraph Dependencies + +[graph-cli](https://github.com/graphprotocol/graph-cli) is a CLI tool to build and deploy subgraphs, version `>=0.30.0` is required in order to work with Cosmos Hub subgraphs. + +[graph-ts](https://github.com/graphprotocol/graph-ts) is a library of subgraph-specific types, version `>=0.27.0` is required in order to work with Cosmos Hub subgraphs. + +##### Networks + +Cosmos Hub mainnet is `cosmoshub-4`. Cosmos Hub current testnet is `theta-testnet-001`.
Other Cosmos Hub networks, i.e. `cosmoshub-3`, are halted, therefore no data is provided for them. + +##### Example Subgraphs Here are some example subgraphs for reference: -[Cosmos Hub Block Subgraph](https://github.com/graphprotocol/example-subgraph/tree/cosmos-block-example) +[Cosmos Hub Block Filtering Example](https://github.com/graphprotocol/example-subgraph/tree/cosmos-block-example) -[Cosmos Hub Event Subgraph](https://github.com/graphprotocol/example-subgraph/tree/cosmos-event-example) +[Cosmos Hub Validator Rewards Example](https://github.com/graphprotocol/example-subgraph/tree/cosmos-event-example) -[Cosmos Hub Transaction Subgraph](https://github.com/graphprotocol/example-subgraph/tree/cosmos-transaction-example) +[Cosmos Hub Validator Delegations Example](https://github.com/graphprotocol/example-subgraph/tree/cosmos-transaction-example) From 98922bd3413beb82c475612f9e18e106a0a3b8e5 Mon Sep 17 00:00:00 2001 From: Marc Puig Date: Tue, 24 May 2022 17:07:58 +0200 Subject: [PATCH 07/13] Add Osmosis --- pages/en/supported-networks/cosmos.mdx | 26 ++++++++++++++++++++++++++ 1 file changed, 26 insertions(+) diff --git a/pages/en/supported-networks/cosmos.mdx b/pages/en/supported-networks/cosmos.mdx index 4139064a8440..e2c2e3b7ae37 100644 --- a/pages/en/supported-networks/cosmos.mdx +++ b/pages/en/supported-networks/cosmos.mdx @@ -218,3 +218,29 @@ Here are some example subgraphs for reference: [Cosmos Hub Validator Rewards Example](https://github.com/graphprotocol/example-subgraph/tree/cosmos-event-example) [Cosmos Hub Validator Delegations Example](https://github.com/graphprotocol/example-subgraph/tree/cosmos-transaction-example) + +### Osmosis + +##### What is Osmosis? + +[Osmosis](https://osmosis.zone/) is a decentralized, cross-chain automated market maker (AMM) protocol build on top of the Cosmos SDK. It allows users to create custom liquidity pools and trade IBC enabled tokens. You can visit the [official documentation](https://docs.osmosis.zone/) for more information. + +##### Subgraph Dependencies + +[graph-cli](https://github.com/graphprotocol/graph-cli) is a CLI tool to build and deploy subgraphs, version `>=0.30.0` is required in order to work with Osmosis subgraphs. + +[graph-ts](https://github.com/graphprotocol/graph-ts) is a library of subgraph-specific types, version `>=0.27.0` is required in order to work with Osmosis subgraphs. + +##### Networks + +Osmosis mainnet is `osmosis-1`. Osmosis current testnet is `osmo-test-4`. + +##### Example Subgraphs + +Here are some example subgraphs for reference: + +[Osmosis Block Filtering Example](https://github.com/graphprotocol/example-subgraph/tree/osmosis-block-example) + +[Osmosis Validator Rewards Example](https://github.com/graphprotocol/example-subgraph/tree/osmosis-event-example) + +[Osmosis Validator Delegations Example](https://github.com/graphprotocol/example-subgraph/tree/osmosis-transaction-example) From 269a0c3fe3b6b807597f8fb9edc8a6bf0718b3bf Mon Sep 17 00:00:00 2001 From: Marc Puig Date: Tue, 24 May 2022 18:58:31 +0200 Subject: [PATCH 08/13] Added feedback updates --- pages/en/supported-networks/cosmos.mdx | 32 ++++++++++---------------- 1 file changed, 12 insertions(+), 20 deletions(-) diff --git a/pages/en/supported-networks/cosmos.mdx b/pages/en/supported-networks/cosmos.mdx index e2c2e3b7ae37..39f48517f173 100644 --- a/pages/en/supported-networks/cosmos.mdx +++ b/pages/en/supported-networks/cosmos.mdx @@ -6,7 +6,7 @@ This guide is an introduction on building subgraphs indexing [Cosmos](https://do ## What are Cosmos subgraphs? -Cosmos subgraphs are a new type of subgraph that [Graph Node](https://github.com/graphprotocol/graph-node) is now able to process. This allows Cosmos-based blockchain developers to easily index on-chain events into a useful data set, easily available to query via GraphQL. +Cosmos subgraphs are a new type of subgraph that [Graph Node](https://github.com/graphprotocol/graph-node) is now able to process. This allows subgraph developers to easily index on-chain events into a useful data set, easily available to query via GraphQL. There are currently three types of handlers supported for the Cosmos subgraphs: @@ -137,7 +137,7 @@ class Event { } ``` -The types above are just the general ones that mappings use. You can find the full list of types for the Cosmos integration [here](https://github.com/graphprotocol/graph-ts/blob/main/chain/cosmos.ts). +The types above are just the general ones that mappings use. You can find the full list of types for the Cosmos integration [here](https://github.com/graphprotocol/graph-ts/blob/4c064a8118dff43b110de22c7756e5d47fcbc8df/chain/cosmos.ts). Each type of handler will receive a different type based on the relevant data. For both event and transaction handlers, a reference to the block they are contained in is passed as well. These are the exact types that are passed as a parameter to each mapping function: @@ -169,20 +169,20 @@ The first thing to do is create the subgraph in the node, this only has to be do ```bash Local deployment: -$ graph create subgraph-name --node +$ graph create subgraph-name --node http://localhost:8020 Hosted service deployment: -$ graph create subgraph-name --node https://api.thegraph.com/deploy/ +$ graph create subgraph-name --product hosted-service ``` After the subgraph has been created, it can be deployed by using the graph `deploy` CLI command: ```bash Local deployment: -$ graph deploy subgraph-name --ipfs --node +$ graph deploy subgraph-name --ipfs http://localhost:5001 --node http://localhost:8020 Hosted service deployment: -$ graph deploy subgraph-name --ipfs https://api.thegraph.com/ipfs/ --node https://api.thegraph.com/deploy/ +$ graph deploy subgraph-name --product hosted-service ``` Once your subgraph has been deployed, it will be indexed by Graph Node. You can check its progress by querying the subgraph itself at the exposed endpoint. @@ -209,18 +209,10 @@ The [Cosmos Hub blockchain](https://hub.cosmos.network/) is the first blockchain Cosmos Hub mainnet is `cosmoshub-4`. Cosmos Hub current testnet is `theta-testnet-001`.
Other Cosmos Hub networks, i.e. `cosmoshub-3`, are halted, therefore no data is provided for them. -##### Example Subgraphs - -Here are some example subgraphs for reference: - -[Cosmos Hub Block Filtering Example](https://github.com/graphprotocol/example-subgraph/tree/cosmos-block-example) - -[Cosmos Hub Validator Rewards Example](https://github.com/graphprotocol/example-subgraph/tree/cosmos-event-example) - -[Cosmos Hub Validator Delegations Example](https://github.com/graphprotocol/example-subgraph/tree/cosmos-transaction-example) - ### Osmosis +> Osmosis support in Graph Node and on the Hosted Service is in beta: please contact the graph team with any questions about building Osmosis subgraphs! + ##### What is Osmosis? [Osmosis](https://osmosis.zone/) is a decentralized, cross-chain automated market maker (AMM) protocol build on top of the Cosmos SDK. It allows users to create custom liquidity pools and trade IBC enabled tokens. You can visit the [official documentation](https://docs.osmosis.zone/) for more information. @@ -235,12 +227,12 @@ Here are some example subgraphs for reference: Osmosis mainnet is `osmosis-1`. Osmosis current testnet is `osmo-test-4`. -##### Example Subgraphs +## Example Subgraphs Here are some example subgraphs for reference: -[Osmosis Block Filtering Example](https://github.com/graphprotocol/example-subgraph/tree/osmosis-block-example) +[Block Filtering Example](https://github.com/graphprotocol/example-subgraph/tree/cosmos-block-example) -[Osmosis Validator Rewards Example](https://github.com/graphprotocol/example-subgraph/tree/osmosis-event-example) +[Validator Rewards Example](https://github.com/graphprotocol/example-subgraph/tree/cosmos-event-example) -[Osmosis Validator Delegations Example](https://github.com/graphprotocol/example-subgraph/tree/osmosis-transaction-example) +[Validator Delegations Example](https://github.com/graphprotocol/example-subgraph/tree/cosmos-transaction-example) From 20e3c1b1f7d095d2140600754e9dbcc6949d8ca9 Mon Sep 17 00:00:00 2001 From: Marc Puig Date: Wed, 25 May 2022 15:54:14 +0200 Subject: [PATCH 09/13] Update example links --- pages/en/supported-networks/cosmos.mdx | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/pages/en/supported-networks/cosmos.mdx b/pages/en/supported-networks/cosmos.mdx index 39f48517f173..41abeb261ef2 100644 --- a/pages/en/supported-networks/cosmos.mdx +++ b/pages/en/supported-networks/cosmos.mdx @@ -231,8 +231,8 @@ Osmosis mainnet is `osmosis-1`. Osmosis current testnet is `osmo-test-4`. Here are some example subgraphs for reference: -[Block Filtering Example](https://github.com/graphprotocol/example-subgraph/tree/cosmos-block-example) +[Block Filtering Example](https://github.com/graphprotocol/example-subgraph/tree/cosmos-block-filtering) -[Validator Rewards Example](https://github.com/graphprotocol/example-subgraph/tree/cosmos-event-example) +[Validator Rewards Example](https://github.com/graphprotocol/example-subgraph/tree/cosmos-validator-rewards) -[Validator Delegations Example](https://github.com/graphprotocol/example-subgraph/tree/cosmos-transaction-example) +[Validator Delegations Example](https://github.com/graphprotocol/example-subgraph/tree/cosmos-validator-delegations) From 5a01daad64ce2a5e33975c6566f80e947f01c25b Mon Sep 17 00:00:00 2001 From: Marc Puig Date: Wed, 25 May 2022 15:54:42 +0200 Subject: [PATCH 10/13] Add Osmosis example --- pages/en/supported-networks/cosmos.mdx | 2 ++ 1 file changed, 2 insertions(+) diff --git a/pages/en/supported-networks/cosmos.mdx b/pages/en/supported-networks/cosmos.mdx index 41abeb261ef2..36b7e5a557ae 100644 --- a/pages/en/supported-networks/cosmos.mdx +++ b/pages/en/supported-networks/cosmos.mdx @@ -236,3 +236,5 @@ Here are some example subgraphs for reference: [Validator Rewards Example](https://github.com/graphprotocol/example-subgraph/tree/cosmos-validator-rewards) [Validator Delegations Example](https://github.com/graphprotocol/example-subgraph/tree/cosmos-validator-delegations) + +[Osmosis Token Swaps Example](https://github.com/graphprotocol/example-subgraph/tree/osmosis-token-swaps) From 02789e2507da88dec955a287eb42fb39b15ef765 Mon Sep 17 00:00:00 2001 From: Marc Puig Date: Thu, 26 May 2022 13:18:15 +0200 Subject: [PATCH 11/13] Apply PR review changes --- pages/en/supported-networks/cosmos.mdx | 66 +++++++++++--------------- 1 file changed, 27 insertions(+), 39 deletions(-) diff --git a/pages/en/supported-networks/cosmos.mdx b/pages/en/supported-networks/cosmos.mdx index 36b7e5a557ae..ba66617eeb2b 100644 --- a/pages/en/supported-networks/cosmos.mdx +++ b/pages/en/supported-networks/cosmos.mdx @@ -6,22 +6,28 @@ This guide is an introduction on building subgraphs indexing [Cosmos](https://do ## What are Cosmos subgraphs? -Cosmos subgraphs are a new type of subgraph that [Graph Node](https://github.com/graphprotocol/graph-node) is now able to process. This allows subgraph developers to easily index on-chain events into a useful data set, easily available to query via GraphQL. +The Graph allows developers to process blockchain events and make the resulting data easily available via an open GraphQL API, known as a subgraph. [Graph Node](https://github.com/graphprotocol/graph-node) is now able to process Cosmos events, which means Cosmos developers can now build subgraphs to easily index on-chain events. There are currently three types of handlers supported for the Cosmos subgraphs: -- Block handlers. -- [Event](https://docs.cosmos.network/master/core/events.html) handlers. -- [Transaction](https://docs.cosmos.network/master/core/transactions.html) handlers. +- Block handlers: run whenever a new block is appended to the chain. +- [Event](https://docs.cosmos.network/master/core/events.html) handlers: run when a specific event is emitted. +- [Transaction](https://docs.cosmos.network/master/core/transactions.html) handlers: run when a transaction occurs. Based on the [official Cosmos documentation](https://docs.cosmos.network/): -> Events are objects that contain information about the execution of the application. They are mainly used by service providers like block explorers and wallet to track the execution of various messages and index transactions. +> Events are objects that contain information about the execution of the application. They are mainly used by service providers like block explorers and wallets to track the execution of various messages and index transactions. > Transactions are objects created by end-users to trigger state changes in the application. ## Building a Cosmos subgraph +### Subgraph Dependencies + +[graph-cli](https://github.com/graphprotocol/graph-cli) is a CLI tool to build and deploy subgraphs, version `>=0.30.0` is required in order to work with Cosmos subgraphs. + +[graph-ts](https://github.com/graphprotocol/graph-ts) is a library of subgraph-specific types, version `>=0.27.0` is required in order to work with Cosmos subgraphs. + ### Subgraph Main Components There are three main key parts or files when it comes to defining a subgraph: @@ -44,7 +50,7 @@ schema: dataSources: - kind: cosmos name: CosmosHub - network: cosmoshub-4 # This will change for each cosmos-based blockchain. In this case the example uses the CosmosHub mainnet. + network: cosmoshub-4 # This will change for each cosmos-based blockchain. In this case, the example uses the CosmosHub mainnet. source: startBlock: 0 # Required for Cosmos, set this to 0 to start indexing from chain genesis mapping: @@ -66,14 +72,14 @@ dataSources: Cosmos data sources support three types of handlers: - `blockHandlers`: run on every new block appended to the chain. The handler will receive a full block and all its data containing, among other things, all the events and transactions. -- `eventHandlers`: run on every event contained in a block that matches the event type specified in the manifest. Block data is also passed onto the mapping in order to have context of the event within the chain. -- `transactionHandlers`: run for every transaction executed. The mapping is provided with all the relevant data related to the transaction and a block abstraction that can be used to acquire context of the transaction within a block and within the chain. +- `eventHandlers`: run on every event contained in a block that matches the event type specified in the manifest. Block data is also passed onto the mapping in order to have the context of the event within the chain. +- `transactionHandlers`: run for every transaction executed. The mapping is provided with all the relevant data related to the transaction and a block abstraction that can be used to acquire the context of the transaction within a block and within the chain. Event and Transaction handlers are a way to process meaningful data from the chain without the need of processing a whole block. The data processed by them can also be found in the block handlers, since events and transactions are also part of a block, but removes the need of processing unnecessary data. ### Schema Definition -Schema definition describes the structure of the resulting subgraph database, and the relationships between entities. This is agnostic of the original data source. There are more details on subgraph schema definition [here](https://thegraph.com/docs/en/developer/create-subgraph-hosted/#the-graph-ql-schema). +Schema definition describes the structure of the resulting subgraph database and the relationships between entities. This is agnostic of the original data source. There are more details on subgraph schema definition [here](https://thegraph.com/docs/en/developer/create-subgraph-hosted/#the-graph-ql-schema). ### AssemblyScript Mappings @@ -163,29 +169,23 @@ $ graph build ## Deploying a Cosmos subgraph -When the subgraph builds successfully, it is time to deploy it to a Graph Node instance for indexing. Cosmos subgraphs can be deployed to any Graph Node on version `>=v0.26.0`. - -The first thing to do is create the subgraph in the node, this only has to be done once via the `create` CLI command: +Once your subgraph has been created, you can deploy your subgraph by using the `graph deploy` CLI command after running the `graph create` CLI command: +**Hosted Service** ```bash -Local deployment: -$ graph create subgraph-name --node http://localhost:8020 - -Hosted service deployment: -$ graph create subgraph-name --product hosted-service +graph create subgraph-name --product hosted-service # creates a subgraph on a local Graph Node (on the Hosted Service, this is done via the UI) ``` - -After the subgraph has been created, it can be deployed by using the graph `deploy` CLI command: - ```bash -Local deployment: -$ graph deploy subgraph-name --ipfs http://localhost:5001 --node http://localhost:8020 - -Hosted service deployment: -$ graph deploy subgraph-name --product hosted-service +graph deploy --node https://api.thegraph.com/deploy/ --ipfs https://api.thegraph.com/ipfs/ --access-token ``` -Once your subgraph has been deployed, it will be indexed by Graph Node. You can check its progress by querying the subgraph itself at the exposed endpoint. +**Local Graph Node (based on default configuration):** +```bash +graph create subgraph-name --node http://localhost:8020 +``` +```bash +graph deploy --node http://localhost:8020/ --ipfs http://localhost:5001 +``` ## Querying a Cosmos subgraph @@ -199,12 +199,6 @@ The GraphQL endpoint for Cosmos subgraphs is determined by the schema definition The [Cosmos Hub blockchain](https://hub.cosmos.network/) is the first blockchain in the [Cosmos](https://cosmos.network/) ecosystem. You can visit the [official documentation](https://docs.cosmos.network/) for more information. -##### Subgraph Dependencies - -[graph-cli](https://github.com/graphprotocol/graph-cli) is a CLI tool to build and deploy subgraphs, version `>=0.30.0` is required in order to work with Cosmos Hub subgraphs. - -[graph-ts](https://github.com/graphprotocol/graph-ts) is a library of subgraph-specific types, version `>=0.27.0` is required in order to work with Cosmos Hub subgraphs. - ##### Networks Cosmos Hub mainnet is `cosmoshub-4`. Cosmos Hub current testnet is `theta-testnet-001`.
Other Cosmos Hub networks, i.e. `cosmoshub-3`, are halted, therefore no data is provided for them. @@ -215,13 +209,7 @@ Cosmos Hub mainnet is `cosmoshub-4`. Cosmos Hub current testnet is `theta-testne ##### What is Osmosis? -[Osmosis](https://osmosis.zone/) is a decentralized, cross-chain automated market maker (AMM) protocol build on top of the Cosmos SDK. It allows users to create custom liquidity pools and trade IBC enabled tokens. You can visit the [official documentation](https://docs.osmosis.zone/) for more information. - -##### Subgraph Dependencies - -[graph-cli](https://github.com/graphprotocol/graph-cli) is a CLI tool to build and deploy subgraphs, version `>=0.30.0` is required in order to work with Osmosis subgraphs. - -[graph-ts](https://github.com/graphprotocol/graph-ts) is a library of subgraph-specific types, version `>=0.27.0` is required in order to work with Osmosis subgraphs. +[Osmosis](https://osmosis.zone/) is a decentralized, cross-chain automated market maker (AMM) protocol built on top of the Cosmos SDK. It allows users to create custom liquidity pools and trade IBC-enabled tokens. You can visit the [official documentation](https://docs.osmosis.zone/) for more information. ##### Networks From 2cd0a8056f8ad8f9ea16f899b07e3477ae92d208 Mon Sep 17 00:00:00 2001 From: Marc Puig Date: Fri, 27 May 2022 15:14:19 +0200 Subject: [PATCH 12/13] Update tx type from bytes to Tx --- pages/en/supported-networks/cosmos.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pages/en/supported-networks/cosmos.mdx b/pages/en/supported-networks/cosmos.mdx index ba66617eeb2b..debffc2bdfe2 100644 --- a/pages/en/supported-networks/cosmos.mdx +++ b/pages/en/supported-networks/cosmos.mdx @@ -132,7 +132,7 @@ class Header { class TxResult { height: u64 index: u32 - tx: Bytes + tx: Tx result: ResponseDeliverTx hash: Bytes } From 66efbb2d38d8978e814e20131a3f32a303e43fee Mon Sep 17 00:00:00 2001 From: Marc Puig Date: Fri, 27 May 2022 15:14:38 +0200 Subject: [PATCH 13/13] Add clarification on transaction decoding --- pages/en/supported-networks/cosmos.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pages/en/supported-networks/cosmos.mdx b/pages/en/supported-networks/cosmos.mdx index debffc2bdfe2..8689681e0695 100644 --- a/pages/en/supported-networks/cosmos.mdx +++ b/pages/en/supported-networks/cosmos.mdx @@ -151,7 +151,7 @@ Each type of handler will receive a different type based on the relevant data. F `EventData` is passed to the eventHandler. -`TransactionData` is passed to the transactionHandler. +`TransactionData` is passed to the transactionHandler. Transactions will need to be decoded in the subgraph, [here](https://github.com/graphprotocol/example-subgraph/blob/cosmos-validator-delegations/src/decoding.ts) is an example on how it can be done. ## Creating and building a Cosmos subgraph