edits (#745)

Author: idalithb

website/pages/en/about.mdx

@@ -2,46 +2,66 @@
 title: About The Graph
 ---
 
-This page will explain what The Graph is and how you can get started.
-
 ## What is The Graph?
 
-The Graph is a decentralized protocol for indexing and querying blockchain data. The Graph makes it possible to query data that is difficult to query directly.
+The Graph is a powerful decentralized protocol that enables seamless querying and indexing of blockchain data. It simplifies the complex process of querying blockchain data, making dapp development faster and easier.
+
+## Understanding the Basics
+
+Projects with complex smart contracts such as [Uniswap](https://uniswap.org/) and NFTs initiatives like [Bored Ape Yacht Club](https://boredapeyachtclub.com/) store data on the Ethereum blockchain, making it very difficult to read anything other than basic data directly from the blockchain.
+
+### Challenges Without The Graph
+
+In the case of the example listed above, Bored Ape Yacht Club, you can perform basic read operations on [the contract](https://etherscan.io/address/0xbc4ca0eda7647a8ab7c2061c2e118a18a936f13d#code). You can read the owner of a certain Ape, read the content URI of an Ape based on their ID, or read the total supply.
+
+- This can be done because these read operations are programmed directly into the smart contract itself. However, more advanced, specific, and real-world queries and operations like aggregation, search, relationships, and non-trivial filtering, **are not possible**.
+
+- For instance, if you want to inquire about Apes owned by a specific address and refine your search based on a particular characteristic, you would not be able to obtain that information by directly interacting with the contract itself.
+
+- To get more data, you would have to process every single [`transfer`](https://etherscan.io/address/0xbc4ca0eda7647a8ab7c2061c2e118a18a936f13d#code#L1746) event ever emitted, read the metadata from IPFS using the Token ID and IPFS hash, and then aggregate it.
+
+### Why is this a problem?
+
+It would take **hours or even days** for a decentralized application (dapp) running in a browser to get an answer to these simple questions.
+
+Alternatively, you have the option to set up your own server, process the transactions, store them in a database, and create an API endpoint to query the data. However, this option is [resource intensive](/network/benefits/), needs maintenance, presents a single point of failure, and breaks important security properties required for decentralization.
+
+Blockchain properties, such as finality, chain reorganizations, and uncled blocks, add complexity to the process, making it time-consuming and conceptually challenging to retrieve accurate query results from blockchain data.
 
-Projects with complex smart contracts like [Uniswap](https://uniswap.org/) and NFTs initiatives like [Bored Ape Yacht Club](https://boredapeyachtclub.com/) store data on the Ethereum blockchain, making it really difficult to read anything other than basic data directly from the blockchain.
+## The Graph Provides a Solution
 
-In the case of Bored Ape Yacht Club, we can perform basic read operations on [the contract](https://etherscan.io/address/0xbc4ca0eda7647a8ab7c2061c2e118a18a936f13d#code) like getting the owner of a certain Ape, getting the content URI of an Ape based on their ID, or the total supply. This can be done because these read operations are programmed directly into the smart contract. However, more advanced real-world queries and operations like aggregation, search, relationships, and non-trivial filtering are _not_ possible. For example, if we wanted to query for Apes that are owned by a certain address and filter by one of its characteristics, we would not be able to get that information by interacting directly with the contract itself.
+The Graph solves this challenge with a decentralized protocol that indexes and enables the efficient and high-performance querying of blockchain data. These APIs (indexed "subgraphs") can then be queried with a standard GraphQL API.
 
-To get this data, you would have to process every single [`transfer`](https://etherscan.io/address/0xbc4ca0eda7647a8ab7c2061c2e118a18a936f13d#code#L1746) event ever emitted, read the metadata from IPFS using the Token ID and IPFS hash, and then aggregate it. It would take **hours or even days** for a decentralized application (dapp) running in a browser to get an answer to these simple questions.
+Today, there is a decentralized protocol that is backed by the open source implementation of [Graph Node](https://github.com/graphprotocol/graph-node) that enables this process.
 
-You could also build out your own server, process the transactions there, save them to a database, and build an API endpoint on top of it all in order to query the data. However, this option is [resource intensive](/network/benefits/), needs maintenance, presents a single point of failure, and breaks important security properties required for decentralization.
+### How The Graph Functions
 
-**Indexing blockchain data is really, really hard.**
+Indexing blockchain data is very difficult, but The Graph makes it easy. The Graph learns how to index Ethereum data by using subgraphs. Subgraphs are custom APIs built on blockchain data that extract data from a blockchain, processes it, and stores it so that it can be seamlessly queried via GraphQL.
 
-Blockchain properties like finality, chain reorganizations, or uncled blocks complicate this process further. They make it time consuming and conceptually hard to retrieve correct query results from blockchain data.
+#### Specifics
 
-The Graph provides a solution with a decentralized protocol that indexes and enables the efficient and high-performance querying of blockchain data. These APIs (indexed "subgraphs") can then be queried with a standard GraphQL API.
+- The Graph uses subgraph descriptions, which are known as the subgraph manifest inside the subgraph.
 
-## How The Graph Works
+- The subgraph description outlines the smart contracts of interest for a subgraph, the events within those contracts to focus on, and how to map event data to the data that The Graph will store in its database.
 
-The Graph learns what and how to index Ethereum data based on subgraph descriptions, known as the subgraph manifest. The subgraph description defines the smart contracts of interest for a subgraph, the events in those contracts to pay attention to, and how to map event data to data that The Graph will store in its database.
+- When creating a subgraph, you need to write a subgraph manifest.
 
-Once you have written a `subgraph manifest`, you use the Graph CLI to store the definition in IPFS and tell the indexer to start indexing data for that subgraph.
+- After writing the `subgraph manifest`, you can use the Graph CLI to store the definition in IPFS and instruct an Indexer to start indexing data for that subgraph.
 
-This diagram gives more detail about the flow of data once a subgraph manifest has been deployed, dealing with Ethereum transactions:
+The diagram below provides more detailed information about the flow of data after a subgraph manifest has been deployed with Ethereum transactions.
 
 ![A graphic explaining how The Graph uses Graph Node to serve queries to data consumers](/img/graph-dataflow.png)
 
 The flow follows these steps:
 
-1. A dapp adds data to Ethereum through a transaction on a smart contract.
-2. The smart contract emits one or more events while processing the transaction.
-3. Graph Node continually scans Ethereum for new blocks and the data for your subgraph they may contain.
-4. Graph Node finds Ethereum events for your subgraph in these blocks and runs the mapping handlers you provided. The mapping is a WASM module that creates or updates the data entities that Graph Node stores in response to Ethereum events.
-5. The dapp queries the Graph Node for data indexed from the blockchain, using the node's [GraphQL endpoint](https://graphql.org/learn/). The Graph Node in turn translates the GraphQL queries into queries for its underlying data store in order to fetch this data, making use of the store's indexing capabilities. The dapp displays this data in a rich UI for end-users, which they use to issue new transactions on Ethereum. The cycle repeats.
+1.  A dapp adds data to Ethereum through a transaction on a smart contract.
+2.  The smart contract emits one or more events while processing the transaction.
+3.  Graph Node continually scans Ethereum for new blocks and the data for your subgraph they may contain.
+4.  Graph Node finds Ethereum events for your subgraph in these blocks and runs the mapping handlers you provided. The mapping is a WASM module that creates or updates the data entities that Graph Node stores in response to Ethereum events.
+5.  The dapp queries the Graph Node for data indexed from the blockchain, using the node's [GraphQL endpoint](https://graphql.org/learn/). The Graph Node in turn translates the GraphQL queries into queries for its underlying data store in order to fetch this data, making use of the store's indexing capabilities. The dapp displays this data in a rich UI for end-users, which they use to issue new transactions on Ethereum. The cycle repeats.
 
 ## Next Steps
 
-The following sections provide more detail on how to define subgraphs, how to deploy them, and how to query data from the indexes that Graph Node builds.
+The following sections provide a more in-depth look at subgraphs, their deployment and data querying.
 
-Before you start writing your own subgraph, you might want to have a look at [Graph Explorer](https://thegraph.com/explorer) and explore some of the subgraphs that have already been deployed. The page for each subgraph contains a playground that lets you query that subgraph's data with GraphQL.
+Before you write your own subgraph, it's recommended to explore [Graph Explorer](https://thegraph.com/explorer) and review some of the already deployed subgraphs. Each subgraph's page includes a GraphQL playground, allowing you to query its data.