diff --git a/website/pages/ar/about.mdx b/website/pages/ar/about.mdx index 809620eeabd9..9477f3788d9b 100644 --- a/website/pages/ar/about.mdx +++ b/website/pages/ar/about.mdx @@ -4,9 +4,9 @@ title: حول The Graph هذه الصفحة ستشرح The Graph وكيف يمكنك أن تبدأ. -## ما هو The Graph +## What is The Graph? -The Graph هو بروتوكول لامركزي وذلك لفهرسة البيانات والاستعلام عنها من blockchains ، بدءًا من Ethereum. حيث يمكننا من الاستعلام عن البيانات والتي من الصعب الاستعلام عنها بشكل مباشر. +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. المشاريع ذات العقود الذكية المعقدة مثل [ Uniswap ](https://uniswap.org/) و NFTs مثل [ Bored Ape Yacht Club ](https://boredapeyachtclub.com/) تقوم بتخزين البيانات على Ethereum blockchain ، مما يجعل من الصعب قراءة أي شيء بشكل مباشر عدا البيانات الأساسية من blockchain. @@ -14,7 +14,7 @@ The Graph هو بروتوكول لامركزي وذلك لفهرسة البيا للحصول على هذه البيانات، يجب معالجة كل [`التحويلات`](https://etherscan.io/address/0xbc4ca0eda7647a8ab7c2061c2e118a18a936f13d#code#L1746) التي حدثت، وقراءة البيانات الوصفية من IPFS باستخدام Token ID و IPFS hash، ومن ثم تجميعه. حتى بالنسبة لهذه الأنواع من الأسئلة البسيطة نسبيا ، قد يستغرق الأمر **ساعات أو حتى أيام** لتطبيق لامركزي (dapp) يعمل في متصفح للحصول على إجابة. -يمكنك أيضا إنشاء الخادم الخاص بك ، ومعالجة الإجراءات هناك ، وحفظها في قاعدة بيانات ، والقيام ببناء API endpoint من أجل الاستعلام عن البيانات. ومع ذلك ، فإن هذا الخيار يتطلب موارد كثيرة ، ويحتاج إلى صيانة ، ويقدم نقطة فشل واحدة ، ويكسر خصائص الأمان الهامة المطلوبة لتحقيق اللامركزية. +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. **إن فهرسة بيانات الـ blockchain أمر صعب.** @@ -30,15 +30,15 @@ The Graph يفهرس بيانات الإيثيريوم بناء على أوصا يقدم هذا الرسم البياني مزيدًا من التفاصيل حول تدفق البيانات عند نشر الـsubgraph manifest ، والتعامل مع إجراءات الـ Ethereum: -![](/img/graph-dataflow.png) +![A graphic explaining how The Graph uses Graph Node to serve queries to data consumers](/img/graph-dataflow.png) تدفق البيانات يتبع الخطوات التالية: -1. التطبيق اللامركزي يضيف البيانات إلى الـ Ethereum من خلال إجراء (transaction) على العقد الذكي. +1. A dapp adds data to Ethereum through a transaction on a smart contract. 2. العقد الذكي يصدر حدثا واحدا أو أكثر أثناء معالجة الإجراء. 3. يقوم الـ Graph Node بمسح الـ Ethereum باستمرار بحثا عن الكتل الجديدة وبيانات الـ subgraph الخاص بك. 4. يعثر الـ Graph Node على أحداث الـ Ethereum لـ subgraph الخاص بك في هذه الكتل ويقوم بتشغيل mapping handlers التي قدمتها. الـ mapping عبارة عن وحدة WASM والتي تقوم بإنشاء أو تحديث البيانات التي يخزنها Graph Node استجابة لأحداث الـ Ethereum. -5. التطبيق اللامركزي يستعلم عن الـ Graph Node للبيانات المفهرسة من الـ blockchain ، باستخدام node's [ GraphQL endpoint](https://graphql.org/learn/). يقوم الـ The Graph Node بدوره بترجمة استعلامات الـ GraphQL إلى استعلامات عن مخزن البيانات الأساسي الخاص به من أجل جلب هذه البيانات ، والاستفادة من إمكانات فهرسة المخزن. التطبيق اللامركزي يعرض تلك البيانات في واجهة مستخدم ، والتي يمكن للمستخدمين من خلالها إصدار إجراءات جديدة على Ethereum. والدورة تتكرر. +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. ## الخطوات التالية diff --git a/website/pages/ar/arbitrum-faq.mdx b/website/pages/ar/arbitrum-faq.mdx new file mode 100644 index 000000000000..04e3dd638490 --- /dev/null +++ b/website/pages/ar/arbitrum-faq.mdx @@ -0,0 +1,80 @@ +--- +title: Arbitrum FAQ +--- + +Click [here](#billing-on-arbitrum-faqs) if you would like to skip to the Arbitrum Billing FAQs. + +## General FAQs + +### Why is The Graph implementing an L2 Solution? + +By scaling The Graph on L2, network participants can expect: + +- 26x savings on gas fees + +- Faster transaction speed + +- Secured by Ethereum + +The protocol allows network participants to interact more frequently at a reduced cost in gas fees. This enables Indexers to index a greater number of subgraphs, allows developers to deploy and upgrade subgraphs with greater ease, enables Delegators to delegate GRT with increased frequency, and gives Curators the ability to add signal to a larger number of subgraphs. + +The Graph community [decided](https://forum.thegraph.com/t/gip-0031-arbitrum-grt-bridge/3305) to move forward with Arbitrum last year. + +### What do I need to do to use The Graph on L2? + +Users bridge their GRT and ETH  using one of the following methods: + +- [The Graph Bridge on Arbitrum](https://bridge.arbitrum.io/?l2ChainId=42161) +- [TransferTo](https://transferto.xyz/swap) +- [Connext Bridge](https://bridge.connext.network/) +- [Hop Exchange](https://app.hop.exchange/#/send?token=ETH) + +To take advantage of using The Graph on L2, use this dropdown switcher to toggle between chains. + +{/* Insert an image */} ![Dropdown switcher to toggle Arbitrum](/img/arbitrum-screenshot-toggle.png) + +### As a subgraph developer, data consumer, Indexer, Curator, or Delegator, what do I need to do now? + +There is no immediate action required. + +Core developer teams are working to create migration helpers that will make it significantly easier to move delegation, curation, and subgraphs to Arbitrum. Network participants can expect migration helpers to be available in April 2023. + +The Graph community can also expect indexing rewards to be enabled on Arbitrum in February or March 2023. + +### If I would like to participate in the network on L2, what should I do? + +Please help [test the network](https://testnet.thegraph.com/explorer) on L2 and report feedback about your experience in [Discord](https://discord.gg/vtvv7FP). + +### Are there any risks associated with scaling the network to L2? + +All smart contracts have been thoroughly [audited](https://github.com/graphprotocol/contracts/blob/dev/audits/OpenZeppelin/2022-07-graph-arbitrum-bridge-audit.pdf). + +Everything has been tested thoroughly, and a contingency plan is in place to ensure a safe and seamless transition. Details can be found [here](https://forum.thegraph.com/t/gip-0037-the-graph-arbitrum-deployment-with-linear-rewards-minted-in-l2/3551#risks-and-security-considerations-20). + +### Will existing subgraphs on Ethereum continue to work? + +Yes, The Graph Network contracts will operate in parallel on both Ethereum and Arbitrum until moving fully to Arbitrum at a later date. + +### Will GRT have a new smart contract deployed on Arbitrum? + +Yes, GRT has an additional [smart contract on Arbitrum](https://arbiscan.io/address/0x9623063377ad1b27544c965ccd7342f7ea7e88c7). However, the Ethereum mainnet [GRT contract](https://etherscan.io/token/0xc944e90c64b2c07662a292be6244bdf05cda44a7) will remain operational. + +## Billing on Arbitrum FAQs + +### What do I need to do about the GRT in my billing balance? + +Nothing! Your GRT has been securely migrated to Arbitrum and is being used to pay for queries as you read this. + +### How do I know my funds have migrated securely to Arbitrum? + +All GRT billing balances have already been successfully migrated to Arbitrum. You can view the billing contract on Arbitrum [here](https://arbiscan.io/address/0x1B07D3344188908Fb6DEcEac381f3eE63C48477a). + +### How do I know the Arbitrum bridge is secure? + +The bridge has been [heavily audited](https://code4rena.com/contests/2022-10-the-graph-l2-bridge-contest) to ensure safety and security for all users. + +### What do I need to do if I'm adding fresh GRT from my Ethereum mainnet wallet? + +Adding GRT to your Arbitrum billing balance can be done with a one-click experience in [Subgraph Studio](https://thegraph.com/studio/). You'll be able to easily bridge your GRT to Arbitrum and fill your API keys in one transaction. + +Visit the [Billing page](https://thegraph.com/docs/en/billing/) for more detailed instructions on adding, withdrawing, or acquiring GRT. diff --git a/website/pages/ar/billing.mdx b/website/pages/ar/billing.mdx new file mode 100644 index 000000000000..3c21e5de1cdc --- /dev/null +++ b/website/pages/ar/billing.mdx @@ -0,0 +1,158 @@ +--- +title: Billing +--- + +> Invoices are generated on a weekly basis. + +There are two options for paying for your query fees: + +- [Paying with fiat currency with Banxa](#billing-with-banxa) +- [Paying with crypto wallet](#billing-on-arbitrum) + +## Billing with Banxa + +Banxa enables you to bypass the need for an exchange and pay for your query fees using the fiat currency of your choice. The fiat currency will be converted to GRT, added to your account balance on the billing contract, and used to pay for queries associated with your API keys. + +There may be KYC requirements depending on the regulations in your country. For more information about KYC, please visit [Banxa's FAQ page](https://docs.banxa.com/docs/faqs). + +You can learn more about Banxa by reading their [documentation](https://docs.banxa.com/docs). + +### Paying for query fees with Banxa + +1. Select “Pay with Card” option in [Subgraph Studio](https://thegraph.com/studio/billing/?show=Deposit). +2. Enter the amount of GRT to be added to your account balance. +3. Click the 'Continue with Banxa' button. +4. Enter necessary banking information on Banxa including payment method & fiat currency of choice. +5. Finish the transaction. + +It may take up to 10 minutes to complete the transaction. Once the transaction is confirmed, the purchased GRT will automatically be added to your account balance on Arbitrum. + +## Billing on Arbitrum + +While The Graph protocol operates on Ethereum Mainnet, [the billing contract](https://arbiscan.io/address/0x1b07d3344188908fb6deceac381f3ee63c48477a) lives on the [Arbitrum](https://arbitrum.io/) network to reduce transaction times and cost. You'll be required to pay the query fees generated from your API keys. Using the billing contract, you'll be able to: + +- Add and withdraw GRT from your account balance. +- Keep track of your balances based on how much GRT you have added to your account balance, how much you have removed, and your invoices. +- Automatically pay invoices based on query fees generated, as long as there is enough GRT in your account balance. + +### Adding GRT using a crypto wallet + +> This section is written assuming you already have GRT in your crypto wallet, and you're on Ethereum mainnet. If you don't have GRT, you can learn how to get GRT [here](#getting-grt). + +1. Go to the [Subgraph Studio Billing page](https://thegraph.com/studio/billing/). + +2. Click on the "Connect Wallet" button on the top right corner of the page. You'll be redirected to the wallet selection page. Select your wallet and click on "Connect". + +3. Click the 'Add GRT' button at the center of the page. A side panel will appear. + +4. Enter the amount of GRT you want to add to your account balance. You can also select the maximum amount of GRT you want to add to your account balance by clicking on the "Max" button. + +5. Click 'Allow GRT Access' to allow the Subgraph Studio to access your GRT. Sign the associated transaction in your wallet. This will not cost any gas. + +6. Click 'Add GRT to account balance' to add the GRT to your account balance. Sign the associated transaction in your wallet. This will cost gas. + +7. Once the transaction is confirmed, you'll see the GRT added to your account balance within an hour. + +### Withdrawing GRT using a crypto wallet + +> This section is written assuming you have deposited GRT into your account balance on [Subgraph Studio](https://thegraph.com/studio/billing/) and that you're on the Arbitrum network. + +1. Go to the [Subgraph Studio Billing page](https://thegraph.com/studio/billing/). + +2. Click on the "Connect Wallet" button on the top right corner of the page. Select your wallet and click on "Connect". + +3. Click the dropdown next to the 'Add GRT' button at the center of the page. Select withdraw GRT. A side panel will appear. + +4. Enter the amount of GRT you would like to withdraw. + +5. Click 'Withdraw GRT' to withdraw the GRT from your account balance. Sign the associated transaction in your wallet. This will cost gas. The GRT will be sent to your Arbitrum wallet. + +6. Once the transaction is confirmed, you'll see the GRT withdrawn from your account balance in your Arbitrum wallet. + +### Adding GRT using a multisig wallet + +1. Go to the [Subgraph Studio Billing page](https://thegraph.com/studio/billing/). + +2. Click on the "Connect Wallet" button on the top right corner of the page. Select your wallet and click on "Connect". If you're using [Gnosis-Safe](https://gnosis-safe.io/), you'll be able to connect your multisig as well as your signing wallet. Then, sign the associated message. This will not cost any gas. + +3. Click the 'Add GRT' button at the center of the page. A side panel will appear. + +4. Once the transaction is confirmed, you'll see the GRT added to your account balance within an hour. + +### Withdrawing GRT using a multisig wallet + +> This section is written assuming you have deposited GRT into your account balance on [Subgraph Studio](https://thegraph.com/studio/billing/) and that you're on Ethereum mainnet. + +1. Go to the [Subgraph Studio Billing page](https://thegraph.com/studio/billing/). + +2. Click on the "Connect Wallet" button on the top right corner of the page. Select your wallet and click on "Connect". + +3. Click the dropdown next to the 'Add GRT' button at the center of the page. Select withdraw GRT. A side panel will appear. + +4. Enter the amount of GRT you would like to withdraw. Specify the receiving wallet which will receive the GRT from this transaction. The GRT will be sent to the receiving wallet on Arbitrum. + +5. Click 'Withdraw GRT' to withdraw the GRT from your account balance. Sign the associated transaction in your wallet. This will cost gas. + +6. Once the transaction is confirmed, you'll see the GRT added to your Arbitrum wallet within an hour. + +## Getting GRT + +This section will show you how to get GRT to pay for query fees. + +### Coinbase + +This will be a step by step guide for purchasing GRT on Coinbase. + +1. Go to [Coinbase](https://www.coinbase.com/) and create an account. +2. Once you have created an account, you will need to verify your identity through a process known as KYC (or Know Your Customer). This is a standard procedure for all centralized or custodial crypto exchanges. +3. Once you have verified your identity, you can purchase GRT. You can do this by clicking on the "Buy/Sell" button on the top right of the page. +4. Select the currency you want to purchase. Select GRT. +5. Select the payment method. Select your preferred payment method. +6. Select the amount of GRT you want to purchase. +7. Review your purchase. Review your purchase and click "Buy GRT". +8. Confirm your purchase. Confirm your purchase and you will have successfully purchased GRT. +9. You can transfer the GRT from your account to your crypto wallet such as [MetaMask](https://metamask.io/). + - To transfer the GRT to your crypto wallet, click on the "Accounts" button on the top right of the page. + - Click on the "Send" button next to the GRT account. + - Enter the amount of GRT you want to send and the wallet address you want to send it to. + - Click "Continue" and confirm your transaction. -Please note that for larger purchase amounts, Coinbase may require you to wait 7-10 days before transferring the full amount to a crypto wallet. + +You can learn more about getting GRT on Coinbase [here](https://help.coinbase.com/en/coinbase/trading-and-funding/buying-selling-or-converting-crypto/how-do-i-buy-digital-currency). + +### Binance + +This will be a step by step guide for purchasing GRT on Binance. + +1. Go to [Binance](https://www.binance.com/en) and create an account. +2. Once you have created an account, you will need to verify your identity through a process known as KYC (or Know Your Customer). This is a standard procedure for all centralized or custodial crypto exchanges. +3. Once you have verified your identity, you can purchase GRT. You can do this by clicking on the "Buy Now" button on the homepage banner. +4. You will be taken to a page where you can select the currency you want to purchase. Select GRT. +5. Select your preferred payment method. You'll be able to pay with different fiat currencies such as Euros, US Dollars, and more. +6. Select the amount of GRT you want to purchase. +7. Review your purchase and click "Buy GRT". +8. Confirm your purchase and you will be able to see your GRT in your Binance Spot Wallet. +9. You can withdraw the GRT from your account to your crypto wallet such as [MetaMask](https://metamask.io/). + - [To withdraw](https://www.binance.com/en/blog/ecosystem/how-to-transfer-crypto-from-binance-to-trust-wallet-8305050796630181570) the GRT to your crypto wallet, add your crypto wallet's address to the withdrawel whitelist. + - Click on the "wallet" button, click withdraw, and select GRT. + - Enter the amount of GRT you want to send and the whitelisted wallet address you want to send it to. + - Click "Continue" and confirm your transaction. + +You can learn more about getting GRT on Binance [here](https://www.binance.com/en/support/faq/how-to-buy-cryptocurrency-on-binance-homepage-400c38f5e0cd4b46a1d0805c296b5582). + +### Uniswap + +This is how you can purchase GRT on Uniswap. + +1. Go to [Uniswap](https://app.uniswap.org/#/swap) and connect your wallet. +2. Select the token you want to swap from. Select ETH. +3. Select the token you want to swap to. Select GRT. + - Make sure you're swapping for the correct token. The GRT smart contract address is: `0xc944E90C64B2c07662A292be6244BDf05Cda44a7` +4. Enter the amount of ETH you want to swap. +5. Click "Swap". +6. Confirm the transaction in your wallet and you wait for the transaction to process. + +You can learn more about getting GRT on Uniswap [here](https://support.uniswap.org/hc/en-us/articles/8370549680909-How-to-Swap-Tokens-). + +## Arbitrum Bridge + +The billing contract is only designed to bridge GRT from Ethereum mainnet to the Arbitrum network. If you'd like to transfer your GRT from Arbitrum back to Ethereum mainnet, you'll need to use the [Arbitrum Bridge](https://bridge.arbitrum.io/?l2ChainId=42161). diff --git a/website/pages/ar/cookbook/arweave.mdx b/website/pages/ar/cookbook/arweave.mdx index 6fa67f40c7a0..87f10495ba1e 100644 --- a/website/pages/ar/cookbook/arweave.mdx +++ b/website/pages/ar/cookbook/arweave.mdx @@ -46,14 +46,14 @@ The requirements for Arweave subgraphs are covered by the [existing documentatio This is the logic that determines how data should be retrieved and stored when someone interacts with the data sources you are listening to. The data gets translated and is stored based off the schema you have listed. -During subgraph development there are two key commands: +أثناء تطوير الـ الرسم البياني الفرعي هناك أمران رئيسان: ``` $ graph codegen # generates types from the schema file identified in the manifest $ graph build # generates Web Assembly from the AssemblyScript files, and prepares all the subgraph files in a /build folder ``` -## 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 an Arweave subgraph: @@ -89,21 +89,21 @@ dataSources: Arweave data sources support two types of handlers: - `blockHandlers` - Run on every new Arweave block. No source.owner is required. -- `transactionHandlers` - Run on every transaction where the data source's source.owner is the owner. Note that only exact matches are processed. Currently an owner is required for `transactionHandlers`. +- `transactionHandlers` - Run on every transaction where the data source's `source.owner` is the owner. Currently an owner is required for `transactionHandlers`, if users want to process all transactions they should provide "" as the `source.owner` -> The source.owner is the owner's Public Key, rather than the owner's address. +> The source.owner can be the owner's address, or their Public Key. > Transactions are the building blocks of the Arweave permaweb and they are objects created by end-users. > Note: [Bundlr](https://bundlr.network/) transactions are not supported yet. -## 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 the subgraph schema definition [here](/developing/creating-a-subgraph/#the-graphql-schema). -## AssemblyScript Mappings +## أسيمبلي سكريبت التعيينات -The handlers for processing events are written in [AssemblyScript](https://www.assemblyscript.org/). +تمت كتابة المعالجات الخاصة بمعالجة الأحداث بـ[ أسيمبلي سكريبت ](https://www.assemblyscript.org/). Arweave indexing introduces Arweave-specific data types to the [AssemblyScript API](/developing/assemblyscript-api/). @@ -162,13 +162,13 @@ graph deploy --node https://api.thegraph.com/deploy/ --ipfs https://api.thegraph The GraphQL endpoint for Arweave subgraphs is determined by the schema definition, with the existing API interface. Please visit the [GraphQL API documentation](/querying/graphql-api/) for more information. -## Example Subgraphs +## مثال الفرعية رسم بياني Here is an example subgraph for reference: -- [Example subgraph for Arweave](https://github.com/graphprotocol/example-subgraph/tree/arweave-blocks-transactions) +- [Example subgraph for Arweave](https://github.com/graphprotocol/example-subgraphs/tree/main/arweave/blocks-transactions) -## FAQ +## الأسئلة الشائعة ### Can a subgraph index Arweave and other chains? @@ -184,7 +184,7 @@ This is not currently supported. ### How can I filter transactions to a specific account? -The source.owner is the user's public key, rather than the account address. We are working on adding account filtering support. +The source.owner can be the user's public key or account address. ### What is the current encryption format? @@ -194,46 +194,46 @@ The following `bytesToBase64(bytes: Uint8Array, urlSafe: boolean): string` helpe ``` const base64Alphabet = [ - "A", "B", "C", "D", "E", "F", "G", "H", "I", "J", "K", "L", "M", - "N", "O", "P", "Q", "R", "S", "T", "U", "V", "W", "X", "Y", "Z", - "a", "b", "c", "d", "e", "f", "g", "h", "i", "j", "k", "l", "m", - "n", "o", "p", "q", "r", "s", "t", "u", "v", "w", "x", "y", "z", - "0", "1", "2", "3", "4", "5", "6", "7", "8", "9", "+", "/" + "A", "B", "C", "D", "E", "F", "G", "H", "I", "J", "K", "L", "M", + "N", "O", "P", "Q", "R", "S", "T", "U", "V", "W", "X", "Y", "Z", + "a", "b", "c", "d", "e", "f", "g", "h", "i", "j", "k", "l", "m", + "n", "o", "p", "q", "r", "s", "t", "u", "v", "w", "x", "y", "z", + "0", "1", "2", "3", "4", "5", "6", "7", "8", "9", "+", "/" ]; const base64UrlAlphabet = [ - "A", "B", "C", "D", "E", "F", "G", "H", "I", "J", "K", "L", "M", - "N", "O", "P", "Q", "R", "S", "T", "U", "V", "W", "X", "Y", "Z", - "a", "b", "c", "d", "e", "f", "g", "h", "i", "j", "k", "l", "m", - "n", "o", "p", "q", "r", "s", "t", "u", "v", "w", "x", "y", "z", - "0", "1", "2", "3", "4", "5", "6", "7", "8", "9", "-", "_" + "A", "B", "C", "D", "E", "F", "G", "H", "I", "J", "K", "L", "M", + "N", "O", "P", "Q", "R", "S", "T", "U", "V", "W", "X", "Y", "Z", + "a", "b", "c", "d", "e", "f", "g", "h", "i", "j", "k", "l", "m", + "n", "o", "p", "q", "r", "s", "t", "u", "v", "w", "x", "y", "z", + "0", "1", "2", "3", "4", "5", "6", "7", "8", "9", "-", "_" ]; function bytesToBase64(bytes: Uint8Array, urlSafe: boolean): string { - let alphabet = urlSafe? base64UrlAlphabet : base64Alphabet; - - let result = '', i: i32, l = bytes.length; - for (i = 2; i < l; i += 3) { - result += alphabet[bytes[i - 2] >> 2]; - result += alphabet[((bytes[i - 2] & 0x03) << 4) | (bytes[i - 1] >> 4)]; - result += alphabet[((bytes[i - 1] & 0x0F) << 2) | (bytes[i] >> 6)]; - result += alphabet[bytes[i] & 0x3F]; - } - if (i === l + 1) { // 1 octet yet to write - result += alphabet[bytes[i - 2] >> 2]; - result += alphabet[(bytes[i - 2] & 0x03) << 4]; - if (!urlSafe) { - result += "=="; - } - } - if (!urlSafe && i === l) { // 2 octets yet to write - result += alphabet[bytes[i - 2] >> 2]; - result += alphabet[((bytes[i - 2] & 0x03) << 4) | (bytes[i - 1] >> 4)]; - result += alphabet[(bytes[i - 1] & 0x0F) << 2]; - if (!urlSafe) { - result += "="; - } - } - return result; + let alphabet = urlSafe? base64UrlAlphabet : base64Alphabet; + + let result = '', i: i32, l = bytes.length; + for (i = 2; i < l; i += 3) { + result += alphabet[bytes[i - 2] >> 2]; + result += alphabet[((bytes[i - 2] & 0x03) << 4) | (bytes[i - 1] >> 4)]; + result += alphabet[((bytes[i - 1] & 0x0F) << 2) | (bytes[i] >> 6)]; + result += alphabet[bytes[i] & 0x3F]; + } + if (i === l + 1) { // 1 octet yet to write + result += alphabet[bytes[i - 2] >> 2]; + result += alphabet[(bytes[i - 2] & 0x03) << 4]; + if (!urlSafe) { + result += "=="; + } + } + if (!urlSafe && i === l) { // 2 octets yet to write + result += alphabet[bytes[i - 2] >> 2]; + result += alphabet[((bytes[i - 2] & 0x03) << 4) | (bytes[i - 1] >> 4)]; + result += alphabet[(bytes[i - 1] & 0x0F) << 2]; + if (!urlSafe) { + result += "="; + } + } + return result; } ``` diff --git a/website/pages/ar/cookbook/base-testnet.mdx b/website/pages/ar/cookbook/base-testnet.mdx new file mode 100644 index 000000000000..465e022a9c57 --- /dev/null +++ b/website/pages/ar/cookbook/base-testnet.mdx @@ -0,0 +1,112 @@ +--- +title: Building Subgraphs on Base +--- + +This guide will quickly take you through how to initialize, create, and deploy your subgraph on Base testnet. + +What you'll need: + +- A Base testnet contract address +- A crypto wallet (e.g. MetaMask or Coinbase Wallet) + +## Subgraph Studio + +### 1. قم بتثبيت رسم بياني CLI + +The Graph CLI (>=v0.41.0) is written in JavaScript and you will need to have either `npm` or `yarn` installed to use it. + +```sh +# NPM +npm install -g @graphprotocol/graph-cli + +# Yarn +yarn global add @graphprotocol/graph-cli +``` + +### 2. Create your subgraph in the Subgraph Studio + +Go to the [Subgraph Studio](https://thegraph.com/studio/) and connect your crypto wallet. + +Once connected, click "Create a Subgraph" and enter a name for your subgraph. + +Select "Base (testnet)" as the indexed blockchain and click Create Subgraph. + +### 3. Initialize your Subgraph + +> You can find specific commands for your subgraph in the Subgraph Studio. + +Make sure that the graph-cli is updated to latest (above 0.41.0) + +```sh +graph --version +``` + +ابدأ الرسم البياني الفرعي الخاص بك من عقد قائم. + +```sh +graph init --studio +``` + +Your subgraph slug is an identifier for your subgraph. The CLI tool will walk you through the steps for creating a subgraph, including: + +- Protocol: ethereum +- Subgraph slug: `` +- Directory to create the subgraph in: `` +- Ethereum network: base-testnet \_ Contract address: `` +- Start block (optional) +- Contract name: `` +- Yes/no to indexing events (yes means your subgraph will be bootstrapped with entities in the schema and simple mappings for emitted events) + +### 3. اكتب الفرعية رسم بياني الخاص بك + +> If emitted events are the only thing you want to index, then no additional work is required, and you can skip to the next step. + +The previous command creates a scaffold subgraph that you can use as a starting point for building your subgraph. When making changes to the subgraph, you will mainly work with three files: + +- Manifest (subgraph.yaml) - The manifest defines what datasources your subgraphs will index. Make sure to add `base-testnet` as the network name in manifest file to deploy your subgraph on Base testnet. +- Schema (schema.graphql) - يحدد مخطط GraphQL البيانات التي ترغب في استردادها من الفرعية رسم بياني. +- (AssemblyScript Mappings (mapping.ts - هذا هو الكود الذي يترجم البيانات من مصادر البيانات الخاصة بك إلى الكيانات المحددة في المخطط. + +If you want to index additional data, you will need extend the manifest, schema and mappings. + +For more information on how to write your subgraph, see [Creating a Subgraph](/developing/creating-a-subgraph). + +### النشر على الفرعية رسم بياني ستوديو + +Before you can deploy your subgraph, you will need to authenticate with the Subgraph Studio. You can do this by running the following command: + +Authenticate the subgraph on studio + +``` +graph auth --studio +``` + +Next, enter your subgraph's directory. + +``` + cd +``` + +Build your subgraph with the following command: + +```` +``` +graph codegen && graph build +``` +```` + +Finally, you can deploy your subgraph using this command: + +```` +``` +graph deploy --studio +``` +```` + +### 5. Query your subgraph + +Once your subgraph is deployed, you can query it from your dapp using the `Development Query URL` in the Subgraph Studio. + +Note - Studio API is rate-limited. Hence should preferably be used for development and testing. + +To learn more about querying data from your subgraph, see the [Querying a Subgraph](/querying/querying-the-graph) page. diff --git a/website/pages/ar/cookbook/cosmos.mdx b/website/pages/ar/cookbook/cosmos.mdx new file mode 100644 index 000000000000..16f3aece075a --- /dev/null +++ b/website/pages/ar/cookbook/cosmos.mdx @@ -0,0 +1,259 @@ +--- +title: Building Subgraphs on Cosmos +--- + +This guide is an introduction on building subgraphs indexing [Cosmos](https://docs.cosmos.network/) based blockchains. + +## What are Cosmos subgraphs? + +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 four types of handlers supported in Cosmos subgraphs: + +- **Block handlers** run whenever a new block is appended to the chain. +- **Event handlers** run when a specific event is emitted. +- **Transaction handlers** run when a transaction occurs. +- **Message handlers** run when a specific message occurs. + +Based on the [official Cosmos documentation](https://docs.cosmos.network/): + +> [Events](https://docs.cosmos.network/main/core/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](https://docs.cosmos.network/main/core/transactions) are objects created by end-users to trigger state changes in the application. + +> [Messages](https://docs.cosmos.network/main/core/transactions#messages) are module-specific objects that trigger state transitions within the scope of the module they belong to. + +Even though all data can be accessed with a block handler, other handlers enable subgraph developers to process data in a much more granular way. + +## 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 key parts 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 blockchain data to the entities defined in your schema. + +### تعريف الفرعية رسم بياني يظهر + +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 +description: Cosmos Subgraph Example +schema: + file: ./schema.graphql # link to the schema file +dataSources: + - kind: cosmos + name: CosmosHub + network: cosmoshub-4 # This will change for each cosmos-based blockchain. In this case, the example uses the Cosmos Hub mainnet. + 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 + messageHandlers: + - message: /cosmos.staking.v1beta1.MsgDelegate # the type of a message + handler: handleMsgDelegate # the function name in the mapping file + 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 chain in the Cosmos ecosystem. In the example, the Cosmos Hub mainnet is used. + +### تعريف المخطط + +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](/developing/creating-a-subgraph/#the-graph-ql-schema). + +### أسيمبلي سكريبت التعيينات + +تمت كتابة المعالجات الخاصة بمعالجة الأحداث بـ[ أسيمبلي سكريبت ](https://www.assemblyscript.org/). + +Cosmos indexing introduces Cosmos-specific data types to the [AssemblyScript API](/developing/assemblyscript-api/). + +```tsx +class Block { + header: Header + evidence: EvidenceList + resultBeginBlock: ResponseBeginBlock + resultEndBlock: ResponseEndBlock + transactions: Array + validatorUpdates: Array +} + +class EventData { + event: Event + block: HeaderOnlyBlock + tx: TransactionContext +} + +class TransactionData { + tx: TxResult + block: HeaderOnlyBlock +} + +class MessageData { + message: Any + block: HeaderOnlyBlock + tx: TransactionContext +} + +class TransactionContext { + hash: Bytes + index: u32 + code: u32 + gasWanted: i64 + gasUsed: i64 +} + +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: Tx + result: ResponseDeliverTx + hash: Bytes +} + +class Event { + eventType: string + attributes: Array +} + +class Any { + typeUrl: string + value: Bytes +} +``` + +Each handler type comes with its own data structure that is passed as an argument to a mapping function. + +- Block handlers receive the `Block` type. +- Event handlers receive the `EventData` type. +- Transaction handlers receive the `TransactionData` type. +- Message handlers receive the `MessageData` type. + +As a part of `MessageData` the message handler receives a transaction context, which contains the most important information about a transaction that encompasses a message. The transaction context is also available in the `EventData` type, but only when the corresponding event is associated with a transaction. Additionally, all handlers receive a reference to a block (`HeaderOnlyBlock`). + +You can find the full list of types for the Cosmos integration [here](https://github.com/graphprotocol/graph-ts/blob/4c064a8118dff43b110de22c7756e5d47fcbc8df/chain/cosmos.ts). + +### Message decoding + +It's important to note that Cosmos messages are chain-specific and they are passed to a subgraph in the form of a serialized [Protocol Buffers](https://developers.google.com/protocol-buffers/) payload. As a result, the message data needs to be decoded in a mapping function before it can be processed. + +An example of how to decode message data in a subgraph can be found [here](https://github.com/graphprotocol/example-subgraphs/blob/main/cosmos/validator-delegations/src/decoding.ts). + +## 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: + +```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 subgraph + +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: + +**الخدمة المستضافة** + +```bash +graph create account/subgraph-name --product hosted-service +``` + +```bash +graph deploy account/subgraph-name --product hosted-service +``` + +**رسم بياني العقدة المحلية (على أساس التكوين الافتراضي):** + +```bash +graph create subgraph-name --node http://localhost:8020 +``` + +```bash +graph deploy subgraph-name --node http://localhost:8020/ --ipfs http://localhost:5001 +``` + +## Querying a Cosmos subgraph + +The GraphQL endpoint for Cosmos subgraphs is determined by the schema definition, with the existing API interface. Please visit the [GraphQL API documentation](/querying/graphql-api/) for more information. + +## 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. + +#### الشبكات + +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. + +### 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 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. + +#### الشبكات + +Osmosis mainnet is `osmosis-1`. Osmosis current testnet is `osmo-test-4`. + +## مثال الفرعية رسم بياني + +فيما يلي بعض مثال الفرعية رسم بياني للرجوع إليها: + +[Block Filtering Example](https://github.com/graphprotocol/example-subgraphs/tree/main/cosmos/block-filtering) + +[Validator Rewards Example](https://github.com/graphprotocol/example-subgraphs/tree/main/cosmos/validator-rewards) + +[Validator Delegations Example](https://github.com/graphprotocol/example-subgraphs/tree/main/cosmos/validator-delegations) + +[Osmosis Token Swaps Example](https://github.com/graphprotocol/example-subgraphs/tree/main/cosmos/osmosis-token-swaps) diff --git a/website/pages/ar/cookbook/grafting.mdx b/website/pages/ar/cookbook/grafting.mdx new file mode 100644 index 000000000000..a8b65e88bb21 --- /dev/null +++ b/website/pages/ar/cookbook/grafting.mdx @@ -0,0 +1,186 @@ +--- +title: Replace a Contract and Keep its History With Grafting +--- + +In this guide, you will learn how to build and deploy new subgraphs by grafting existing subgraphs. + +## What is Grafting? + +Grafting reuses the data from an existing subgraph and starts indexing it at a later block. This is useful during development to get past simple errors in the mappings quickly or to temporarily get an existing subgraph working again after it has failed. Also, it can be used when adding a feature to a subgraph that takes long to index from scratch. + +The grafted subgraph can use a GraphQL schema that is not identical to the one of the base subgraph, but merely compatible with it. It has to be a valid subgraph schema in its own right, but may deviate from the base subgraph's schema in the following ways: + +- يضيف أو يزيل أنواع الكيانات +- يزيل الصفات من أنواع الكيانات +- يضيف صفات لاغية لأنواع الكيانات +- يحول صفات غير لاغية إلى صفات لاغية +- يضيف قيما إلى تعداد +- يضيف أو يزيل الواجهات +- يغير للكيانات التي يتم تنفيذ الواجهة لها + +For more information, you can check: + +- [گرافتنگ](https://thegraph.com/docs/en/developing/creating-a-subgraph#grafting-onto-existing-subgraphs) + +In this tutorial, we will be covering a basic usecase. We will replace an existing contract with an identical contract (with a new address, but the same code). Then, graft the existing subgraph onto the "base" subgraph that tracks the new contract. + +## Building an Existing Subgraph + +Building subgraphs is an essential part of The Graph, described more in depth [here](http://localhost:3000/en/cookbook/quick-start/). To be able to build and deploy the existing subgraph used in this tutorial, the following repo is provided: + +- [Subgraph example repo](https://github.com/t-proctor/grafting-tutorial) + +> Note: The contract used in the subgraph was taken from the following [Hackathon Starterkit](https://github.com/schmidsi/hackathon-starterkit). + +## تعريف الفرعية رسم بياني يظهر + +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 that you will use: + +```yaml +specVersion: 0.0.4 +schema: + file: ./schema.graphql +dataSources: + - kind: ethereum + name: Lock + network: goerli + source: + address: '0x4Ed995e775D3629b0566D2279f058729Ae6EA493' + abi: Lock + startBlock: 7674603 + mapping: + kind: ethereum/events + apiVersion: 0.0.6 + language: wasm/assemblyscript + entities: + - Withdrawal + abis: + - name: Lock + file: ./abis/Lock.json + eventHandlers: + - event: Withdrawal(uint256,uint256) + handler: handleWithdrawal + file: ./src/lock.ts +``` + +- The `Lock` data source is the abi and contract address we will get when we compile and deploy the contract +- The network should correspond to a indexed network being queried. Since we're running on Goerli testnet, the network is `goerli` +- The `mapping` section defines the triggers of interest and the functions that should be run in response to those triggers. In this case, we are listening for the `Withdrawal` event and calling the `handleWithdrawal` function when it is emitted. + +## Grafting Manifest Definition + +Grafting requires adding two new items to the original subgraph manifest: + +```yaml +--- +features: + - grafting # feature name +graft: + base: Qm... # subgraph ID of base subgraph + block: 1502122 # block number +``` + +- `features:` is a list of all used [feature names](developing/creating-a-subgraph/#experimental-features). +- `graft:` is a map of the `base` subgraph and the block to graft on to. The `block` is the block number to start indexing from. The Graph will copy the data of the base subgraph up to and including the given block and then continue indexing the new subgraph from that block on. + +The `base` and `block` values can be found by deploying two subgraphs: one for the base indexing and one with grafting + +## Deploying the Base Subgraph + +1. Go to [The Graph Studio UI](https://thegraph.com/studio/) and create a subgraph on Goerli testnet called `graft-example` +2. Follow the directions in the `AUTH & DEPLOY` section on your subgraph page in the `graft-example` folder from the repo +3. Once finished, verify the subgraph is indexing properly. If you run the following command in The Graph Playground + +```graphql +{ + withdrawals(first: 5) { + id + amount + when + } +} +``` + +It returns something like this: + +``` +{ + "data": { + "withdrawals": [ + { + "id": "0x13098b538a61837e9f29b32fb40527bbbe63c9120c250242b02b69bb42c287e5-5", + "amount": "0", + "when": "1664367528" + }, + { + "id": "0x800c92fcc0edbd26f74e19ad058c62008a47c7789f2064023b987028343dd498-3", + "amount": "0", + "when": "1664367648" + } + ] + } +} +``` + +Once you have verified the subgraph is indexing properly, you can quickly update the subgraph with grafting. + +## Deploying the Grafting Subgraph + +The graft replacement subgraph.yaml will have a new contract address. This could happen when you update your dapp, redeploy a contract, etc. + +1. Go to [The Graph Studio UI](https://thegraph.com/studio/) and create a subgraph on Goerli testnet called `graft-replacement` +2. Create a new manifest. The `subgraph.yaml` for `graph-replacement` contains a different contract address and new information about how it should graft. These are the `block` of the [last event emitted](https://goerli.etherscan.io/tx/0x800c92fcc0edbd26f74e19ad058c62008a47c7789f2064023b987028343dd498) you care about by the old contract and the `base` of the old subgraph. The `base` subgraph ID is the `Deployment ID` of your original `graph-example` subgraph. You can find this in The Graph Studio UI. +3. Follow the directions in the `AUTH & DEPLOY` section on your subgraph page in the `graft-replacement` folder from the repo +4. Once finished, verify the subgraph is indexing properly. If you run the following command in The Graph Playground + +```graphql +{ + withdrawals(first: 5) { + id + amount + when + } +} +``` + +It should return the following: + +``` +{ + "data": { + "withdrawals": [ + { + "id": "0x13098b538a61837e9f29b32fb40527bbbe63c9120c250242b02b69bb42c287e5-5", + "amount": "0", + "when": "1664367528" + }, + { + "id": "0x800c92fcc0edbd26f74e19ad058c62008a47c7789f2064023b987028343dd498-3", + "amount": "0", + "when": "1664367648" + }, + { + "id": "0xb4010e4c76f86762beb997a13cf020231778eaf7c64fa3b7794971a5e6b343d3-22", + "amount": "0", + "when": "1664371512" + } + ] + } +} +``` + +You can see that the `graft-replacement` subgraph is indexing from older `graph-example` data and newer data from the new contract address. The original contract emitted two `Withdrawal` events, [Event 1](https://goerli.etherscan.io/tx/0x800c92fcc0edbd26f74e19ad058c62008a47c7789f2064023b987028343dd498) and [Event 2](https://goerli.etherscan.io/address/0x4ed995e775d3629b0566d2279f058729ae6ea493). The new contract emitted one `Withdrawal` after, [Event 3](https://goerli.etherscan.io/tx/0xb4010e4c76f86762beb997a13cf020231778eaf7c64fa3b7794971a5e6b343d3). The two previously indexed transactions (Event 1 and 2) and the new transaction (Event 3) were combined together in the `graft-replacement` subgraph. + +Congrats! You have succesfully grafted a subgraph onto another subgraph. + +## مصادر إضافية + +If you want more experience with grafting, here's a few examples for popular contracts: + +- [Curve](https://github.com/messari/subgraphs/blob/master/subgraphs/curve-finance/protocols/curve-finance/templates/curve.template.yaml) +- [ERC-721](https://github.com/messari/subgraphs/blob/master/subgraphs/erc721-metadata/subgraph.yaml) +- [Uniswap](https://github.com/messari/subgraphs/blob/master/subgraphs/uniswap-v3/protocols/uniswap-v3/config/templates/uniswap.v3.template.yaml), + +To become even more of a Graph expert, consider learning about other ways to handle changes in underlying datasources. Alternatives like [Data Source Templates](developing/creating-a-subgraph/#data-source-templates) can achieve similar results + +> Note: A lot of material from this article was taken from the previously published [Arweave article](/cookbook/arweave/) diff --git a/website/pages/ar/cookbook/migrating-a-subgraph.mdx b/website/pages/ar/cookbook/migrating-a-subgraph.mdx index b89d62758e65..634b1ae09cc9 100644 --- a/website/pages/ar/cookbook/migrating-a-subgraph.mdx +++ b/website/pages/ar/cookbook/migrating-a-subgraph.mdx @@ -1,22 +1,22 @@ --- -title: ترحيل Subgraph موجود إلى شبكة The Graph +title: ترحيل الفرعيةرسمبياني موجود إلى شبكة رسم بياني --- ## مقدمة -هذا دليل حول كيفية ترحيل الـ subgraph الخاص بك من Hosted Service إلى شبكة The Graph. لقد نجح الترحيل إلى شبكة The Graph لمشاريع مثل Opyn و UMA و mStable و Audius و PoolTogether و Livepeer و RAI و Enzyme و DODO و Opyn و Pickle و BadgerDAO ، وكلها تعتمد على البيانات التي يقدمها المفهرسون على الشبكة. ويوجد الآن أكثر من 200 subgraphs حي على شبكة The Graph، مولدة بذلك رسوم استعلام وفهرسة بيانات web3 بشكل نشط. +This is a guide on how to migrate your subgraph from the Hosted Service to The Graph's decentralized network. Migration to The Graph Network has been successful for projects like Opyn, UMA, mStable, Audius, PoolTogether, Livepeer, RAI, Enzyme, DODO, Pickle, and BadgerDAO all of which are relying on data served by Indexers on the network. There are now over 700 subgraphs live on The Graph's decentralized network, generating query fees and actively indexing web3 data. -عملية الترحيل سريعة وسيستفيد الـ subgraphs الخاض بك إلى الأبد من الموثوقية والأداء اللذين يمكنك الحصول عليهما فقط على شبكة The Graph. +عملية الترحيل سريعة وسيستفيد الـ الفرعيةرسمبياني الخاض بك إلى الأبد من الموثوقية والأداء اللذين يمكنك الحصول عليهما فقط على شبكة رسم بياني. -### متى لا تقوم بعملية الترحيل(Migration)؟ +### Assumptions -إذا كان الـ subgraph الخاص بك: +- You have already deployed a subgraph on the hosted service. +- القراف الفرعي يقوم بفهرسة سلسلة متوفرة (أو متوفرة في النسخة التجريبية) على شبكة القراف. +- The subgraph does not have IPFS or full-text search dependencies (these are not fully supported on the decentralized network yet). -- يفهرس [IPFS](https://ipfs.io/). -- يستخدم [حقول بحث عن نص-كامل(full-text)](/developing/creating-a-subgraph/#defining-fulltext-search-fields). -- يفهرس(chains) السلاسل عدا Ethereum mainnet. +## ترحيل الفرعيةرسمبياني موجود إلى شبكة رسم بياني -### ترحيل Subgraph موجود إلى شبكة The Graph +> You can find specific commands for your subgraph in the [Subgraph Studio](https://thegraph.com/studio/). 1. احصل على أحدث إصدار من graph-cli المثبت: @@ -28,26 +28,29 @@ npm install -g @graphprotocol/graph-cli yarn global add @graphprotocol/graph-cli ``` -2. أنشئ subgraph على [ Subgraph Studio ](https://thegraph.com/studio/). يمكن العثور على شرح حول كيفية القيام بذلك في [ مستندات Subgraph Studio ](/deploying/subgraph-studio) وفي \[ هذا الفيديو التعليمي\](https://www. youtube. com/watch؟ v = HfDgC2oNnwo). -3. داخل مستودع (repository) الـ subgraph للمشروع الرئيسي ، قم بمصادقة الـ subgraph للنشر والبناء على الاستوديو: +Make sure your `apiVersion` in subgraph.yaml is `0.0.5` or greater. + +2. Inside the subgraph's main project repository, authenticate the subgraph to deploy and build on the studio: ```sh graph auth --studio ``` -4. أنشئ الملفات وقم ببناء الـ subgraph: +3. أنشئ الملفات وقم ببناء الـ الفرعيةرسمبياني: ```sh graph codegen && graph build ``` -5. انشر الـ subgraph في الاستوديو. يمكنك العثور على`` الخاص بك في واجهة مستخدم الـ Studio ، والذي يعتمد على اسم الـ subgraph الخاص بك. +If your subgraph has build errors, refer to the [AssemblyScript Migration Guide](/release-notes/assemblyscript-migration-guide/). + +4. Sign into [Subgraph Studio](https://thegraph.com/studio/) with your wallet and deploy the subgraph. You can find your `` in the Studio UI, which is based on the name of your subgraph. ```sh - graph deploy --studio +graph deploy --studio ``` -6. قم باختبار الاستعلامات في Studio's playground. فيما يلي بعض الأمثلة لـ [Sushi - Mainnet Exchange Subgraph](https://thegraph.com/explorer/subgraph?id=0x4bb4c1b0745ef7b4642feeccd0740dec417ca0a0-0&view=Playground): +5. قم باختبار الاستعلامات في الاستوديو playground. فيما يلي بعض الأمثلة لـ [سوشي - mainnet تبادل الفرعية رسم بياني](https://thegraph.com/explorer/subgraph?id=0x4bb4c1b0745ef7b4642feeccd0740dec417ca0a0-0&view=Playground): ```sh { @@ -64,92 +67,153 @@ graph codegen && graph build } ``` -7. املأ الوصف والتفاصيل الخاصة بالـ subgraph الخاص بك واختر ما يصل إلى 3 فئات. وقم برفع صورة المشروع في الاستوديو إذا كنت ترغب في ذلك. -8. انشر الـ subgraph على شبكة The Graph بالضغط على زر "Publish". +6. At this point, your subgraph is now deployed on Subgraph Studio, but not yet published to the decentralized network. You can now test the subgraph to make sure it is working as intended using the temporary query URL as seen on top of the right column above. As this name already suggests, this is a temporary URL and should not be used in production. + +- Publishing is an on-chain action and will require gas to be paid for in Ethereum - see an example transaction [here](https://etherscan.io/tx/0xd0c3fa0bc035703c9ba1ce40c1862559b9c5b6ea1198b3320871d535aa0de87b). Prices are roughly around 0.0425 ETH at 100 gwei. +- Any time you need to upgrade your subgraph, you will be charged an upgrade fee. Upgrading is just publishing another version of your existing subgraph on-chain. Because this incurs a cost, it is highly recommended to deploy and test your subgraph on Goerli before deploying to mainnet. It can, in some cases, also require some GRT if there is no signal on that subgraph. In the case there is signal/curation on that subgraph version (using auto-migrate), the taxes will be split. + +7. Publish the subgraph on The Graph's decentralized network by hitting the "Publish" button. + +And that's it! After you are done publishing, you'll be able to view your subgraphs live on the decentralized network via [The Graph Explorer](https://thegraph.com/explorer). + +لا تتردد في الاستفادة من [ #قناة القيمين ](https://discord.gg/rC8rBuRtbH) على دسکورد لإعلام القيمين بأن الـ الفرعيةرسمبياني الخاص بك جاهز للإشارة إليه. وسيكون من المفيد أيضا أن تشارك حجم الاستعلام المتوقع معهم. بالتالي، يمكنهم تقدير مقدار GRT الذي يجب أن يشيروا إليه في الـ الفرعيةرسمبياني الخاص بك. + +### Create an API key + +You can generate an API key in Subgraph Studio [here](https://thegraph.com/studio/apikeys/). + +![API key creation page](/img/api-image.png) + +At the end of each week, an invoice will be generated based on the query fees that have been incurred during this period. This invoice will be paid automatically using the GRT available in your balance. Your balance will be updated after the cost of your query fees are withdrawn. Query fees are paid in GRT via the Arbitrum network. You will need to add GRT to the Arbitrum billing contract to enable your API key via the following steps: + +- Purchase GRT on an exchange of your choice. +- Send the GRT to your wallet. +- On the Billing page in Studio, click on Add GRT. + +![Add GRT in billing](/img/Add-GRT-New-Page.png) + +- Follow the steps to add your GRT to your billing balance. +- Your GRT will be automatically bridged to the Arbitrum network and added to your billing balance. + +![Billing pane](/img/New-Billing-Pane.png) + +> Note: see the [official billing page](../billing.mdx) for full instructions on adding GRT to your billing balance. + +### Securing your API key -- تذكر أن النشر هو إجراء on-chain وسيتطلب دفع ثمن الغاز كـ Ethereum - انظر مثال لإجراء [ هنا ](https://etherscan.io/tx/0xd0c3fa0bc035703c9ba1ce40c1862559b9c5b6ea1198b3320871d535aa0de87b). الأسعار حوالي 0.0425 ETH عند 100 gwei. -- في أي وقت تحتاج فيه إلى ترقية الـ subgraph الخاص بك ، ستدفع رسوم الترقية. تذكر أن الترقية هي مجرد نشر إصدار آخر من subgraph on-chain موجود. ولأن هذا ينطوي على تكلفة ، فيوصى بشدة بنشر واختبار الـ subgraph الخاص بك على Rinkeby قبل النشر على mainnet. في بعض الحالات ، قد تتطلب أيضا بعض GRT إذا لم تكن هناك إشارة على هذا الـ subgraph. وفي حالة وجود إشارة / تنسيق في إصدار هذا الـ subgraph (باستخدام الترحيل التلقائي) ، سيتم تقسيم الضرائب. +It is recommended that you secure the API by limiting its usage in two ways: -وهذا كل شيء! بعد الانتهاء من النشر ، ستتمكن من رؤية الـ subgraphs الخاص بك على الشبكة عبر [The Graph Explorer](https://thegraph.com/explorer). +1. Authorized Subgraphs +2. Authorized Domain + +You can secure your API key [here](https://thegraph.com/studio/apikeys/test/). + +![Subgraph lockdown page](/img/subgraph-lockdown.png) + +### Querying your subgraph on the decentralized network + +Now you can check the indexing status of the Indexers on the network in Graph Explorer (example [here](https://thegraph.com/explorer/subgraph?id=S9ihna8D733WTEShJ1KctSTCvY1VJ7gdVwhUujq4Ejo&view=Indexers)). The green line at the top indicates that at the time of posting 8 Indexers successfully indexed that subgraph. Also in the Indexer tab you can see which Indexers picked up your subgraph. + +![Rocket Pool subgraph](/img/rocket-pool-subgraph.png) + +As soon as the first Indexer has fully indexed your subgraph you can start to query the subgraph on the decentralized network. In order to retrieve the query URL for your subgraph, you can copy/paste it by clicking on the symbol next to the query URL. You will see something like this: + +`https://gateway.thegraph.com/api/[api-key]/subgraphs/id/S9ihna8D733WTEShJ1KctSTCvY1VJ7gdVwhUujq4Ejo` + +Important: Make sure to replace `[api-key]` with an actual API key generated in the section above. + +You can now use that Query URL in your dapp to send your GraphQL requests to. + +Congratulations! You are now a pioneer of decentralization! + +> Note: Due to the distributed nature of the network it might be the case that different Indexers have indexed up to different blocks. In order to only receive fresh data you can specify the minimum block an Indexer has to have indexed in order to serve your query with the block: `{ number_gte: $minBlock }` field argument as shown in the example below: + +```graphql +{ + stakers(block: { number_gte: 14486109 }) { + id + } +} +``` -لا تتردد في الاستفادة من [ قناة Curators# ](https://discord.gg/rC8rBuRtbH) على Discord لإعلام المنسقين (Curators) بأن الـ subgraph الخاص بك جاهز للإشارة إليه. وسيكون من المفيد أيضا أن تشارك حجم الاستعلام المتوقع معهم. بالتالي، يمكنهم تقدير مقدار GRT الذي يجب أن يشيروا إليه في الـ subgraph الخاص بك. +More information about the nature of the network and how to handle re-orgs are described in the documentation article [Distributed Systems](/querying/distributed-systems/). -### ترقية Subgraph على الشبكة +## الترقية الرسم البياني الفرعي على شبكة -إذا كنت ترغب في ترقية subgraph موجود على الشبكة ، فيمكنك القيام بذلك عن طريق نشر إصدار جديد من الـ subgraph الخاص بك على Subgraph Studio باستخدام Graph CLI. +إذا كنت ترغب في ترقية الفرعيةرسمبياني موجود على الشبكة ، فيمكنك القيام بذلك عن طريق نشر إصدار جديد من الـ الفرعية رسمبياني الخاص بك على الفرعية رسمبياني الاستوديو باستخدام Graph CLI. -1. قم بإجراء تغييرات على الـ subgraph الحالي الخاص بك. إنها لفكرة جيدة أن تقوم باختبار الإصلاحات الصغيرة في Subgraph Studio بالنشر على Rinkeby. +1. Make changes to your current subgraph. A good idea is to test small fixes on the Subgraph Studio by publishing to Goerli. 2. انشر ما يلي وحدد الإصدار الجديد في الأمر (مثل v0.0.1 ، v0.0.2 ، إلخ): ```sh graph deploy --studio ``` -3. اختبر الإصدار الجديد في Subgraph Studio من خلال الاستعلام في الـ playground -4. انشر الإصدار الجديد على شبكة The Graph. تذكر أن هذا يتطلب غاز (كما هو موضح في القسم أعلاه). +3. اختبر الإصدار الجديد في الفرعية رسم بياني ستوديو من خلال الاستعلام في الـ playground +4. انشر الإصدار الجديد على شبكة رسم بياني. تذكر أن هذا يتطلب غاز (كما هو موضح في القسم أعلاه). ### رسوم ترقية المالك -الترقية تتطلب ترحيل GRT من الإصدار القديم للـ subgraph إلى الإصدار الجديد. وهذا يعني أنه لكل ترقية ، سيتم إنشاء منحنى ربط جديد (للمزيد عن منحنيات الترابط [ هنا ](/network/curating#bonding-curve-101)). +An upgrade requires GRT to be migrated from the old version of the subgraph to the new version. This means that for every upgrade, a new bonding curve will be created (more on bonding curves [here](/network/curating#bonding-curve-101)). -يفرض منحنى الترابط الجديد ضريبة تنسيق 2.5٪ على جميع GRT التي يتم ترحيلها إلى الإصدار الجديد. يجب على المالك دفع 50٪ من هذا أو 1.25٪. علما أن 1.25٪ المتبقية يتم استحواذها من قبل جميع المنسقين كرسوم. وتم وضع هذا التصميم لمنع مالك الـ subgraph من استنزاف جميع أموال المنسقين من خلال استدعاءات الترقية المتكررة. إذا لم يكن هناك نشاط تنسيق ، فسيتعين عليك دفع 100 GRT كحد أدنى للإشارة إلى الـ subgraph الخاص بك. +The new bonding curve charges the 2.5% curation tax on all GRT being migrated to the new version. The owner must pay 50% of this or 1.25%. The other 1.25% is absorbed by all the curators as a fee. This incentive design is in place to prevent an owner of a subgraph from being able to drain all their curator's funds with recursive upgrade calls. If there is no curation activity, you will have to pay a minimum of 100 GRT in order to signal your own subgraph. -كمثال على ذلك ، هذه هي الحالة فقط إذا كان الـ subgraph الخاص بك يتم تنسيقه بشكل نشط: +كمثال على ذلك ، هذه هي الحالة فقط إذا كان الـ الفرعية رسم بياني الخاص بك يتم تنسيقه بشكل نشط: -- تتم الإشارة بـ 100،000 GRT باستخدام الترحيل التلقائي في v1 لـ subgraph +- تتم الإشارة بـ 100،000 GRT باستخدام الترحيل التلقائي في v1 لـ الفرعية رسم بياني - المالك يقوم بالترقية إلى v2. يتم ترحيل 100،000 GRT إلى منحنى ربط جديد ، حيث يتم وضع 97،500 GRT في المنحنى الجديد وحرق 2،500 GRT - ثم قام المالك بحرق 1250 GRT لدفع نصف الرسوم. يجب أن يملك المالك ذلك في محفظته قبل الترقية ، وإلا فلن تنجح الترقية. يحدث هذا في نفس إجراء الترقية. -_بينما تتم هذه الآلية حاليا على الشبكة ، يناقش المجتمع حاليا طرقا لتقليل تكلفة الترقيات لمطوري الـ subgraph._ +_بينما تتم هذه الآلية حاليا على الشبكة ، يناقش المجتمع حاليا طرقا لتقليل تكلفة الترقيات لمطوري الـ الفرعية رسم بياني._ -### الحفاظ على إصدار مستقر من Subgraph +### الحفاظ على إصدار مستقر من الفرعية رسم بياني -إذا كنت تقوم بإجراء الكثير من التغييرات على الـ subgraph الخاص بك ، فليس من الجيد ترقيته باستمرار والتعرض لتكاليف الترقية. ويعد الاحتفاظ بإصدار مستقر من الـ subgraph أمرًا بالغ الأهمية ، ليس فقط من منظور التكلفة ، ولكن أيضًا حتى يشعر المفهرسون بالثقة في أوقات المزامنة. يجب وضع علامة (flag) على المفهرسين عندما تنوي الترقية بحيث لا تتأثر أوقات مزامنة المفهرس. لا تتردد في الاستفادة من قناة [ Indexers# ](https://discord.gg/rC8rBuRtbH) على Discord للسماح للمفهرسين بمعرفة متى تقوم بإنشاء إصدارات لـ subgraphs الخاص بك. +If you're making a lot of changes to your subgraph, it is not a good idea to continually upgrade it and front the upgrade costs. Maintaining a stable and consistent version of your subgraph is critical, not only from the cost perspective but also so that Indexers can feel confident in their syncing times. Indexers should be flagged when you plan for an upgrade so that Indexer syncing times do not get impacted. Feel free to leverage the [#Indexers channel](https://discord.gg/rC8rBuRtbH) on Discord to let Indexers know when you're versioning your subgraphs. -الـ Subgraphs عبارة عن APIs مفتوحة يستخدمها المطورون الخارجيون. تحتاج APIs المفتوحة إلى اتباع معايير صارمة حتى لا تتسبب في تعطيل تطبيقات المطورين الخارجيين. وفي شبكة The Graph ، يجب على مطور الـ subgraph أخذ المفهرسين بعين الاعتبار والوقت المستغرق لمزامنة الـ subgraph الجديد ** بالإضافة إلى ** المطورين الآخرين الذين يستخدمون الـ subgraphs الخاصة بهم. +الـ الفرعيةرسم بياني عبارة عن APIs مفتوحة يستخدمها المطورون الخارجيون. تحتاج APIs المفتوحة إلى اتباع معايير صارمة حتى لا تتسبب في تعطيل تطبيقات المطورين الخارجيين. وفي شبكة رسم بياني ، يجب على مطور الـ الفرعية رسم بياني أخذ المفهرسين بعين الاعتبار والوقت المستغرق لمزامنة الـ الفرعيةرسم بياني الجديد ** بالإضافة إلى ** المطورين الآخرين الذين يستخدمون الـ الفرعيةرسم بياني الخاصة بهم. -### تحديث البيانات الوصفية (Metadata) لـ Subgraph +### تحديث البيانات الوصفية للرسم البياني الفرعي -يمكنك تحديث البيانات الوصفية لـ subgraphs الخاص بك دون الحاجة إلى نشر إصدار جديد. تتضمن البيانات الوصفية اسم الـ subgraph والصورة والوصف و URL لموقع الويب و URL كود المصدر والفئات. يمكن للمطورين القيام بذلك عن طريق تحديث تفاصيل الـ subgraph الخاصة بهم في Subgraph Studio حيث يمكنك تعديل جميع الحقول الملائمة. +يمكنك تحديث البيانات الوصفية لـ الفرعيةرسم بياني الخاص بك دون الحاجة إلى نشر إصدار جديد. تتضمن البيانات الوصفية اسم الـ الفرعيةرسم بياني والصورة والوصف و URL لموقع الويب و URL كود المصدر والفئات. يمكن للمطورين القيام بذلك عن طريق تحديث تفاصيل الـ الفرعيةرسم بياني الخاصة بهم في الفرعية رسم بياني الاستوديو حيث يمكنك تعديل جميع الحقول الملائمة. -تأكد من تحديد **Update Subgraph Details in Explorer** وانقر على **Save**. إذا تم تحديد هذا الخيار ، فسيتم إنشاء إجراء on-chain والتي تقوم بتحديث تفاصيل الـ subgraph في Explorer دون الحاجة إلى نشر(publish) إصدار جديد عند قيامك بنشر(deployment) جديد. +تأكد من تحديد **تحديث تفاصيل الرسم البياني الفرعي بتنسيق إكسبلورر** وانقر على **يحفظ**. إذا تم تحديد هذا الخيار ، فسيتم إنشاء إجراء على السلسلة والتي تقوم بتحديث تفاصيل الـ الفرعية رسم بياني في إكسبلورر دون الحاجة إلى نشر إصدار جديد عند قيامك بنشر جديد. -## أفضل الممارسات لنشر Subgraph على شبكة The Graph +## أفضل الممارسات لنشر الفرعية رسم بياني على شبكة رسم بياني -1. الاستفادة من اسم ENS لتطوير الـ Subgraph: +1. الرفع من اسم ENS لتطوير الـ الفرعية رسم بياني: - قم بإعداد ENS الخاص بك [https://app.ens.domains/](https://app.ens.domains/) - أضف اسم ENS الخاص بك إلى إعداداتك [هنا](https://thegraph.com/explorer/settings?view=display-name). -2. كلما تم ملء البروفايل الخاص بك ، كلما زادت فرص فهرسة الـ subgraphs الخاصة بك وتنسيقها. +2. كلما تم ملء البروفايل الخاص بك ، كلما زادت فرص فهرسة الـ الفرعية رسم بياني الخاصة بك وتنسيقها. -## إيقاف Subgraph على شبكة The Graph +## إيقاف الفرعية رسم بياني على شبكة رسم بياني -اتبع الخطوات [هنا](/managing/deprecating-a-subgraph) لإيقاف الـ subgraph الخاص بك وإزالته من شبكة The Graph. +Follow the steps [here](/managing/deprecating-a-subgraph) to deprecate your subgraph and remove it from The Graph Network. -## الاستعلام عن Subgraph + الفوترة على شبكة The Graph +## الاستعلام عن الفرعية رسم بياني + الفوترة على شبكة رسم بياني -تم إعداد الخدمة المستضافة (Hosted Service) للسماح للمطورين بنشر الـ subgraphs الخاصة بهم دون أي قيود. +تم إعداد الخدمة المستضافة للسماح للمطورين بنشر الـ الفرعية رسم بياني الخاصة بهم دون أي قيود. -لكي تصبح شبكة The Graph لا مركزية حقًا ، يجب دفع رسوم الاستعلام كجزء أساسي من حوافز البروتوكول. لمزيد من المعلومات حول الاشتراك في APIs ودفع رسوم الاستعلام ، راجع وثائق الفوترة [ هنا ](/querying/billing). +In order for The Graph Network to truly be decentralized, query fees have to be paid as a core part of the protocol's incentives. For more information on subscribing to APIs and paying the query fees, check out billing documentation [here](/billing/). ### تقدير رسوم الاستعلام على الشبكة على الرغم من أن هذه ليست ميزة موجودة في واجهة مستخدم المنتج ، إلا أنه يمكنك تعيين الحد الأقصى لميزانيتك لكل استعلام وذلك عن طريق أخذ المبلغ الذي ترغب في دفعه شهريًا وتقسيمه على حجم الاستعلام المتوقع. -أثناء اتخاذ قرار بشأن ميزانية الاستعلام الخاصة بك ، ليس هناك ما يضمن أن المفهرس سيكون على استعداد لتقديم الاستعلامات بهذا السعر. إذا تمكن الـ Gateway من مطابقتك مع مفهرس يرغب في تقديم استعلام بالسعر الذي ترغب في دفعه أو أقل ، فستدفع الفرق بين ميزانيتك **و** سعرهم. ونتيجة لذلك ، فإن سعر الاستعلام المنخفض يقلل من عدد المفهرسين المتاحين لك ، مما قد يؤثر على جودة الخدمة التي تتلقاها. من المفيد أن يكون لديك رسوم استعلام مرتفع ، لأن ذلك قد يجذب التنسيق وأسماء كبيرة من المفهرسين إلى الـ subgraph الخاص بك. +أثناء اتخاذ قرار بشأن ميزانية الاستعلام الخاصة بك ، ليس هناك ما يضمن أن المفهرس سيكون على استعداد لتقديم الاستعلامات بهذا السعر. إذا تمكن الـ بوابة من مطابقتك مع مفهرس يرغب في تقديم استعلام بالسعر الذي ترغب في دفعه أو أقل ، فستدفع الفرق بين ميزانيتك **و** سعرهم. ونتيجة لذلك ، فإن سعر الاستعلام المنخفض يقلل من عدد المفهرسين المتاحين لك ، مما قد يؤثر على جودة الخدمة التي تتلقاها. من المفيد أن يكون لديك رسوم استعلام مرتفع ، لأن ذلك قد يجذب التنسيق وأسماء كبيرة من المفهرسين إلى الـ الفرعية رسم بياني الخاص بك. -تذكر أنه سوق ديناميكي ومتنامي ، ولكن كيفية تفاعلك معه هو تحت سيطرتك. لا يوجد حد أقصى أو أدنى للسعر في البروتوكول أو البوابات(Gateways). على سبيل المثال ، يمكنك إلقاء نظرة أدناه على السعر الذي دفعه عدد قليل من الـ dapps على الشبكة (على أساس أسبوعي). انظر للعمود الأخير ، والذي يعرض رسوم الاستعلام كـ GRT. على سبيل المثال ، [Pickle Finance](https://www.pickle.finance/) لديه 8 طلبات في الثانية ودفع 2.4 GRT لأسبوع واحد. +Remember that it's a dynamic and growing market, but how you interact with it is in your control. There is no maximum or minimum price specified in the protocol or the Gateways. For example, you can look at the price paid by a few of the dapps on the network (on a per-week basis), below. See the last column, which shows query fees in GRT. ![رسوم الاستعلام](/img/QueryFee.png) ## مصادر إضافية -إذا كنت لا تزال في حيرة من أمرك ، فلا تخف! راجع المصادر التالية أو شاهد الفيديو الخاص بنا حول ترحيل الـ subgraphs إلى الشبكة اللامركزية أدناه: +إذا كنت لا تزال في حيرة من أمرك ، فلا تخف! راجع المصادر التالية أو شاهد الفيديو الخاص بنا حول ترحيل الـ الفرعية رسم بياني إلى الشبكة اللامركزية أدناه: -- [عقود شبكة The Graph](https://github.com/graphprotocol/contracts) -- [ عقد التنسيق](https://github.com/graphprotocol/contracts/blob/dev/contracts/curation/Curation.sol) - العقد الأساسي الذي تلتف حوله GNS +- [عقود شبكة رسم بياني](https://github.com/graphprotocol/contracts) +- [ عقد التنظيم](https://github.com/graphprotocol/contracts/blob/dev/contracts/curation/Curation.sol) - العقد الأساسي الذي تلتف حوله GNS - العنوان - `0x8fe00a685bcb3b2cc296ff6ffeab10aca4ce1538` -- [وثائق Subgraph Studio](/deploying/subgraph-studio) +- [توثيق الفرعية رسم بياني ستوديو](/deploying/subgraph-studio) diff --git a/website/pages/ar/cookbook/near.mdx b/website/pages/ar/cookbook/near.mdx index f382e8b08e61..080f1db192b6 100644 --- a/website/pages/ar/cookbook/near.mdx +++ b/website/pages/ar/cookbook/near.mdx @@ -1,14 +1,14 @@ --- -title: بناء Subgraphs على NEAR +title: بناء الفرعيةرسم بياني على NEAR --- -> يتوفر دعم NEAR في Graph Node وفي الخدمة المستضافة(Hosted Service) في مرحلة beta: يرجى التواصل بـ near@thegraph.com إذا كانت لديك أي أسئلة حول بناء subgraphs NEAR! +> يتوفر دعم NEAR في عقدة الرسم البياني وفي الخدمة المستضافة في مرحلة تجريبية: يرجى التواصل مع near@thegraph.com إذا كانت لديك أي أسئلة حول إنشاء NEAR الفرعية رسم بياني! هذا الدليل عبارة عن مقدمة لبناء subgraphs تقوم بفهرسة العقود الذكية على [NEAR blockchain](https://docs.near.org/). ## ما هو NEAR؟ -[NEAR](https://near.org/) هي عبارة عن منصة عقد ذكي لبناء تطبيقات لامركزية. قم بزيارة [ الوثائق الرسمية ](https://docs.near.org/docs/concepts/new-to-near) لمزيد من المعلومات. +[NEAR](https://near.org/) is a smart contract platform for building decentralized applications. Visit the [official documentation](https://docs.near.org/docs/concepts/new-to-near) for more information. ## ماهي NEAR subgraphs؟ @@ -25,32 +25,32 @@ title: بناء Subgraphs على NEAR ## بناء NEAR Subgraph -`graphprotocol/graph-cli@` هو أداة سطر أوامر لبناء ونشر الـ subgraphs. +`@graphprotocol/graph-cli` is a command-line tool for building and deploying subgraphs. `graphprotocol/graph-ts@` هي مكتبة لأنواع خاصة بـ subgraph. تطوير NEAR subgraph يتطلب `graph-cli` بإصدار أعلى من `0.23.0` و `graph-ts` بإصدار أعلى من `0.23.0`. -> بناء NEAR subgraph يشبه إلى حد كبير بناء subgraph يقوم بفهرسة الـ Ethereum. +> Building a NEAR subgraph is very similar to building a subgraph that indexes Ethereum. هناك ثلاثة جوانب لتعريف الـ subgraph: **subgraph.yaml:** الـ subgraph manifest ، وتحديد مصادر البيانات ذات الأهمية ، وكيف يجب أن تتم معالجتها.علما أن NEAR هو `نوع` جديد لمصدر البيانات. -**schema.graphql:** مخطط يقوم بتعريف البيانات المخزنة لـ subgraph الخاص بك ، وكيفية الاستعلام عنها عبر GraphQL. وتتم تغطية متطلبات NEAR subgraphs بواسطة [ الوثائق الحالية ](/developing/creating-a-subgraph#the-graphql-schema). +**schema.graphql:** a schema file that defines what data is stored for your subgraph, and how to query it via GraphQL. The requirements for NEAR subgraphs are covered by [the existing documentation](/developing/creating-a-subgraph#the-graphql-schema). -**AssemblyScript Mappings:** هو [AssemblyScript كود ](/developing/assemblyscript-api) والذي يترجم من بيانات الحدث إلى الكيانات المعرفة في مخططك. دعم NEAR يقدم أنواع بيانات خاصة بـ NEAR ووظيفة تحليل JSON جديدة. +**AssemblyScript Mappings:** [AssemblyScript code](/developing/assemblyscript-api) that translates from the event data to the entities defined in your schema. NEAR support introduces NEAR-specific data types and new JSON parsing functionality. -أثناء تطوير الـ subgraph ، هناك أمران رئيسيان: +أثناء تطوير الـ الرسم البياني الفرعي هناك أمران رئيسان: ```bash $ graph codegen # generates types from the schema file identified in the manifest $ graph build # generates Web Assembly from the AssemblyScript files, and prepares all the subgraph files in a /build folder ``` -### تعريف Subgraph Manifest +### تعريف الفرعية رسم بياني يظهر -Subgraph manifest (`subgraph.yaml`) يحدد مصادر البيانات لـ subgraph ، والمشغلات(triggers) ذات الأهمية ، والدوال التي يجب تشغيلها استجابة لتلك المشغلات. انظر أدناه للحصول على مثال لـ subgraph manifest لـ NEAR 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 NEAR subgraph: ```yaml specVersion: 0.0.2 @@ -74,22 +74,33 @@ dataSources: - NEAR subgraphs يقدم `نوعا ` جديدا من مصدر بيانات (`near`) - يجب أن يتوافق الـ `network` مع شبكة على Graph Node المضيفة. في الخدمة المستضافة ، الشبكة الرئيسية لـ NEAR هي `near-mainnet` ، وشبكة NEAR's testnet هي `near-testnet` -- مصادر بيانات NEAR تقدم حقلًا اختياريًا `source.account` ، وهو ID يمكن قراءته و يتوافق مع [ حساب NEAR ](https://docs.near.org/docs/concepts/account). ويمكن أن يكون ذلك حسابًا أو حسابًا فرعيًا. +- NEAR data sources introduce an optional `source.account` field, which is a human-readable ID corresponding to a [NEAR account](https://docs.near.org/docs/concepts/account). This can be an account or a sub-account. +- NEAR data sources introduce an alternative optional `source.accounts` field, which contains optional suffixes and prefixes. At least prefix or suffix must be specified, they will match the any account starting or ending with the list of values respectively. The example below would match: `[app|good].*[morning.near|morning.testnet]`. If only a list of prefixes or suffixes is necessary the other field can be omitted. + +```yaml +accounts: + prefixes: + - app + - good + suffixes: + - morning.near + - morning.testnet +``` مصادر بيانات NEAR تدعم نوعين من المعالجات: - `blockHandlers`: يتم تشغيلها على كل كتلة NEAR جديدة. لا يتطلب `source.account`. - `receiptHandlers`: يتم تشغيلها في كل استلام حيث يكون مصدر البيانات`source.account` هو المستلم. لاحظ أنه تتم معالجة المطابقات التامة فقط (يجب إضافة حسابات فرعية [subaccounts](https://docs.near.org/docs/concepts/account#subaccounts) كمصادر بيانات مستقلة). -### تعريف المخطط(Schema Definition) +### تعريف المخطط -تعريف المخطط يقوم بوصف هيكل قاعدة بيانات الـ subgraph الناتجة والعلاقات بين الكيانات. وهذا مستقل عن مصدر البيانات الأصلية. لمزيد من التفاصيل حول تعريف مخطط الـ subgraph [ هنا ](/developing/creating-a-subgraph#the-graphql-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](/developing/creating-a-subgraph#the-graphql-schema). -### AssemblyScript Mappings +### أسيمبلي سكريبت التعيينات -تمت كتابة المعالجات(handlers) الخاصة بمعالجة الأحداث بـ[ AssemblyScript ](https://www.assemblyscript.org/). +تمت كتابة المعالجات الخاصة بمعالجة الأحداث بـ[ أسيمبلي سكريبت ](https://www.assemblyscript.org/). -فهرسة NEAR تقدم أنواع بيانات خاصة بـ NEAR إلى [AssemblyScript API](/developing/assemblyscript-api). +NEAR indexing introduces NEAR-specific data types to the [AssemblyScript API](/developing/assemblyscript-api). ```typescript @@ -151,14 +162,14 @@ class ReceiptWithOutcome { } ``` -يتم تمرير هذه الأنواع لمعالجات الكتلة(block) & الاستلام(receipt): +يتم تمرير هذه الأنواع لمعالجات الكتلة و الاستلام: - معالجات الكتلة ستتلقى`Block` - معالجات الاستلام ستتلقى`ReceiptWithOutcome` -وبخلاف ذلك ، فإن بقية [ AssemblyScript API ](/developing/assemblyscript-api) تكون متاحة لمطوري NEAR subgraph أثناء تنفيذ الـ mapping. +Otherwise, the rest of the [AssemblyScript API](/developing/assemblyscript-api) is available to NEAR subgraph developers during mapping execution. -هذا يتضمن دالة تحليل JSON جديدة - يتم إرسال السجلات الموجودة على NEAR بشكل متكرر على هيئة JSONs. تتوفر دالة `(...)json.fromString` جديدة كجزء من [JSON API](/developing/assemblyscript-api#json-api) للسماح للمطورين لمعالجة هذه السجلات بسهولة. +This includes a new JSON parsing function - logs on NEAR are frequently emitted as stringified JSONs. A new `json.fromString(...)` function is available as part of the [JSON API](/developing/assemblyscript-api#json-api) to allow developers to easily process these logs. ## نشر NEAR Subgraph @@ -169,7 +180,7 @@ class ReceiptWithOutcome { - `near-mainnet` - `near-testnet` -يمكن العثور على مزيد من المعلومات حول إنشاء ونشر الـ subgraphs على Hosted Service [ هنا ](/deploying/deploying-a-subgraph-to-hosted). +More information on creating and deploying subgraphs on the Hosted Service can be found [here](/deploying/deploying-a-subgraph-to-hosted). كتمهيد سريع - الخطوة الأولى هي "إنشاء" subgraph خاص بك - يجب القيام بذلك مرة واحدة فقط. على Hosted Service ، يمكن القيام بذلك من [Dashboard](https://thegraph.com/hosted-service/dashboard): الخاص بك "Add Subgraph". @@ -180,7 +191,7 @@ $ graph create --node subgraph/name # creates a subgraph on a l $ graph deploy --node --ipfs https://api.thegraph.com/ipfs/ # uploads the build files to a specified IPFS endpoint, and then deploys the subgraph to a specified Graph Node based on the manifest IPFS hash ``` -سيعتمد تكوين العقدة (node) على مكان نشر الـ subgraph. +The node configuration will depend on where the subgraph is being deployed. #### Hosted Service: @@ -188,7 +199,7 @@ $ graph deploy --node --ipfs https://api.thegraph.com/ipfs/ # u graph deploy --node https://api.thegraph.com/deploy/ --ipfs https://api.thegraph.com/ipfs/ --access-token ``` -#### Graph Node المحلية (على أساس التكوين الافتراضي): +#### رسم بياني العقدة المحلية (على أساس التكوين الافتراضي): ``` graph deploy --node http://localhost:8020/ --ipfs http://localhost:5001 @@ -216,15 +227,15 @@ graph deploy --node http://localhost:8020/ --ipfs http://localhost:5001 ## الاستعلام عن NEAR Subgraph -يتم تحديد GraphQL endpoint لـ NEAR subgraphs من خلال تعريف المخطط ، باستخدام واجهة API الحالية. يرجى زيارة [ وثائق GraphQL API ](/querying/graphql-api) لمزيد من المعلومات. +The GraphQL endpoint for NEAR subgraphs is determined by the schema definition, with the existing API interface. Please visit the [GraphQL API documentation](/querying/graphql-api) for more information. -## أمثلة على الـ Subgraphs +## مثال الفرعية رسم بياني -فيما يلي بعض الأمثلة على الـ subgraphs للرجوع إليها: +فيما يلي بعض مثال الفرعية رسم بياني للرجوع إليها: -[NEAR Blocks](https://github.com/graphprotocol/example-subgraph/tree/near-blocks-example) +[NEAR Blocks](https://github.com/graphprotocol/example-subgraphs/tree/main/near/blocks-example) -[NEAR Receipts](https://github.com/graphprotocol/example-subgraph/tree/near-receipts-example) +[NEAR Receipts](https://github.com/graphprotocol/example-subgraphs/tree/main/near/receipts-example) ## الأسئلة الشائعة @@ -234,15 +245,21 @@ graph deploy --node http://localhost:8020/ --ipfs http://localhost:5001 ### هل يمكن لـ subgraph فهرسة كلاً من سلاسل NEAR و EVM؟ -لا ، يمكن لـ subgraph أن يدعم فقط مصادر البيانات من سلسلة(chain) واحدة لكل شبكة. +No, a subgraph can only support data sources from one chain/network. ### هل يمكن أن يتفاعل الـ subgraphs مع مشغلات(triggers) أكثر تحديدًا؟ حاليًا ، يتم دعم مشغلات الكتلة(Block) والاستلام(Receipt). نحن نبحث في مشغلات استدعاءات الدوال لحساب محدد. نحن مهتمون أيضًا بدعم مشغلات الأحداث ، بمجرد حصول NEAR على دعم محلي للأحداث. -### هل سيتم تشغيل(trigger) معالجات الاستلام للحسابات وحساباتها الفرعية؟ +### Will receipt handlers trigger for accounts and their sub-accounts? -سيتم تشغيل معالجات الاستلام فقط للتطابق التام للحساب المحدد. يمكن إضافة المزيد من المرونة في المستقبل. +If an `account` is specified, that will only match the exact account name. It is possible to match sub-accounts by specifying an `accounts` field, with `suffixes` and `prefixes` specified to match accounts and sub-accounts, for example the following would match all `mintbase1.near` sub-accounts: + +```yaml +accounts: + suffixes: + - mintbase1.near +``` ### هل يستطيع NEAR subgraphs أن يقوم بعرض استدعاءات لحسابات NEAR أثناء الـ mappings؟ @@ -258,7 +275,7 @@ graph deploy --node http://localhost:8020/ --ipfs http://localhost:5001 ### لم تتم الإجابة على سؤالي ، أين يمكنني الحصول على مزيد من المساعدة في بناء NEAR subgraphs؟ -إذا كان سؤالاً عامًا حول تطوير الـ subgraph ، فهناك الكثير من المعلومات في [ وثائق المطور ](/cookbook/quick-start). بخلاف ذلك ، يرجى الانضمام إلى [ The Graph Protocol Discord ](https://discord.gg/vtvv7FP) والسؤال في قناة near# ، أو إرسال بريد إلكتروني إلى near@thegraph.com. +If it is a general question about subgraph development, there is a lot more information in the rest of the [Developer documentation](/cookbook/quick-start). Otherwise please join [The Graph Protocol Discord](https://discord.gg/vtvv7FP) and ask in the #near channel or email near@thegraph.com. ## المراجع diff --git a/website/pages/ar/cookbook/quick-start.mdx b/website/pages/ar/cookbook/quick-start.mdx index e0c7267a09d1..36df517408fb 100644 --- a/website/pages/ar/cookbook/quick-start.mdx +++ b/website/pages/ar/cookbook/quick-start.mdx @@ -2,16 +2,15 @@ title: بداية سريعة --- -سيأخذك هذا الدليل سريعا ويعلمك كيفية تهيئة وإنشاء ونشر Subgraph الخاص بك على: +This guide will quickly take you through how to initialize, create, and deploy your subgraph to the Subgraph Studio or the [hosted service](#hosted-service). -- **Subgraph Studio** - تستخدم فقط لـ subgraphs التي تفهرس **Ethereum mainnet** -- **Hosted Service** - يتم استخدامها ل Subgraphs التي تفهرس ** الشبكات الأخرى ** خارج Ethereum mainnet (مثل Binance و Matic والخ..) +Ensure that your subgraph will be indexing data from a [supported network](/developing/supported-networks). -## Subgraph Studio +## الفرعيةرسم بياني استوديو ### 1. قم بتثبيت Graph CLI -تمت كتابة Graph CLI بلغة JavaScript وستحتاج إلى تثبيت إما `npm` أو `yarn` لاستخدامه. +تمت كتابة Graph CLI بلغة جافا سكريبت وستحتاج إلى تثبيت إما `npm` أو `yarn` لاستخدامه. ```sh # NPM @@ -21,40 +20,42 @@ $ npm install -g @graphprotocol/graph-cli $ yarn global add @graphprotocol/graph-cli ``` -### 2. قم بتهيئة Subgraph الخاص بك +### 2. قم بتهيئة الفرعيةرسم بياني الخاص بك -- ابدأ ال Subgraph الخاص بك من عقد موجود. +- ابدأ الفرعية رسم بياني الخاص بك من عقد قائم. ```sh graph init --studio ``` -- الـ subgraph slug الخاص بك هو معرف لـ Subgraph الخاص بك. ستوجهك أداة CLI لخطوات إنشاء Subgraph ، مثل عنوان العقد والشبكة الخ.. كما ترى في لقطة الشاشة أدناه. +- الـ الفرعية رسم بياني slug الخاص بك هو معرف لـ الفرعية رسم بياني الخاص بك. ستوجهك أداة CLI لخطوات إنشاء الفرعية رسم بياني ، مثل عنوان العقد والشبكة الخ.. كما ترى في لقطة الشاشة أدناه. -![أمر Subgraph](/img/Subgraph-Slug.png) +![أمر الفرعيةرسم بياني](/img/Subgraph-Slug.png) -### 3. اكتب subgraph الخاص بك +> Note: Consider adding `--index-events` to the command above to save time. It bootstraps the subgraph with entities in the schema and simple mappings for each emitted event. -تقوم الأوامر السابقة بإنشاء ركيزة ال Subgraph والتي يمكنك استخدامها كنقطة بداية لبناء subgraph الخاص بك. عند إجراء تغييرات على ال subgraph ، ستعمل بشكل أساسي على ثلاثة ملفات: +### 3. اكتب الفرعيةرسم بياني الخاص بك -- : (Manifest(subgraph.yaml يحدد ال manifest مصادر البيانات التي سيقوم Subgraphs الخاص بك بفهرستها. -- مخطط (schema.graphql) - يحدد مخطط GraphQL البيانات التي ترغب في استردادها من Subgraph. -- (AssemblyScript Mappings (mapping.ts هذا هو الكود الذي يترجم البيانات من مصادر البيانات الخاصة بك إلى الكيانات المحددة في المخطط. +The previous commands create a scaffold subgraph that you can use as a starting point for building your subgraph. When making changes to the subgraph, you will mainly work with three files: -لمزيد من المعلومات حول كيفية كتابة Subgraph ، راجع [ إنشاء Subgraph ](/developing/creating-a-subgraph). +- (Manifest(subgraph.yaml - يحدد ال manifest مصادر البيانات التي سيقوم الفرعية رسم بياني الخاص بك بفهرستها. +- Schema (schema.graphql) - The GraphQL schema defines what data you wish to retrieve from the subgraph. +- (AssemblyScript Mappings (mapping.ts - هذا هو الكود الذي يترجم البيانات من مصادر البيانات الخاصة بك إلى الكيانات المحددة في المخطط. -### النشر على Subgraph Studio +For more information on how to write your subgraph, see [Creating a Subgraph](/developing/creating-a-subgraph). -- انتقل إلى Subgraph Studio [ https://thegraph.com/studio/ ](https://thegraph.com/studio/) وقم بتوصيل محفظتك. +### نشر على الفرعيةرسم بياني استوديو + +- انتقل إلى استوديو الرسم البياني [ https://thegraph.com/studio/ ](https://thegraph.com/studio/) وقم بتخزين محفظتك. - انقر على "إنشاء" وأدخل subgraph slug الذي استخدمته في الخطوة 2. -- قم بتشغيل هذه الأوامر في مجلد Subgraph +- قم بتشغيل هذه الأوامر في مجلد الفرعيةرسم بياني ```sh $ graph codegen $ graph build ``` -- وثق وأنشر ال Subgraph الخاص بك. يمكن العثور على مفتاح النشر في صفحة Subgraph في Subgraph Studio. +- وثق وأنشر ال الفرعيةرسم بياني الخاص بك. يمكن العثور على مفتاح النشر في صفحة الفرعيةرسم بياني في الفرعيةرسم بياني استوديو. ```sh $ graph auth --studio @@ -65,7 +66,7 @@ $ graph deploy --studio ### 5. تحقق من السجلات الخاصة بك -السجلات ستخبرك في حالة وجود أخطاء. في حالة فشل Subgraph ، يمكنك الاستعلام عن صحة Subgraph وذلك باستخدام [ GraphiQL Playground ](https://graphiql-online.com/). استخدم [this endpoint](https://api.thegraph.com/index-node/graphql). لاحظ أنه يمكنك الاستفادة من الاستعلام أدناه وإدخال ID النشر ل Subgraph الخاص بك. في هذه الحالة ، `Qm...` هو ID النشر (والذي يمكن أن يوجد في صفحة ال Subgraph ضمن ** التفاصيل **). سيخبرك الاستعلام أدناه عند فشل Subgraph حتى تتمكن من تصحيح الأخطاء وفقًا لذلك: +السجلات ستخبرك في حالة وجود أخطاء. في حالة فشل الفرعيةرسم بياني ، يمكنك الاستعلام عن صحة الفرعيةرسم بياني وذلك باستخدام [ GraphiQL Playground ](https://graphiql-online.com/). استخدم [this endpoint](https://api.thegraph.com/index-node/graphql). لاحظ أنه يمكنك الاستفادة من الاستعلام أدناه وإدخال ID النشر ل الفرعيةرسم بياني الخاص بك. في هذه الحالة ، `Qm...` هو ID النشر (والذي يمكن أن يوجد في صفحة ال الفرعيةرسم بياني ضمن ** التفاصيل **). سيخبرك الاستعلام أدناه عند فشل الفرعيةرسم بياني حتى تتمكن من تصحيح الأخطاء وفقًا لذلك: ```sh { @@ -111,7 +112,7 @@ $ graph deploy --studio ### 6. الاستعلام عن ال Subgraph الخاص بك -يمكنك الآن الاستعلام عن Subgraph باتباع [ هذه الإرشادات ](/querying/querying-the-graph). يمكنك الاستعلام من ال dapp الخاص بك إذا لم يكن لديك API Key الخاص بك وذلك عبر عنوان URL الخاص بالاستعلام المؤقت المجاني والمحدود والذي يمكن استخدامه للتطوير والتشغيل. يمكنك قراءة الإرشادات الإضافية حول كيفية الاستعلام عن رسم بياني فرعي من [ هنا ](/querying/querying-from-an-application). +You can now query your subgraph by following [these instructions](/querying/querying-the-graph). You can query from your dApp if you don't have your API key via the free, rate-limited temporary query URL that can be used for development and staging. You can read the additional instructions for how to query a subgraph from a frontend application [here](/querying/querying-from-an-application). ## الخدمة المستضافة @@ -127,9 +128,9 @@ $ npm install -g @graphprotocol/graph-cli $ yarn global add @graphprotocol/graph-cli ``` -### 2. قم بتهيئة Subgraph الخاص بك +### 2. قم بتهيئة الفرعيةرسم بياني الخاص بك -- ابدأ ال Subgraph الخاص بك من عقد موجود. +- ابدأ الفرعية رسم بياني الخاص بك من عقد قائم. ```sh $ graph init --product hosted-service --from-contract
@@ -145,7 +146,7 @@ graph init --product hosted-service --from-example$ - في حالة المثال ، يعتمد Subgraph على عقد Gravity بواسطة Dani Grant الذي يدير ال avatars للمستخدم ويصدر أحداث `NewGravatar` أو `UpdateGravatar` كلما تم إنشاء ال avatars أو تحديثها. -### 3. اكتب subgraph الخاص بك +### 3. اكتب الفرعيةرسم بياني الخاص بك سيكون الأمر السابق قد أنشأ ركيزة حيث يمكنك بناء Subgraph خاص بك. عند إجراء تغييرات على ال subgraph ، ستعمل بشكل أساسي على ثلاثة ملفات: @@ -153,13 +154,13 @@ graph init --product hosted-service --from-example$ - مخطط (schema.graphql) - يحدد مخطط GraphQL البيانات التي ترغب في جلبها من Subgraph - (AssemblyScript Mappings (mapping.ts هذا هو الكود الذي يترجم البيانات من مصادر البيانات الخاصة بك إلى الكيانات المحددة في المخطط -لمزيد من المعلومات حول كيفية كتابة Subgraph ، راجع [ إنشاء Subgraph ](/developing/creating-a-subgraph). +For more information on how to write your subgraph, see [Creating a Subgraph](/developing/creating-a-subgraph). ### 4. انشر ال subgraph الخاص بك -- سجّل الدخول إلى [ الخدمة المستضافة ](https://thegraph.com/hosted-service/) باستخدام حسابك على github -- انقر فوق إضافة Subgraph واملأ المعلومات المطلوبة. استخدم نفس اسم ال Subgraph كما في الخطوة 2. -- قم بتشغيل codegen في مجلد ال Subgraph +- Sign into the [Hosted Service](https://thegraph.com/hosted-service/) using your GitHub account +- انقر فوق إضافة الفرعيةرسم بياني واملأ المعلومات المطلوبة. استخدم نفس اسم ال الفرعيةرسم بياني كما في الخطوة 2. +- Run `codegen` in the subgraph folder ```sh # NPM @@ -169,7 +170,7 @@ $ npm run codegen $ yarn codegen ``` -- أضف توكن الوصول الخاص بك وانشر ال Subgraph الخاص بك. يتم العثور على توكن الوصول في لوحة التحكم في ال Hosted service. +- أضف توكن الوصول الخاص بك وانشر ال الفرعيةرسم بياني الخاص بك. يتم العثور على توكن الوصول في لوحة التحكم في ال الخدمة المستضافة. ```sh $ graph auth --product hosted-service @@ -178,7 +179,7 @@ $ graph deploy --product hosted-service / ### 5. تحقق من السجلات الخاصة بك -السجلات ستخبرك في حالة وجود أخطاء. في حالة فشل Subgraph ، يمكنك الاستعلام عن صحة Subgraph وذلك باستخدام [ GraphiQL Playground ](https://graphiql-online.com/). استخدم [this endpoint](https://api.thegraph.com/index-node/graphql). لاحظ أنه يمكنك الاستفادة من الاستعلام أدناه وإدخال ID النشر ل Subgraph الخاص بك. في هذه الحالة ، `Qm...` هو ID النشر (والذي يمكن أن يوجد في صفحة ال Subgraph ضمن ** التفاصيل **). سيخبرك الاستعلام أدناه عند فشل Subgraph حتى تتمكن من تصحيح الأخطاء وفقًا لذلك: +السجلات ستخبرك في حالة وجود أخطاء. في حالة فشل الفرعيةرسم بياني ، يمكنك الاستعلام عن صحة الفرعيةرسم بياني وذلك باستخدام [ GraphiQL Playground ](https://graphiql-online.com/). استخدم [this endpoint](https://api.thegraph.com/index-node/graphql). لاحظ أنه يمكنك الاستفادة من الاستعلام أدناه وإدخال ID النشر ل الفرعيةرسم بياني الخاص بك. في هذه الحالة ، `Qm...` هو ID النشر (والذي يمكن أن يوجد في صفحة ال الفرعيةرسم بياني ضمن ** التفاصيل **). سيخبرك الاستعلام أدناه عند فشل الفرعيةرسم بياني حتى تتمكن من تصحيح الأخطاء وفقًا لذلك: ```sh { @@ -222,6 +223,6 @@ $ graph deploy --product hosted-service / } ``` -### 6. الاستعلام عن ال Subgraph الخاص بك +### 6. الاستعلام عن ال الفرعيةرسم بياني الخاص بك -اتبع [ هذه الإرشادات ](/querying/querying-the-hosted-service) للاستعلام عن ال Subgraph الخاص بك على ال Hosted service. +Follow [these instructions](/querying/querying-the-hosted-service) to query your subgraph on the Hosted Service. diff --git a/website/pages/ar/cookbook/subgraph-debug-forking.mdx b/website/pages/ar/cookbook/subgraph-debug-forking.mdx index f9e39caaf1b8..4a1580140954 100644 --- a/website/pages/ar/cookbook/subgraph-debug-forking.mdx +++ b/website/pages/ar/cookbook/subgraph-debug-forking.mdx @@ -1,8 +1,8 @@ --- -title: تصحيح أخطاء الـ subgraph بسرعة وسهولة باستخدام التفرعات (forks) +title: Quick and Easy Subgraph Debugging Using Forks --- -كما هو الحال مع العديد من الأنظمة التي تعالج كميات كبيرة من البيانات ، قد يستغرق مفهرسو The Graph أو (Graph nodes) بعض الوقت لمزامنة الـ subgraph الخاص بك مع blockchain المستهدف. التناقض بين التغييرات السريعة بغرض تصحيح الأخطاء وأوقات الانتظار الطويلة اللازمة للفهرسة يؤدي إلى نتائج عكسية للغاية ونحن ندرك ذلك جيدًا. ولهذا السبب نقدم **subgraph forking ** ، الذي تم تطويره بواسطة [ LimeChain ](https://limechain.tech/) ، وفي هذه المقالة سنوضح لكم كيف يمكن استخدام هذه الميزة لتسريع تصحيح أخطاء الـ subgraph بشكل كبير! +كما هو الحال مع العديد من الأنظمة التي تعالج كميات كبيرة من البيانات ، قد يستغرق مفهرسو رسم بياني أو (Graph nodes) بعض الوقت لمزامنة الـ الفرعية رسمبياني الخاص بك مع بلوكشين المستهدف. التناقض بين التغييرات السريعة بغرض تصحيح الأخطاء وأوقات الانتظار الطويلة اللازمة للفهرسة يؤدي إلى نتائج عكسية للغاية ونحن ندرك ذلك جيدًا. ولهذا السبب نقدم **الفرعيةرسم بياني forking ** ، الذي تم تطويره بواسطة [ LimeChain ](https://limechain.tech/) ، وفي هذه المقالة سنوضح لكم كيف يمكن استخدام هذه الميزة لتسريع تصحيح أخطاء الـ الفرعيةرسم بياني بشكل كبير! ## حسنا، ما هو؟ @@ -12,15 +12,15 @@ title: تصحيح أخطاء الـ subgraph بسرعة وسهولة باستخ ## ماذا؟! كيف؟ -عندما تنشر subgraph إلى Graph node بعيدة للقيام بالفهرسة ويفشل عند الكتلة _ X _ ، فإن الخبر الجيد هو أن Graph node ستظل تقدم استعلامات GraphQL باستخدام مخزنها(store)، والذي تمت مزامنته للكتلة(block) _ X _. هذا عظيم! هذا يعني أنه يمكننا الاستفادة من هذا المخزن "المحدث" لإصلاح الأخطاء التي تظهر عند فهرسة الكتلة _ X _. +عندما تنشر الفرعيةرسم بياني إلى Graph node بعيدة للقيام بالفهرسة ويفشل عند الكتلة _ X _ ، فإن الخبر الجيد هو أن Graph node ستظل تقدم استعلامات GraphQL باستخدام مخزنها، والذي تمت مزامنته للكتلة _ X _. هذا عظيم! هذا يعني أنه يمكننا الاستفادة من هذا المخزن "المحدث" لإصلاح الأخطاء التي تظهر عند فهرسة الكتلة _ X _. -باختصار ، سنقوم _ بتفريع (fork) الـ subgraph الفاشل _ من Graph node بعيدة والتي تضمن فهرسة الـ subgraph للكتلة _ X _ وذلك من أجل توفير الـ subgraph المنشور محليًا والذي يتم تصحيحه عندالكتلة*X* مع عرض محدث لحالة الفهرسة. +باختصار ، سنقوم _ بتفريع الـ الفرعيةرسم بياني الفاشل _ من Graph node بعيدة والتي تضمن فهرسة الـ الفرعيةرسم بياني للكتلة _ X _ وذلك من أجل توفير الـ الفرعيةرسم بياني المنشور محليًا والذي يتم تصحيحه عندالكتلة _X_ مع عرض محدث لحالة الفهرسة. ## من فضلك ، أرني بعض الأكواد! -للاستمرار في التركيز على تصحيح أخطاء الـ subgraph ، دعنا نجعل الأمور بسيطة ونعمل مع [example-subgraph](https://github.com/graphprotocol/example-subgraph) الذي يفهرس عقد Ethereum Gravity الذكي. +To stay focused on subgraph debugging, let's keep things simple and run along with the [example-subgraph](https://github.com/graphprotocol/example-subgraphs/tree/main/ethereum/gravatar) indexing the Ethereum Gravity smart contract. -فيما يلي المعالجات (handlers) المعرفة لفهرسة `Gravatar` ، بدون أخطاء على الإطلاق: +فيما يلي المعالجات المعرفة لفهرسة `Gravatar` ، بدون أخطاء على الإطلاق: ```tsx export function handleNewGravatar(event: NewGravatar): void { @@ -44,12 +44,12 @@ export function handleUpdatedGravatar(event: UpdatedGravatar): void { } ``` -للأسف ، يفشل نشر هذا الـ subgraph ذو المظهر المثالي على [ HostedService ](https://thegraph.com/hosted-service/)مع ظهور الخطأ _"Gravatar not found!"_. +Oops, how unfortunate, when I deploy my perfect looking subgraph to the [Hosted Service](https://thegraph.com/hosted-service/) it fails with the _"Gravatar not found!"_ error. الطريقة المعتادة لمحاولة الإصلاح هي: 1. إجراء تغيير في مصدر الـ mappings ، والذي تعتقد أنه سيحل المشكلة (وأنا أعلم أنه لن يحلها). -2. إعادة نشر الـ subgraph على [ HostedService ](https://thegraph.com/hosted-service/) (أو Graph node أخرى بعيدة). +2. Re-deploy the subgraph to the [Hosted Service](https://thegraph.com/hosted-service/) (or another remote Graph node). 3. الانتظار حتى تتم المزامنة. 4. إذا حدثت المشكلة مرة أخرى ، فارجع إلى 1! @@ -59,17 +59,17 @@ export function handleUpdatedGravatar(event: UpdatedGravatar): void { 0. قم بتجهيز Graph node محلية بمجموعة **_fork-base_** مناسبة. 1. قم بإجراء تغيير في مصدر الـ mappings ، والذي تعتقد أنه سيحل المشكلة. -2. قم بالنشر إلى Graph node محلية ، **_وقم بتفريع الـ subgraph الفاشل_**و**_ البدء من الكتلة التي بها المشكلة_**. +2. قم بالنشر إلى Graph node محلية ، **_وقم بتفريع الـ الفرعيةرسم بياني الفاشل_**و**_ البدء من الكتلة التي بها المشكلة_**. 3. إذا حدثت المشكلة مرة أخرى ، فارجع إلى 1! الآن ، قد يكون لديك سؤالان: 1. ماهو fork-base؟؟؟ -2. ما الذي نقوم بتفريعه (Forking)؟! +2. ما الذي نقوم بتفريعه ؟! وأنا أجيب: -1. `fork-base` هو عنوان URL "الأساسي" ،فمثلا عند إلحاق _subgraph id_ ، يكون عنوان URL الناتج (`/`) هو GraphQL endpoint صالح لمخزن الـ subgraph. +1. `fork-base` هو عنوان URL "الأساسي" ،فمثلا عند إلحاق _الفرعيةرسم بياني id_ ، يكون عنوان URL الناتج (`/`) هو GraphQL endpoint صالح لمخزن الـ الفرعيةرسم بياني. 2. الـتفريع سهل ، فلا داعي للقلق: ```bash @@ -80,7 +80,7 @@ $ graph deploy --debug-fork --ipfs http://localhos لذلك ، هذا ما أفعله: -0. أقوم بتجهيز Graph Node محلية ([هنا كيف تقوم به](https://github.com/graphprotocol/graph-node#running-a-local-graph-node)) مع تعيين خيار `fork-base` إلى `https://api.thegraph.com/subgraphs/id/` ، نظرا لأنني سأقوم بتفريع(fork) الـ subgraph الذي به أخطاء والذي نشرته سابقا من الـ [HostedService](https://thegraph.com/hosted-service/). +0. أقوم بتجهيز Graph Node محلية ([هنا كيف تقوم به](https://github.com/graphprotocol/graph-node#running-a-local-graph-node)) مع تعيين خيار `fork-base` إلى `https://api.thegraph.com/subgraphs/id/` ، نظرا لأنني سأقوم بتفريع الـ الفرعيةرسم بياني الذي به أخطاء والذي نشرته سابقا من الـ [الخدمة المستضافة](https://thegraph.com/hosted-service/). ``` $ cargo run -p graph-node --release -- \ @@ -91,12 +91,12 @@ $ cargo run -p graph-node --release -- \ ``` 1. بعد فحص دقيق ، لاحظت أن هناك عدم تطابق في تمثيلات الـ `id` المستخدمة عند فهرسة `Gravatar` في المعالجين الخاصين بي. بينما `handleNewGravatar` يحول (`event.params.id.toHex()`) إلى سداسي ، `handleUpdatedGravatar` يستخدم int32 (`event.params.id.toI32()`) مما يجعل `handleUpdatedGravatar` قلقا من "Gravatar not found!". أنا أجعلهم كلاهما يحولان `id` إلى سداسي. -2. بعد إجراء التغييرات ، قمت بنشر الـ subgraph الخاص بي على Graph node المحلية **_وتفريع الـsubgraph الفاشل_** وضبط `dataSources.source.startBlock` إلى `6190343` في `subgraph.yaml`: +2. بعد إجراء التغييرات ، قمت بنشر الـ الفرعيةرسم بياني الخاص بي على Graph node المحلية **_وتفريع الـ الفرعيةرسم بياني الفاشل_** وضبط `dataSources.source.startBlock` إلى `6190343` في `subgraph.yaml`: ```bash $ graph deploy gravity --debug-fork QmNp169tKvomnH3cPXTfGg4ZEhAHA6kEq5oy1XDqAxqHmW --ipfs http://localhost:5001 --node http://localhost:8020 ``` 3. لقد قمت بفحص السجلات التي تنتجها Graph node المحلية ، ويبدو أن كل شيء يعمل بشكل جيد. -4. أقوم بنشر الـ subgraph الخاص بي الخالي من الأخطاء لـ Graph node بعيدة وأعيش في سعادة دائمة +4. أقوم بنشر الـ الفرعيةرسم بياني الخاص بي الخالي من الأخطاء لـ Graph node بعيدة وأعيش في سعادة دائمة 5. النهاية... diff --git a/website/pages/ar/cookbook/subgraph-uncrashable.mdx b/website/pages/ar/cookbook/subgraph-uncrashable.mdx new file mode 100644 index 000000000000..e6db9624c7bc --- /dev/null +++ b/website/pages/ar/cookbook/subgraph-uncrashable.mdx @@ -0,0 +1,29 @@ +--- +title: Safe Subgraph Code Generator +--- + +[Subgraph Uncrashable](https://float-capital.github.io/float-subgraph-uncrashable/) is a code generation tool that generates a set of helper functions from the graphql schema of a project. It ensures that all interactions with entities in your subgraph are completely safe and consistent. + +### Why integrate with Subgraph Uncrashable? + +- **Continuous Uptime**. Mishandled entities may cause subgraphs to crash, which can be disruptive for projects that are dependent on The Graph. Set up helper functions to make your subgraphs “uncrashable” and ensure business continuity. + +- **Completely Safe**. Common problems seen in subgraph development are issues of loading undefined entities, not setting or initializing all values of entities, and race conditions on loading and saving entities. Ensure all interactions with entities are completely atomic. + +- **User Configurable** Set default values and configure the level of security checks that suits your individual project's needs. Warning logs are recorded indicating where there is a breach of subgraph logic to help patch the issue to ensure data accuracy. + +**Key Features** + +- The code generation tool accommodates **all** subgraph types and is configurable for users to set sane defaults on values. The code generation will use this config to generate helper functions that are to the users specification. + +- The framework also includes a way (via the config file) to create custom, but safe, setter functions for groups of entity variables. This way it is impossible for the user to load/use a stale graph entity and it is also impossible to forget to save or set a variable that is required by the function. + +- Warning logs are recorded as logs indicating where there is a breach of subgraph logic to help patch the issue to ensure data accuracy. These logs can be viewed in the The Graph's hosted service under the 'Logs' section. + +Subgraph Uncrashable can be run as an optional flag using the Graph CLI codegen command. + +```sh +graph codegen -u [options] [] +``` + +Visit the [subgraph uncrashable documentation](https://float-capital.github.io/float-subgraph-uncrashable/docs/) or watch this [video tutorial](https://float-capital.github.io/float-subgraph-uncrashable/docs/tutorial) to learn more and to get started with developing safer subgraphs. diff --git a/website/pages/ar/deploying/deploying-a-subgraph-to-hosted.mdx b/website/pages/ar/deploying/deploying-a-subgraph-to-hosted.mdx index 249f26f83c02..cdb790eba81f 100644 --- a/website/pages/ar/deploying/deploying-a-subgraph-to-hosted.mdx +++ b/website/pages/ar/deploying/deploying-a-subgraph-to-hosted.mdx @@ -1,74 +1,76 @@ --- -title: نشر Subgraph على الخدمة المستضافة (Hosted Service) +title: Deploying a Subgraph to the Hosted Service --- -إذا لم تفعل ذلك بالفعل ، فتحقق من كيفية كتابة الملفات التي تشكل [subgraph manifest](/developing/creating-a-subgraph#the-subgraph-manifest) وكيفية تثبيت [ Graph CLI ](https://github.com/graphprotocol/graph-cli) وذلك لتوليد كود لـ subgraph الخاص بك. حان الوقت الآن لنشر الـ subgraph الخاص بك على Hosted Service ، والمعروفة أيضا باسم Hosted Service. +> If a network is not supported on the Hosted Service, you can run your own [graph-node](https://github.com/graphprotocol/graph-node) to index it. -## إنشاء حساب Hosted Service +This page explains how to deploy a subgraph to the Hosted Service. To deploy a subgraph you need to first install the [Graph CLI](https://github.com/graphprotocol/graph-cli). If you have not created a subgraph already, see [creating a subgraph](/developing/creating-a-subgraph). -قبل استخدام Hosted Service ، قم بإنشاء حساب في Hosted Service الخاص بنا. ستحتاج إلى حساب [ Github ](https://github.com/) لذلك ؛ إذا لم يكن لديك واحد ، فأنت بحاجة إلى إنشاء ذلك أولا. بعد ذلك ، انتقل إلى [Hosted Service](https://thegraph.com/hosted-service/)، وانقر على _'Sign up with Github'_ وأكمل مصادقة Github. +## إنشاء حساب الخدمة المستضافة -## تخزين Access Token +Before using the Hosted Service, create an account in our Hosted Service. You will need a [Github](https://github.com/) account for that; if you don't have one, you need to create that first. Then, navigate to the [Hosted Service](https://thegraph.com/hosted-service/), click on the _'Sign up with Github'_ button, and complete Github's authorization flow. -بعد إنشاء حساب ، انتقل إلى [dashboard](https://thegraph.com/hosted-service/dashboard). وانسخ access token المعروض على لوحة المعلومات وقم بتنفيذ `graph auth --product hosted-service `. سيؤدي هذا إلى تخزين access token على جهاز الكمبيوتر الخاص بك. تحتاج للقيام بذلك مرة واحدة ، أو إذا قمت بإعادة توليد access token. +## تخزين رمز وصول -## إنشاء Subgraph على الخدمة المستضافة (Hosted Service) +بعد إنشاء حساب ، انتقل إلى [لوحة القيادة](https://thegraph.com/hosted-service/dashboard). وانسخ رمز وصول المعروض على لوحة المعلومات وقم بتنفيذ `graph auth --product hosted-service `. سيؤدي هذا إلى تخزين رمز وصول على جهاز الكمبيوتر الخاص بك. تحتاج للقيام بذلك مرة واحدة ، أو إذا قمت بإعادة توليد رمز وصول. -قبل نشر الـ subgraph ، تحتاج إلى إنشائه في The Graph Explorer. انتقل إلى [dashboard](https://thegraph.com/hosted-service/dashboard) وانقر على _'Add Subgraph'_ واملأ المعلومات أدناه حسب الحاجة: +## إنشاء الفرعية رسم بياني على الخدمة المستضافة -**Image** - اختر صورة لاستخدامها كصورة عرض وصورة مصغرة للـ subgraph. +قبل نشر الـ الفرعيةرسم بياني ، تحتاج إلى إنشائه في مستكشف الرسم البياني. انتقل إلى [لوحة القيادة](https://thegraph.com/hosted-service/dashboard) وانقر على _'يضيف الفرعيةرسم بياني'_ واملأ المعلومات أدناه حسب الحاجة: -**Subgraph Name** - بالاضافة لاسم الحساب الذي تم إنشاء الـ subgraph ضمنه، سيؤدي هذا أيضا إلى تعريف اسم النمط `account-name/subgraph-name` - المستخدم لعمليات النشر و GraphQL endpoints. _لا يمكن تغيير هذا الحقل لاحقا._ +**صورة** - اختر صورة لاستخدامها كصورة عرض وصورة مصغرة للـ الفرعيةرسم بياني. -**Account** - الحساب الذي تم إنشاء الـ subgraph ضمنه. يمكن أن يكون هذا حساب فرد أو منظمة. _لا يمكن نقل الـ Subgraphs بين الحسابات لاحقا._ +**الفرعيةرسم بياني اسم** - بالاضافة لاسم الحساب الذي تم إنشاء الـ الفرعيةرسم بياني ضمنه، سيؤدي هذا أيضا إلى تعريف اسم النمط `account-name/subgraph-name` - المستخدم لعمليات النشر و GraphQL endpoints. _لا يمكن تغيير هذا الحقل لاحقا._ -**Subtitle** - النص الذي سيظهر في بطاقات الـ subgraph. +**حساب** - الحساب الذي تم إنشاء الـ الفرعيةرسم بياني ضمنه. يمكن أن يكون هذا حساب فرد أو منظمة. _لا يمكن نقل الـ الفرعيةرسم بياني بين الحسابات لاحقا._ -**Description** - وصف الـ subgraph ، ويكون مرئيا في صفحة تفاصيل الـ subgraph. +**العنوان الفرعي** - النص الذي سيظهر في بطاقات الـ الفرعيةرسم بياني. -**GitHub URL** - رابط لمستودع(repository) الـ subgraph على GitHub. +**وصف** - وصف الـ الفرعيةرسم بياني ، ويكون مرئيا في صفحة تفاصيل الـ الفرعيةرسم بياني. -**Hide** - يؤدي تشغيل هذا إلى إخفاء الـ subgraph في Graph Explorer. +** جيثب رابط** - رابط لمستودع الـ الفرعيةرسم بياني على جيثب. -بعد حفظ الـ subgraph الجديد ، تظهر لك شاشة تحتوي على تعليمات حول كيفية تثبيت Graph CLI ، وكيفية توليد ركائز لـ subgraph الجديد ، وكيفية نشر الـ subgraph. تمت تغطية أول خطوتين في [ قسم تعريف Subgraph ](/developing/defining-a-subgraph). +**يخفي** - يؤدي تشغيل هذا إلى إخفاء الـ الفرعيةرسم بياني في مستكشف الرسم البياني. -## نشر Subgraph على الخدمة المستضافة (Hosted Service) +After saving the new subgraph, you are shown a screen with help on how to install the Graph CLI, how to generate the scaffolding for a new subgraph, and how to deploy your subgraph. The first two steps were covered in the [Defining a Subgraph section](/developing/defining-a-subgraph). -سيؤدي نشر الـ subgraph الخاص بك إلى رفع ملفاته والتي قمت بإنشائها باستخدام `yarn build` إلى IPFS وإخبار Graph Explorer ببدء فهرسة الـ subgraph باستخدام هذه الملفات. +## نشر الفرعيةرسم بياني على الخدمة المستضافة -يمكنك نشر الـ subgraph عن طريق تنفيذ `yarn deploy` +سيؤدي نشر الـ الفرعيةرسم بياني الخاص بك إلى رفع ملفاته والتي قمت بإنشائها باستخدام `yarn build` إلى IPFS وإخبار مستكشف الرسم البياني ببدء فهرسة الـ الفرعيةرسم بياني باستخدام هذه الملفات. -بعد نشر الـ subgraph ، سيعرض Graph Explorer حالة مزامنة الـ subgraph الخاص بك. واعتمادا على كمية البيانات وعدد الأحداث التي يجب استخراجها من كتل Ethereum التاريخية ، بدءا من genesis block ، يمكن أن تستغرق المزامنة من بضع دقائق إلى عدة ساعات. وتتحول حالة الـ subgraph إلى `Synced` بمجرد أن تستخرج Graph Node جميع البيانات من الكتل التاريخية. سيستمر Graph Node في فحص كتل Ethereum للـ subgraph الخاص بك عندما يتم تعدين هذه الكتل. +يمكنك نشر الـ الفرعيةرسم بياني عن طريق تنفيذ `yarn deploy` -## إعادة نشر الـ Subgraph +After deploying the subgraph, the Graph Explorer will switch to showing the synchronization status of your subgraph. Depending on the amount of data and the number of events that need to be extracted from historical blocks, starting with the genesis block, syncing can take from a few minutes to several hours. -عند إجراء تغييرات على تعريف الـ subgraph الخاص بك ، على سبيل المثال لإصلاح مشكلة في كيانات(entity) الـ mappings، قم بتشغيل الأمر `yarn deploy` أعلاه مرة أخرى لنشر الإصدار المحدث من الـ subgraph الخاص بك. يتطلب أي تحديث لـ subgraph أن تقوم Graph Node بإعادة فهرسة الـ subgraph بالكامل ، بدءًا من genesis block. +The subgraph status switches to `Synced` once the Graph Node has extracted all data from historical blocks. The Graph Node will continue inspecting blocks for your subgraph as these blocks are mined. -إذا كان الـ subgraph المنشور سابقا لا يزال في حالة`Syncing` ، فسيتم استبداله على الفور بالإصدار المنشور حديثا. وإذا كان الـ subgraph المنشور سابقا متزامنا بالكامل بالفعل ، فسيقوم Graph Node بوضع علامة على الإصدار المنشور حديثا على أنه `Pending Version` ، ويتم مزامنته في الخلفية ، ويستبدل الإصدار المنشور حاليا بالإصدار الجديد بمجرد الانتهاء من مزامنة الإصدار الجديد. هذا يضمن أن لديك subgraph تعمل به أثناء مزامنة الإصدار الجديد. +## إعادة نشر الـ الفرعيةرسم بياني -## Deploying the subgraph to multiple Ethereum networks +When making changes to your subgraph definition, for example, to fix a problem in the entity mappings, run the `yarn deploy` command above again to deploy the updated version of your subgraph. Any update of a subgraph requires that Graph Node reindexes your entire subgraph, again starting with the genesis block. -In some cases, you will want to deploy the same subgraph to multiple Ethereum networks without duplicating all of its code. The main challenge that comes with this is that the contract addresses on these networks are different. +إذا كان الـ الفرعيةرسم بياني المنشور سابقا لا يزال في حالة`Syncing` ، فسيتم استبداله على الفور بالإصدار المنشور حديثا. وإذا كان الـ الفرعيةرسم بياني المنشور سابقا متزامنا بالكامل بالفعل ، فسيقوم Graph Node بوضع علامة على الإصدار المنشور حديثا على أنه `Pending Version` ، ويتم مزامنته في الخلفية ، ويستبدل الإصدار المنشور حاليا بالإصدار الجديد بمجرد الانتهاء من مزامنة الإصدار الجديد. هذا يضمن أن لديك الفرعيةرسم بياني تعمل به أثناء مزامنة الإصدار الجديد. -### graph-cli >=0.29.0 +## Deploying the subgraph to multiple networks -From version `0.29.0` the `build` command accepts two new options: +In some cases, you will want to deploy the same subgraph to multiple networks without duplicating all of its code. The main challenge that comes with this is that the contract addresses on these networks are different. -```sh -graph build [options] [] +### Using graph-cli + +Both `graph build` (since `v0.29.0`) and `graph deploy` (since `v0.32.0`) accept two new options: +```sh Options: ... - --network Network to use from networks.json - --network-file Networks file (default: "./networks.json") + --network Network configuration to use from the networks config file + --network-file Networks config file path (default: "./networks.json") ``` You can use the `--network` option to specify a network configuration from a `json` standard file (defaults to `networks.json`) to easily update your subgraph during development. **Note:** The `init` command will now auto-generate a `networks.json` based on the provided information. You will then be able to update existing or add additional networks. -If you don't have a `networks.json` file, you'll need to manually create one with the follwing structure: +If you don't have a `networks.json` file, you'll need to manually create one with the following structure: ```json { @@ -130,7 +132,7 @@ This is what your networks config file should look like: } ``` -Now we can run the following command: +Now we can run one of the following commands: ```sh # Using default networks.json file @@ -155,9 +157,19 @@ dataSources: kind: ethereum/events ``` -Now you are ready to `yarn deploy` +Now you are ready to `yarn deploy`. + +**Note:** As mentioned earlier, since `graph-cli 0.32.0` you can directly run `yarn deploy` with the `--network` option: + +```sh +# Using default networks.json file +yarn deploy --network goerli + +# Using custom named file +yarn deploy --network goerli --network-file path/to/config +``` -### graph-cli \<0.29.0 +### Using subgraph.yaml template One solution for older graph-cli versions that allows to parameterize aspects like contract addresses is to generate parts of it using a templating system like [Mustache](https://mustache.github.io/) or [Handlebars](https://handlebarsjs.com/). @@ -196,7 +208,7 @@ dataSources: kind: ethereum/events ``` -In order generate a manifest to either network, you could add two additional commands to `package.json` along with a dependency on `mustache`: +In order to generate a manifest to either network, you could add two additional commands to `package.json` along with a dependency on `mustache`: ```json { @@ -225,13 +237,13 @@ yarn prepare:goerli && yarn deploy A working example of this can be found [here](https://github.com/graphprotocol/example-subgraph/tree/371232cf68e6d814facf5e5413ad0fef65144759). -**Note:** This approach can also be applied more complex situations, where it is necessary to substitute more than contract addresses and network names or where generating mappings or ABIs from templates as well. +**Note:** This approach can also be applied to more complex situations, where it is necessary to substitute more than contract addresses and network names or where generating mappings or ABIs from templates as well. ## Checking subgraph health -If a subgraph syncs successfully, that is a good sign that it will continue to run well forever. However, new triggers on the chain might cause your subgraph to hit an untested error condition or it may start to fall behind due to performance issues or issues with the node operators. +If a subgraph syncs successfully, that is a good sign that it will continue to run well forever. However, new triggers on the network might cause your subgraph to hit an untested error condition or it may start to fall behind due to performance issues or issues with the node operators. -Graph Node exposes a graphql endpoint which you can query to check the status of your subgraph. On the Hosted Service, it is available at `https://api.thegraph.com/index-node/graphql`. On a local node it is available on port `8030/graphql` by default. The full schema for this endpoint can be found [here](https://github.com/graphprotocol/graph-node/blob/master/server/index-node/src/schema.graphql). Here is an example query that checks the status of the current version of a subgraph: +Graph Node exposes a graphql endpoint which you can query to check the status of your subgraph. On the Hosted Service, it is available at `https://api.thegraph.com/index-node/graphql`. On a local node, it is available on port `8030/graphql` by default. The full schema for this endpoint can be found [here](https://github.com/graphprotocol/graph-node/blob/master/server/index-node/src/schema.graphql). Here is an example query that checks the status of the current version of a subgraph: ```graphql { @@ -258,14 +270,22 @@ Graph Node exposes a graphql endpoint which you can query to check the status of } ``` -This will give you the `chainHeadBlock` which you can compare with the `latestBlock` on your subgraph to check if it is running behind. `synced` informs if the subgraph has ever caught up to the chain. `health` can currently take the values of `healthy` if no errors ocurred, or `failed` if there was an error which halted the progress of the subgraph. In this case you can check the `fatalError` field for details on this error. +This will give you the `chainHeadBlock` which you can compare with the `latestBlock` on your subgraph to check if it is running behind. `synced` informs if the subgraph has ever caught up to the chain. `health` can currently take the values of `healthy` if no errors occurred, or `failed` if there was an error which halted the progress of the subgraph. In this case, you can check the `fatalError` field for details on this error. -## Subgraph archive policy +## Hosted service subgraph archive policy -The Hosted Service is a free Graph Node indexer. Developers can deploy subgraphs indexing a range of networks, which will be indexed, and made available to query via graphQL. +The Hosted Service is a free Graph Node Indexer. Developers can deploy subgraphs indexing a range of networks, which will be indexed, and made available to query via graphQL. -To improve the performance of the service for active subgraphs, the Hosted Service will archive subgraphs which are inactive. +To improve the performance of the service for active subgraphs, the Hosted Service will archive subgraphs that are inactive. -**A subgraph is defined as "inactive" if it was deployed to the Hosted Service more than 45 days ago, and if it has received 0 queries in the last 30 days.** +**A subgraph is defined as "inactive" if it was deployed to the Hosted Service more than 45 days ago, and if it has received 0 queries in the last 45 days.** Developers will be notified by email if one of their subgraphs has been marked as inactive 7 days before it is removed. If they wish to "activate" their subgraph, they can do so by making a query in their subgraph's Hosted Service graphQL playground. Developers can always redeploy an archived subgraph if it is required again. + +## Subgraph Studio subgraph archive policy + +When a new version of a subgraph is deployed, the previous version is archived (deleted from the graph-node DB). This only happens if the previous version is not published to The Graph's decentralized network. + +When a subgraph version isn’t queried for over 45 days, that version is archived. + +Every subgraph affected with this policy has an option to bring the version in question back. diff --git a/website/pages/ar/deploying/deploying-a-subgraph-to-studio.mdx b/website/pages/ar/deploying/deploying-a-subgraph-to-studio.mdx index a58526173633..6a166c941265 100644 --- a/website/pages/ar/deploying/deploying-a-subgraph-to-studio.mdx +++ b/website/pages/ar/deploying/deploying-a-subgraph-to-studio.mdx @@ -1,17 +1,19 @@ --- -title: نشر Subgraph في Subgraph Studio +title: نشر الفرعيةرسم بياني في الفرعيةرسم بياني استوديو --- -يعد نشر الـ Subgraph في Subgraph Studio أمرًا بسيطًا للغاية. سينقلك هذا الدليل خلال الخطوات: +> Ensure the network your subgraph is indexing data from is [supported](/developing/supported-chains) on the decentralized network. -- تثبيت The Graph CLI (مع كل من yarn و npm) -- إنشاء الـ Subgraph الخاص بك في Subgraph Studio +These are the steps to deploy your subgraph to the Subgraph Studio: + +- Install The Graph CLI (with either yarn or npm) +- إنشاء الـ الفرعيةرسم بياني الخاص بك في الفرعيةرسم بياني استوديو - مصادقة حسابك من CLI -- نشر Subgraph في Subgraph Studio +- نشر الفرعيةرسم بياني في الفرعيةرسم بياني استوديو ## تثبيت Graph CLI -نحن نستخدم نفس CLI لنشر الـ subgraphs على [hosted service](https://thegraph.com/hosted-service/) الخاصة بنا وعلى [Subgraph Studio](https://thegraph.com/studio/). وفيما يلي أوامر تثبيت graph-cli. يمكن القيام بذلك باستخدام npm أو yarn. +نحن نستخدم نفس CLI لنشر الـ الفرعيةرسم بياني على [خدمة مستضافة](https://thegraph.com/hosted-service/) الخاصة بنا وعلى [ الفرعيةرسم بياني استوديو](https://thegraph.com/studio/). وفيما يلي أوامر تثبيت graph-cli. يمكن القيام بذلك باستخدام npm أو yarn. **التثبيت بواسطة yarn:** @@ -25,27 +27,27 @@ yarn global add @graphprotocol/graph-cli npm install -g @graphprotocol/graph-cli ``` -## إنشاء الـ Subgraph الخاص بك في Subgraph Studio +## إنشاء الـ خدمة مستضافة الخاص بك في الفرعيةرسم بياني استوديو -قبل نشر الـ subgraph الفعلي الخاص بك، فإنك بحاجة لإنشاء subgraph في [ Subgraph Studio ](https://thegraph.com/studio/). نوصيك بقراءة [ وثائق Studio ](/deploying/subgraph-studio) لمعرفة المزيد حول هذا الأمر. +Before deploying your actual subgraph you need to create a subgraph in [Subgraph Studio](https://thegraph.com/studio/). We recommend you read our [Studio documentation](/deploying/subgraph-studio) to learn more about this. -## تهيئة Subgraph الخاص بك +## تهيئة خدمة مستضافة الخاص بك -بمجرد إنشاء الـ subgraph الخاص بك في Subgraph Studio ، يمكنك بدء كود الـ subgraph باستخدام هذا الأمر: +بمجرد إنشاء الـ خدمة مستضافة الخاص بك في الفرعيةرسم بياني استوديو ، يمكنك بدء كود الـ الفرعيةرسم بياني باستخدام هذا الأمر: ```bash graph init --studio ``` -يمكن العثور على قيمة `` في صفحة تفاصيل الـ subgraph الخاص بك في Subgraph Studio: +يمكن العثور على قيمة `` في صفحة تفاصيل الـ الفرعيةرسم بياني الخاص بك في الفرعيةرسم بياني استوديو: ![Subgraph Studio - Slug](/img/doc-subgraph-slug.png) -بعد تشغيل `graph init` ، سيُطلب منك إدخال عنوان العقد والشبكة و abi التي تريد الاستعلام عنها. وسيؤدي القيام بذلك إلى إنشاء مجلد جديد على جهازك المحلي مع بعض الأكواد الأساسية لبدء العمل على الـ subgraph الخاص بك. يمكنك بعد ذلك إنهاء الـ subgraph الخاص بك للتأكد من أنه يعمل كما هو متوقع. +After running `graph init`, you will be asked to input the contract address, network, and ABI that you want to query. Doing this will generate a new folder on your local machine with some basic code to start working on your subgraph. You can then finalize your subgraph to make sure it works as expected. -## Graph Auth(مصادقة Graph) +## رسم بياني المصادقة -قبل أن تتمكن من نشر الـ subgraph الخاص بك في Subgraph Studio ، ستحتاج إلى تسجيل الدخول إلى حسابك ضمن CLI. للقيام بذلك ، ستحتاج إلى مفتاح النشر الخاص بك الذي يمكنك العثور عليه في صفحة "My Subgraphs" أو في صفحة تفاصيل الـ subgraph. +Before being able to deploy your subgraph to Subgraph Studio, you need to login into your account within the CLI. To do this, you will need your deploy key that you can find on your "My Subgraphs" page or your subgraph details page. إليك الأمر الذي تحتاج إلى استخدامه للمصادقة من CLI: @@ -53,16 +55,16 @@ graph init --studio graph auth --studio ``` -## نشر Subgraph في Subgraph Studio +## نشر الفرعيةرسم بياني في الفرعيةرسم بياني استوديو -بمجرد أن تصبح جاهزًا ، يمكنك نشر الـ subgraph الخاص بك في Subgraph Studio. لن يؤدي القيام بذلك إلى نشر الـ subgraph الخاص بك إلى الشبكة اللامركزية ، بل سيتم نشره فقط في حساب Studio الخاص بك حيث ستتمكن من اختباره وتحديث البيانات الوصفية (metadata). +بمجرد أن تصبح جاهزًا ، يمكنك نشر الـ الفرعيةرسم بياني الخاص بك في الفرعيةرسم بياني استوديو. لن يؤدي القيام بذلك إلى نشر الـ الفرعيةرسم بياني الخاص بك إلى الشبكة اللامركزية ، بل سيتم نشره فقط في حساب استوديو الخاص بك حيث ستتمكن من اختباره وتحديث البيانات الوصفية. -إليك أمر CLI والذي تحتاج إلى استخدامه لنشر الـ subgraph الخاص بك. +إليك أمر CLI والذي تحتاج إلى استخدامه لنشر الـ الفرعيةرسم بياني الخاص بك. ```bash graph deploy --studio ``` -بعد تشغيل هذا الأمر ، سيطلب الـ CLI أن تقوم بتسمية الإصدار ، ويمكنك تسميته كما تريد ، يمكنك استخدام تسميات مثل `0.1` و `0.2` أو استخدام الأحرف مثل `uniswap-v2-0.1`. ستكون هذه التسميات مرئية في Graph Explorer ويمكن استخدامها من قبل المنسقين (curators) لتقرير ما إذا كانوا يريدون الإشارة إلى هذا الإصدار أم لا ، لذا اختر بحكمة. +After running this command, the CLI will ask for a version label, you can name it however you want, you can use labels such as `0.1` and `0.2` or use letters as well such as `uniswap-v2-0.1`. Those labels will be visible in Graph Explorer and can be used by curators to decide if they want to signal on this version or not, so choose them wisely. -بمجرد النشر(deploy) ، يمكنك اختبار الـ subgraph الخاص بك في Subgraph Studio باستخدام playground، ونشر(deploy) إصدار آخر إذا لزم الأمر ، وتحديث البيانات الوصفية ، وعندما تكون جاهزًا ، قم بنشر(publish) الـ subgraph الخاص بك إلى Graph Explorer. +بمجرد النشر ، يمكنك اختبار الـ الفرعيةرسم بياني الخاص بك في الفرعيةرسم بياني استوديو باستخدام playground، ونشر إصدار آخر إذا لزم الأمر ، وتحديث البيانات الوصفية ، وعندما تكون جاهزًا ، قم بنشر الـ الفرعيةرسم بياني الخاص بك إلى مستكشف الرسم البياني. diff --git a/website/pages/ar/deploying/hosted-service.mdx b/website/pages/ar/deploying/hosted-service.mdx index 119b03a765c3..6be25961d626 100644 --- a/website/pages/ar/deploying/hosted-service.mdx +++ b/website/pages/ar/deploying/hosted-service.mdx @@ -1,18 +1,22 @@ --- -title: ما هي الخدمة المستضافة (Hosted Service)؟ +title: ما هي الخدمة المستضافة؟ --- -سيرشدك هذا القسم لنشر subgraph على الـخدمة المستضافة، والمعروفة باسم [Hosted Service.](https://thegraph.com/hosted-service/) وكتذكير ، الـ Hosted Service لن يغلق قريبا وسننهي الخدمة المستضافة تدريجيا بمجرد أن نصل إلى ميزات مساوية للشبكة اللامركزية. لا تزال الـ subgraphs المنشورة على الخدمة المستضافة متاحة [ هنا. ](https://thegraph.com/hosted-service/) +> Please note, the Hosted Service will begin sunsetting in Q1 2023, but it will remain available to networks that are not supported on the decentralized network. Developers are encouraged to [migrate their subgraphs](https://thegraph.com/blog/how-to-migrate-ethereum-subgraph) as more networks are supported. Each network will have their hosted service equivalents gradually sunset to ensure developers have enough time to migrate subgraphs to the decentralized network. Read more about the sunsetting of the Hosted Service [here](https://thegraph.com/blog/sunsetting-hosted-service). -إذا لم يكن لديك حساب على Hosted Service ، فيمكنك التسجيل باستخدام حساب Github الخاص بك. وبمجرد المصادقة ، يمكنك البدء في إنشاء subgraphs من خلال واجهة المستخدم ونشرها من الـ terminal الخاص بك. يدعم Graph Node عددا من Ethereum testnets (Rinkeby و Goerli) بالإضافة إلى mainnet. +This section will walk you through deploying a subgraph to the [Hosted Service](https://thegraph.com/hosted-service/). + +If you don't have an account on the Hosted Service, you can sign up with your GitHub account. Once you authenticate, you can start creating subgraphs through the UI and deploying them from your terminal. The Hosted Service supports a number of networks, such as Polygon, Gnosis Chain, BNB Chain, Optimism, Arbitrum, and more. + +For a comprehensive list, see [Supported Networks](/developing/supported-networks/#hosted-service). ## إنشاء الـ Subgraph -اتبع أولاً التعليمات [ هنا ](/developing/defining-a-subgraph) لتثبيت Graph CLI. قم بإنشاء subgraph عن طريق تمرير `graph init --product hosted-service` +First follow the instructions [here](/developing/defining-a-subgraph) to install the Graph CLI. Create a subgraph by passing in `graph init --product hosted-service` ### من عقد موجود -إذا كان لديك بالفعل عقد ذكي تم نشره على شبكة Ethereum mainnet أو إحدى شبكات testnets ، فإن تمهيد subgraph جديد من هذا العقد يمكن أن يكون طريقة جيدة للبدء في Hosted Service. +If you already have a smart contract deployed to your network of choice, bootstrapping a new subgraph from this contract can be a good way to get started on the Hosted Service. يمكنك استخدام هذا الأمر لإنشاء subgraph يقوم بفهرسة جميع الأحداث من عقد موجود. هذا سيحاول جلب ABI العقد من [ Etherscan ](https://etherscan.io/). @@ -30,7 +34,7 @@ graph init \ --abi \ ``` -الـ `` في هذه الحالة هو اسم المستخدم في github أو اسم المؤسسة الخاص بك ،`` هو اسم الـ subgraph الخاص بك ، و `` هو الاسم الاختياري للدليل حيث graph init سيضع مثال subgraph manifest. الـ `` هو عنوان عقدك الحالي.`` هو اسم شبكة Ethereum التي يسري فيه العقد.`` هو مسار محلي لملف ABI العقد. **كل من network-- و abi-- اختيارية.** +The `` in this case is your GitHub user or organization name, `` is the name for your subgraph, and `` is the optional name of the directory where `graph init` will put the example subgraph manifest. The `` is the address of your existing contract. `` is the name of the network that the contract lives on. `` is a local path to a contract ABI file. **Both `--network` and `--abi` are optional.** ### من مثال Subgraph @@ -40,40 +44,8 @@ graph init \ graph init --from-example --product hosted-service / [] ``` -يعتمد مثال الـ subgraph على عقد Gravity بواسطة Dani Grant الذي يدير avatars للمستخدم ويصدر أحداث `NewGravatar` أو `UpdateGravatar` كلما تم إنشاء avatars أو تحديثها. حيث يعالج الـ subgraph هذه الأحداث عن طريق كتابة كيانات `Gravatar` إلى مخزن Graph Node والتأكد من تحديثها وفقا للأحداث. انتقل إلى [subgraph manifest](/developing/creating-a-subgraph#the-subgraph-manifest) لفهم أفضل لـ mappings والأحداث من عقودك الذكية التي يجب الانتباه إليها و والمزيد. +The example subgraph is based on the Gravity contract by Dani Grant that manages user avatars and emits `NewGravatar` or `UpdateGravatar` events whenever avatars are created or updated. The subgraph handles these events by writing `Gravatar` entities to the Graph Node store and ensuring these are updated according to the events. Continue on to the [subgraph manifest](/developing/creating-a-subgraph#the-subgraph-manifest) to better understand which events from your smart contracts to pay attention to, mappings, and more. ## الشبكات المدعومة على الـ Hosted Service -يرجى ملاحظة أن الشبكات التالية مدعومة على Hosted Service. والشبكات خارج Ethereum mainnet ('mainnet') غير مدعومة حاليا على [The Graph Explorer.](https://thegraph.com/explorer) - -- `mainnet` -- `rinkeby` -- `goerli` -- `poa-core` -- `poa-sokol` -- `gnosis` -- `near-mainnet` -- `near-testnet` -- `matic` -- `mumbai` -- `fantom` -- `bnb` -- `chapel` -- `clover` -- `avalanche` -- `fuji` -- `celo` -- `celo-alfajores` -- `fuse` -- `moonbeam` -- `moonriver` -- `mbase` (Moonbeam/Moonriver Testnet) -- `arbitrum-one` -- `arbitrum-rinkeby` -- `arbitrum-goerli` -- `optimism` -- `optimism-goerli` -- `aurora` -- `aurora-testnet` -- `harmony` -- `zkSync2-testnet` +You can find the list of the supported networks [Here](/developing/supported-networks). diff --git a/website/pages/ar/deploying/subgraph-studio-faqs.mdx b/website/pages/ar/deploying/subgraph-studio-faqs.mdx index 82843615b88c..4f2b98e4a99f 100644 --- a/website/pages/ar/deploying/subgraph-studio-faqs.mdx +++ b/website/pages/ar/deploying/subgraph-studio-faqs.mdx @@ -1,27 +1,31 @@ --- -title: الأسئلة الشائعة حول Subgraph Studio +title: الأسئلة الشائعة حول الفرعيةرسم بياني استوديو --- -### 1. كيف يمكنني إنشاء مفتاح API؟ +### 1. What is Subgraph Studio? -في Subgraph Studio ، يمكنك إنشاء API Keys وذلك حسب الحاجة وإضافة إعدادات الأمان لكل منها. +[Subgraph Studio](https://thegraph.com/studio/) is a dapp for creating, managing, and publishing subgraphs and API keys. -### 2. هل يمكنني إنشاء أكثر من API Keys؟ +### 2. How do I create an API Key? -A: نعم يمكنك إنشاء أكثر من API Keys وذلك لاستخدامها في مشاريع مختلفة. تحقق من الرابط [هنا](https://thegraph.com/studio/apikeys/). +To create an API, navigate to the Subgraph Studio and connect your wallet. You will be able to click the API keys tab at the top. There, you will be able to create an API key. -### 3. كيف أقوم بتقييد نطاق مفتاح API؟ +### 3. Can I create multiple API Keys? -بعد إنشاء مفتاح API ، يمكنك في قسم Security تعريف المجالات التي يمكنها الاستعلام عن مفتاح API محدد. +Yes! You can create multiple API Keys to use in different projects. Check out the link [here](https://thegraph.com/studio/apikeys/). -### 4. هل يمكنني نقل الـ subgraph الخاص بي إلى مالك آخر؟ +### 4. How do I restrict a domain for an API Key? -نعم ، الـ subgraphs التي تم نشرها على Mainnet يمكن نقلها إلى محفظة جديدة أو إلى Multisig. يمكنك القيام بذلك عن طريق النقر فوق النقاط الثلاث الموجودة بجوار زر "Publish" في صفحة تفاصيل الـ subgraph واختيار "Transfer ownership". +After creating an API Key, in the Security section, you can define the domains that can query a specific API Key. -لاحظ أنك لن تتمكن من رؤية الـ subgraph أو تحريره في Studio بمجرد نقله. +### 5. Can I transfer my subgraph to another owner? -### 5. كيف يمكنني العثور على URLs الاستعلام لـ subgraphs إذا لم أكن مطورا لـ subgraph الذي أريد استخدامه؟ +نعم ، الـ الفرعيةرسم بياني التي تم نشرها على Mainnet يمكن نقلها إلى محفظة جديدة أو إلى Multisig. يمكنك القيام بذلك عن طريق النقر فوق النقاط الثلاث الموجودة بجوار زر "Publish" في صفحة تفاصيل الـ الفرعيةرسم بياني واختيار "Transfer ownership". -يمكنك العثور على URL الاستعلام(query URL) لكل subgraph في قسم Subgraph Details في The Graph Explorer. عند النقر فوق الزر "Query" ، سيتم توجيهك إلى نافذة حيث يمكنك عرض URL الاستعلام لـ subgraph الذي تهتم به. ويمكنك بعد ذلك استبدال `` بمفتاح API الذي ترغب في الاستفادة منه في Subgraph Studio. +لاحظ أنك لن تتمكن من رؤية الـ الفرعيةرسم بياني أو تحريره في استوديو بمجرد نقله. -تذكر أنه يمكنك إنشاء API key والاستعلام عن أي subgraph منشور على الشبكة ، حتى إذا قمت ببناء subgraph بنفسك. حيث أن الاستعلامات عبر API key الجديد ، هي استعلامات مدفوعة مثل أي استعلامات أخرى على الشبكة. +### 6. How do I find query URLs for subgraphs if I’m not the developer of the subgraph I want to use? + +يمكنك العثور على URL الاستعلام لكل الفرعيةرسم بياني في قسم Subgraph Details في مستكشف الرسم البياني. عند النقر فوق الزر "Query" ، سيتم توجيهك إلى نافذة حيث يمكنك عرض URL الاستعلام لـ الفرعيةرسم بياني الذي تهتم به. ويمكنك بعد ذلك استبدال `` بمفتاح API الذي ترغب في الاستفادة منه في الفرعيةرسم بياني استوديو. + +تذكر أنه يمكنك إنشاء API key والاستعلام عن أي الفرعيةرسم بياني منشور على الشبكة ، حتى إذا قمت ببناء الفرعيةرسم بياني بنفسك. حيث أن الاستعلامات عبر API key الجديد ، هي استعلامات مدفوعة مثل أي استعلامات أخرى على الشبكة. diff --git a/website/pages/ar/deploying/subgraph-studio.mdx b/website/pages/ar/deploying/subgraph-studio.mdx index c9434d838f85..c22fb0368414 100644 --- a/website/pages/ar/deploying/subgraph-studio.mdx +++ b/website/pages/ar/deploying/subgraph-studio.mdx @@ -1,123 +1,95 @@ --- -title: كيفية استخدام Subgraph Studio +title: كيفية استخدام الفرعيةرسم بياني استوديو --- مرحبًا بك في منصة الاطلاق الجديدة الخاصة بك 👩🏽‍🚀 -يعد Subgraph Studio مكانك لبناء وإنشاء الـ subgraphs وإضافة البيانات الوصفية (metadata) ونشرها على المستكشف(Explorer) اللامركزي الجديد (المزيد حول هذا [ هنا ](/network/explorer)). +The Subgraph Studio is your place to build and create subgraphs, add metadata, and publish them to the new decentralized Explorer (more on that [here](/network/explorer)). -ما يمكنك القيام به في Subgraph Studio: +ما يمكنك القيام به في الفرعيةرسم بياني استوديو: -- إنشاء subgraph من خلال Studio UI -- نشر subgraph باستخدام CLI -- نشر subgraph باستخدام Studio UI -- اختبار الـ subgraph في playground +- إنشاء الفرعيةرسم بياني من خلال استوديو UI +- نشر الفرعيةرسم بياني باستخدام CLI +- نشر الفرعيةرسم بياني باستخدام استوديو UI +- اختبار الـ الفرعيةرسم بياني في playground - دمجه في المنصة باستخدام عنوان URL الاستعلام -- إنشاء وإدارة مفاتيح API الخاصة بك لـ subgraphs محددة +- إنشاء وإدارة مفاتيح API الخاصة بك لـ الفرعيةرسم بياني محددة -هنا في Subgraph Studio ، لديك سيطرة كاملة على الـ subgraphs الخاصة بك. حيث لا يمكنك اختبار الـ subgraphs الخاصة بك قبل نشرها فحسب، ولكن يمكنك أيضا تقييد مفاتيح API الخاصة بك على نطاقات محددة والسماح فقط لمفهرسين معينين بالاستعلام من مفاتيح API الخاصة بهم. +Here in the Subgraph Studio, you have full control over your subgraphs. Not only can you test your subgraphs before you publish them, but you can also restrict your API keys to specific domains and only allow certain Indexers to query from their API keys. -يولد الاستعلام عن الـ subgraphs رسوم استعلام ، وتُستخدم لمكافأة [المفهرسين](/network/indexing) على شبكة Graph. إذا كنت مطورا لـ dapp أو لـ subgraph ، فيمكنك من خلال Studio بناء subgraphs أفضل لدعم استعلاماتك أو استعلام مجتمعك. يتكون Studio من 5 أجزاء رئيسية: +Querying subgraphs generates query fees, used to reward [Indexers](/network/indexing) on the Graph network. If you’re a dapp developer or subgraph developer, the Studio will empower you to build better subgraphs to power your or your community’s queries. The Studio is comprised of 5 main parts: - التحكم في حساب المستخدم الخاص بك -- قائمة من الـ subgraphs التي قمت بإنشائها -- قسم لإدارة وعرض التفاصيل وتصور حالة subgraph محدد -- قسم لإدارة مفاتيح API الخاصة بك والتي ستحتاجها للاستعلام عن subgraph +- قائمة من الـ الفرعيةرسم بياني التي قمت بإنشائها +- A section to manage, view details and visualize the status of a specific subgraph +- قسم لإدارة مفاتيح API الخاصة بك والتي ستحتاجها للاستعلام عن الفرعيةرسم بياني - قسم لإدارة الفواتير الخاصة بك ## كيف تنشئ حسابك 1. سجّل الدخول باستخدام محفظتك - يمكنك القيام بذلك عبر MetaMask أو WalletConnect -1. بمجرد تسجيل الدخول ، سترى مفتاح النشر الفريد الخاص بك في الصفحة الرئيسية لحسابك. وسيسمح لك ذلك إما بنشر الـ subgraphs الخاصة بك أو إدارة مفاتيح API + الفواتير. سيكون لديك مفتاح نشر فريد يمكن إعادة إنشائه إذا كنت تعتقد أنه تم اختراقه. +1. Once you sign in, you will see your unique deploy key on your account home page. This will allow you to either publish your subgraphs or manage your API keys + billing. You will have a unique deploy key that can be re-generated if you think it has been compromised. -## كيف تنشئ الـ Subgraph الخاص بك في Subgraph Studio +## كيف تنشئ الـ الفرعيةرسم بياني الخاص بك في الفرعيةرسم بياني استوديو -هذا أفضل جزء! عندما تنشئ subgraph لأول مرة ، سيتم توجيهك لملء: +هذا أفضل جزء! عندما تنشئ الفرعيةرسم بياني لأول مرة ، سيتم توجيهك لملء: -- اسم الـ Subgraph الخاص بك +- اسم الـ الفرعيةرسم بياني الخاص بك - صورة - الوصف -- التصنيفات +- Categories (e.g. `DeFi`, `NFTs`, `Governance`) - الموقع إلكتروني -## توافق الـ Subgraph مع شبكة The Graph +## توافق الـ الفرعيةرسم بياني مع شبكة الرسم البياني -شبكة The Graph ليست قادرة بعد على دعم جميع مصادر البيانات & الميزات المتوفرة على Hosted Service. ولكي يتم دعمها من قبل المفهرسين على الشبكة ، يجب أن تكون الـ subgraphs: +The Graph Network is not yet able to support all of the data-sources & features available on the Hosted Service. In order to be supported by Indexers on the network, subgraphs must: -- تفهرس mainnet Ethereum +- Index a [supported network](/developing/supported-networks) - يجب ألا تستخدم أيًا من الميزات التالية: - - ipfs.cat & ipfs.map - - أخطاء غير فادحة(Non-fatal) - - تطعيم(Grafting) + - ipfs.cat و ipfs.map + - أخطاء غير فادحة + - تطعيم المزيد من الميزات والشبكات ستتم إضافتها إلى شبكة The Graph بشكل متزايد. -### تدفق دورة حياة الـ Subgraph +### تدفق دورة حياة الـ الفرعيةرسم بياني -![دورة حياة الـ Subgraph](/img/subgraph-lifecycle.png) +![دورة حياة الـ الفرعيةرسم بياني](/img/subgraph-lifecycle.png) -بعد إنشاء الـ subgraph الخاص بك، ستتمكن من نشره باستخدام [ CLI ](https://github.com/graphprotocol/graph-cli) أو واجهة سطر الأوامر. سيؤدي نشر subgraph باستخدام CLI إلى دفع الـ subgraph إلى Studio حيث ستتمكن من اختبار الـ subgraphs باستخدام playground. سيسمح لك هذا في النهاية بالنشر على شبكة Graph. لمزيد من المعلومات حول إعداد CLI ، [ راجع هذا](/developing/defining-a-subgraph#install-the-graph-cli) (pst ، تأكد من توفر مفتاح النشر لديك). تذكر أن النشر(deploying)**يختلف عن** النشر(publishing). عندما تنشر (deploying) الـ subgraph، فأنت تدفعه إلى Studio حيث يمكنك اختباره. وفي المقابل ، عندما تنشر(publishing) الـ subgraph ، فإنك تنشره على السلسلة (on-chain). +After you have created your subgraph, you will be able to deploy it using the [CLI](https://github.com/graphprotocol/graph-cli), or command-line interface. Deploying a subgraph with the CLI will push the subgraph to the Studio where you’ll be able to test subgraphs using the playground. This will eventually allow you to publish to the Graph Network. For more information on CLI setup, [check this out](/developing/defining-a-subgraph#install-the-graph-cli) (pst, make sure you have your deploy key on hand). Remember, deploying is **not the same as** publishing. When you deploy a subgraph, you just push it to the Studio where you’re able to test it. Versus, when you publish a subgraph, you are publishing it on-chain. -## اختبار الـ Subgraph الخاص بك في Subgraph Studio +## اختبار الـ الفرعيةرسم بياني الخاص بك في الفرعيةرسم بياني استوديو -إذا كنت ترغب في اختبار الـ subgraph قبل نشره على الشبكة ، فيمكنك القيام بذلك في Subgraph **Playground** أو إلقاء نظرة على سجلاتك. ستخبرك سجلات الـ Subgraph ** أين ** يفشل الـ subgraph في حالة حدوث ذلك. +إذا كنت ترغب في اختبار الـ الفرعيةرسم بياني قبل نشره على الشبكة ، فيمكنك القيام بذلك في الفرعيةرسم بياني **Playground** أو إلقاء نظرة على سجلاتك. ستخبرك سجلات الـ الفرعيةرسم بياني ** أين ** يفشل الـ الفرعيةرسم بياني في حالة حدوث ذلك. -## نشر الـ Subgraph الخاص بك في Subgraph Studio +## نشر الـ الفرعيةرسم بياني الخاص بك في الفرعيةرسم بياني استوديو -لقد نجحت في الوصول إلى هذا الحد - تهانينا! نشر الـ subgraph يعني أنه تم إنشاء IPFS hash عند نشرك لـ subgraph ضمن CLI وتخزينه في عقود Ethereum الذكية للشبكة. ولنشر الـ subgraph الخاص بك بنجاح ، ستحتاج إلى اتباع الخطوات التالية الموجزة في هذه [ المدونة ](https://thegraph.com/blog/building-with-subgraph-studio). راجع الفيديو أدناه أيضًا: +You’ve made it this far - congrats! - - -تذكر ، أثناء تقدمك في تدفق النشر ، ستتمكن من الدفع(push) إما إلى mainnet أو Rinkeby ، وهي testnet التي ندعمها. إذا كنت مطور subgraph لأول مرة ، فنحن نقترح بشدة أن تبدأ بالنشر على Rinkeby ، وهو مجاني. سيسمح لك ذلك بمعرفة كيفية عمل الـ subgraph في The Graph Explorer وسيسمح لك باختبار عناصر التنسيق. - -ستتمكن فقط من فهرسة البيانات من mainnet (حتى إذا تم نشر الـ subgraph الخاص بك على testnet) لأنه لا يمكن نشر سوى الـ subgraphs التي تقوم بفهرسة بيانات mainnet. وذلك لأن المفهرسين يحتاجون إلى تقديم إثبات إلزامي لسجلات الفهرسة بدءا من block hash معين. نظرًا لأن نشر subgraph هو إجراء على-سلسلة (on-chain) ، فالإجراء يمكن أن يستغرق بضع دقائق. أي عنوان تستخدمه لنشر العقد سيكون هو الوحيد القادر على نشر الإصدارات المستقبلية. لذا اختر بحكمة! - -الـ Subgraphs التي لها إشارة تنسيق يتم عرضها للمفهرسين بحيث يمكن فهرستها على الشبكة اللامركزية. يمكنك نشر الـ subgraphs والإشارة إليها في إجراء واحد ، مما يتيح لك صك أول إشارة تنسيق على الـ subgraph وتوفير تكاليف الغاز. ومن خلال إضافة إشارتك إلى الإشارة التي قدمها المنسقون لاحقًا ، سيكون للـ subgraph الخاص بك فرصة أكبر لتقديم الاستعلامات في النهاية. +In order to publish your subgraph successfully, you’ll need to go through the following steps outlined in this [blog](https://thegraph.com/blog/building-with-subgraph-studio). -** الآن بعد أن نشرت الـ subgraph الخاص بك ، دعنا ندخل في كيفية إدارتهم على أساس منتظم. ** لاحظ أنه لا يمكنك نشر الـ subgraph على الشبكة إذا قد فشلت المزامنة. يحدث هذا عادةً بسبب وجود أخطاء في الـ subgraph - ستخبرك السجلات بمكان وجود هذه المشكلات! +Check out the video overview below as well: -## تعديل إصدار الـ Subgraph الخاص بك باستخدام CLI - -قد يرغب المطورون في تحديث الـ subgraph الخاص بهم لعدة أسباب. في هذه الحالة ، يمكنك نشر إصدار جديد من الـ subgraph الخاص بك إلى Studio باستخدام CLI (سيكون خاصًا فقط في هذه المرحلة) وإذا كنت راضيًا عنه ، فيمكنك نشره إلى The Graph Explorer. سيؤدي هذا إلى إنشاء نسخة جديدة من الـ subgraph الخاص بك والذي يمكن للمنسقين البدء في الإشارة إليه وسيتمكن المفهرسون من فهرسة هذا الإصدار الجديد. - -حتى وقت قريب ، كان المطورون مضطرين لنشر(deploy) ونشر(publish) نسخة جديدة من الـ subgraph الخاص بهم على Explorer لتحديث البيانات الوصفية للـ subgraphs الخاص بهم. الآن ، يمكن للمطورين تحديث البيانات الوصفية لـ subgraphs ** دون الحاجة إلى نشر(publish) إصدار جديد **. يمكن للمطورين تحديث تفاصيل الـ subgraph الخاصة بهم في Studio (صورة الملف الشخصي والاسم والوصف وما إلى ذلك) عن طريق تحديد خيار يسمى ** Update Details ** في The Graph Explorer. إذا تم تحديد هذا الخيار ، فسيتم إنشاء إجراء on-chain والذي يقوم بتحديث تفاصيل الـ subgraph في Explorer دون الحاجة إلى نشر(publish) إصدار جديد مع نشر(deployment) جديد. + -يرجى ملاحظة أن هناك تكاليف مرتبطة بنشر نسخة جديدة من subgraph على الشبكة. بالإضافة إلى رسوم الإجراء ، يجب على المطورين أيضًا تمويل جزء من ضريبة التنسيق لإشارة الترحيل التلقائي. لا يمكنك نشر نسخة جديدة من الـ subgraph الخاص بك إذا لم يشر إليه المنسقون. لمزيد من المعلومات حول مخاطر التنسيق، يرجى قراءة المزيد [ هنا ](/network/curating). +Remember, while you’re going through your publishing flow, you’ll be able to push to either mainnet or Goerli. If you’re a first-time subgraph developer, we highly suggest you start with publishing to Goerli, which is free to do. This will allow you to see how the subgraph will work in The Graph Explorer and will allow you to test curation elements. -### الأرشفة التلقائية لإصدارات الـ Subgraph +Indexers need to submit mandatory Proof of Indexing records as of a specific block hash. Because publishing a subgraph is an action taken on-chain, remember that the transaction can take up to a few minutes to go through. Any address you use to publish the contract will be the only one able to publish future versions. Choose wisely! -كلما قمت بنشر إصدار subgraph جديد في Subgraph Studio ، سيتم أرشفة الإصدار السابق. لن تتم فهرسة / مزامنة الإصدارات المؤرشفة ، وبالتالي لا يمكن الاستعلام عنها. يمكنك إلغاء أرشفة نسخة مؤرشفة من الـ subgraph الخاص بك في Studio UI. يرجى ملاحظة أن الإصدارات السابقة من الـ subgraphs غير المنشورة (non-publishe) التي تم نشرها (deployed) في Studio ستتم أرشفتها تلقائيا. +الـ الفرعيةرسم بياني التي لها إشارة تنسيق يتم عرضها للمفهرسين بحيث يمكن فهرستها على الشبكة اللامركزية. يمكنك نشر الـ الفرعيةرسم بياني والإشارة إليها في إجراء واحد ، مما يتيح لك صك أول إشارة تنسيق على الـ الفرعيةرسم بياني وتوفير تكاليف الغاز. ومن خلال إضافة إشارتك إلى الإشارة التي قدمها المنسقون لاحقًا ، سيكون للـ الفرعيةرسم بياني الخاص بك فرصة أكبر لتقديم الاستعلامات في النهاية. -![Subgraph Studio -إلغاء أرشفة](/img/Unarchive.png) +** الآن بعد أن نشرت الـ الفرعيةرسم بياني الخاص بك ، دعنا ندخل في كيفية إدارتهم على أساس منتظم. ** لاحظ أنه لا يمكنك نشر الـ الفرعيةرسم بياني على الشبكة إذا قد فشلت المزامنة. يحدث هذا عادةً بسبب وجود أخطاء في الـ الفرعيةرسم بياني - ستخبرك السجلات بمكان وجود هذه المشكلات! -## إدارة مفاتيح API الخاصة بك +## تعديل إصدار الـ الفرعيةرسم بياني الخاص بك باستخدام CLI -بغض النظر عما إذا كنت مطور dapp أو مطور subgraph ، فستحتاج إلى إدارة مفاتيح API الخاصة بك. وهذا مهم بالنسبة لك لتكون قادرا على الاستعلام عن الـ subgraphs لأن مفاتيح API تضمن أن الربط بين خدمات التطبيق صحيحة ومرخصة. يتضمن ذلك مصادقة المستخدم والجهاز المستخدم للتطبيق. +Developers might want to update their subgraph, for a variety of reasons. When this is the case, you can deploy a new version of your subgraph to the Studio using the CLI (it will only be private at this point) and if you are happy with it, you can publish this new deployment to The Graph Explorer. This will create a new version of your subgraph that curators can start signaling on and Indexers will be able to index this new version. -سيقوم Studio بسرد مفاتيح API الموجودة ، والتي ستمنحك القدرة على إدارتها أو حذفها. +Up until recently, developers were forced to deploy and publish a new version of their subgraph to the Explorer to update the metadata of their subgraphs. Now, developers can update the metadata of their subgraphs **without having to publish a new version**. Developers can update their subgraph details in the Studio (under the profile picture, name, description, etc) by checking an option called **Update Details** in The Graph Explorer. If this is checked, an on-chain transaction will be generated that updates subgraph details in the Explorer without having to publish a new version with a new deployment. -1. سيسمح لك قسم **Overview** بما يلي: - - تعديل اسم المفتاح الخاص بك - - إعادة إنشاء مفاتيح API - - عرض الاستخدام الحالي لمفتاح API مع الإحصائيات: - - عدد الاستعلامات - - كمية GRT التي تم صرفها -2. Under **Security**, you’ll be able to opt into security settings depending on the level of control you’d like to have over your API keys. In this section, you can: - - عرض وإدارة أسماء النطاقات المصرح لها باستخدام مفتاح API الخاص بك - - تعيين الـ subgraphs التي يمكن الاستعلام عنها باستخدام مفتاح API الخاص بك -3. Under **Indexer Preference**, you’ll be able to set different preferences for Indexers who are indexing subgraphs that your API key is used for. You can assign up to 5 points for each of these: - - **Fastest Speed**: Time between the query and the response from an indexer. If you mark this as important we will optimize for fast indexers. - - **Lowest Price**: The amount paid per query. If you mark this as important we will optimize for the less expensive indexers. - - **Data Freshness**: How recent the latest block an indexer has processed for the subgraph you are querying. If you mark this as important we will optimize to find the indexers with the freshest data. - - **Economic Security**: The amount of GRT an indexer can lose if they respond incorrectly to your query. If you mark this as important we will optimize for indexers with a large stake. -4. Under **Budget**, you’ll be able to update the maximum price per query. Note that we have a dynamic setting for that that's based on a volume discounting algorithm. **We strongly recommend using the default settings unless you are experiencing a specific problem.** Otherwise, you can update it under "Set a custom maximum budget". On this page you can also view different KPIs (in GRT and USD): - - Average cost per query - - Failed queries over max price - - Most expensive query +Please note that there are costs associated with publishing a new version of a subgraph to the network. In addition to the transaction fees, developers must also fund a part of the curation tax on the auto-migrating signal. You cannot publish a new version of your subgraph if curators have not signaled on it. For more information on the risks of curation, please read more [here](/network/curating). -## كيفية إدارة الـ Subgraph الخاص بك +### الأرشفة التلقائية لإصدارات الـ الفرعيةرسم بياني -سيكون لديك العديد من الأدوات تحت تصرفك لإدارة الـ subgraphs. ويمكنك تنظيم الـ subgraphs الخاصة بك حسب **الحالة(status)** و**الفئة(category)**. +كلما قمت بنشر إصدار الفرعيةرسم بياني جديد في الفرعيةرسم بياني استوديو، سيتم أرشفة الإصدار السابق. لن تتم فهرسة / مزامنة الإصدارات المؤرشفة ، وبالتالي لا يمكن الاستعلام عنها. يمكنك إلغاء أرشفة نسخة مؤرشفة من الـ الفرعيةرسم بياني الخاص بك في استوديو UI. يرجى ملاحظة أن الإصدارات السابقة من الـ الفرعيةرسم بياني غير المنشورة التي تم نشرها في استوديو ستتم أرشفتها تلقائيا. -- The **Status** tag allows you to pick between a variety of tags including ``, ``, ``, ``, etc. -- Meanwhile, **Category** allows you to designate what category your subgraph falls into. Options include ``, ``, ``, etc. +![الفرعيةرسم بياني استوديو -إلغاء أرشفة](/img/Unarchive.png) diff --git a/website/pages/ar/developing/assemblyscript-api.mdx b/website/pages/ar/developing/assemblyscript-api.mdx index 8b77643bdbc9..7f766913b8b8 100644 --- a/website/pages/ar/developing/assemblyscript-api.mdx +++ b/website/pages/ar/developing/assemblyscript-api.mdx @@ -1,26 +1,26 @@ --- -title: AssemblyScript API +title: أسيمبلي سكريبت API --- -> ملاحظة: إذا أنشأت رسمًا فرعيًا قبل إصدار `graph-cli` / `graph-ts` `0.22.0` ، فأنت تستخدم إصدارًا أقدم من AssemblyScript ، نوصي بإلقاء نظرة على [ `دليل الترحيل` ](/release-notes/assemblyscript-migration-guide) +> Note: if you created a subgraph prior to `graph-cli`/`graph-ts` version `0.22.0`, you're using an older version of AssemblyScript, we recommend taking a look at the [`Migration Guide`](/release-notes/assemblyscript-migration-guide) هذه الصفحة توثق APIs المضمنة التي يمكن استخدامها عند كتابة subgraph mappings. يتوفر نوعان من APIs خارج الصندوق: -- مكتبة Graph TypeScript(`graph-ts`) -- كود تم إنشاؤه من ملفات الـ subgraph بواسطة `graph codegen`. +- [مكتبة رسم بياني تيبسكريبت](https://github.com/graphprotocol/graph-ts)(`graph-ts`) +- كود تم إنشاؤه من ملفات الـ الفرعيةرسم بياني بواسطة `graph codegen`. -من الممكن أيضا إضافة مكتبات أخرى كـ dependencies، طالما أنها متوافقة مع [ AssemblyScript ](https://github.com/AssemblyScript/assemblyscript). نظرا لأنه تتم كتابة الـ mappings بهذه اللغة فإن [ AssemblyScript wiki ](https://github.com/AssemblyScript/assemblyscript/wiki) تعد مصدرا جيدا للغة ولميزات المكتبة القياسية. +من الممكن أيضا إضافة مكتبات أخرى كـ التبعيات، طالما أنها متوافقة مع [ أسيمبلي سكريبت ](https://github.com/AssemblyScript/assemblyscript). نظرا لأنه تتم كتابة الـ mappings بهذه اللغة فإن [ أسيمبلي سكريبت wiki ](https://github.com/AssemblyScript/assemblyscript/wiki) تعد مصدرا جيدا للغة ولميزات المكتبة القياسية. ## التثبيت -الـ Subgraphs التي تم إنشاؤها باستخدام [ `graph init` ](/developing/creating-a-subgraph) تأتي مع dependencies مكونة مسبقا. كل ما هو مطلوب لتثبيت هذه الـ dependencies هو تشغيل أحد الأوامر التالية: +Subgraphs created with [`graph init`](/developing/creating-a-subgraph) come with preconfigured dependencies. All that is required to install these dependencies is to run one of the following commands: ```sh yarn install # Yarn npm install # NPM ``` -إذا تم إنشاء الـ subgraph من البداية ، فسيقوم أحد الأمرين التاليين بتثبيت مكتبة Graph TypeScript كـ dependency: +إذا تم إنشاء الـ الفرعيةرسم بياني من البداية ، فسيقوم أحد الأمرين التاليين بتثبيت مكتبة رسم بياني تيبسكريبت كـ dependency: ```sh yarn add --dev @graphprotocol/graph-ts # Yarn @@ -31,13 +31,13 @@ npm install --save-dev @graphprotocol/graph-ts # NPM توفر مكتبة `graphprotocol / graph-ts@` الـ APIs التالية: -- واجهة برمجة تطبيقات `ethereum` للعمل مع عقود Ethereum الذكية والأحداث والكتل والإجرءات وقيم Ethereum. -- واجهة برمجة تطبيقات `store` لتحميل الـ entities وحفظها من وإلى مخزن Graph Node. -- واجهة برمجة تطبيقات `log` لتسجيل الرسائل إلى خرج Graph Node ومستكشف Graph Explorer. +- واجهة برمجة تطبيقات `ethereum` للعمل مع عقود إيثيريوم الذكية والأحداث والكتل والإجرءات وقيم إيثيريوم. +- واجهة برمجة تطبيقات `store` لتحميل الـ الكيانات وحفظها من وإلى مخزن Graph Node. +- واجهة برمجة تطبيقات `سجل` لتسجيل الرسائل إلى خرج Graph Node ومستكشف مستكشف الرسم البياني. - واجهة برمجة تطبيقات `ipfs` لتحميل الملفات من IPFS. - واجهة برمجة تطبيقات `json` لتحليل بيانات JSON. - واجهة برمجة تطبيقات `crypto` لاستخدام وظائف التشفير. -- الأوامر الأساسية منخفضة المستوى للترجمة بين أنظمة الأنواع المختلفة مثل Ethereum و JSON و GraphQL و AssemblyScript. +- الأوامر الأساسية منخفضة المستوى للترجمة بين أنظمة الأنواع المختلفة مثل إيثيريوم و JSON و GraphQL و أسيمبلي سكريبت. ### إصدارات @@ -45,15 +45,16 @@ npm install --save-dev @graphprotocol/graph-ts # NPM | الاصدار | ملاحظات الإصدار | | :-: | --- | -| 0.0.6 | تمت إضافة حقل `nonce` إلى كائن إجراء الـ Ethereum
تمت إضافة `baseFeePerGas` إلى كائن Ethereum Block | -| 0.0.5 | تمت ترقية AssemblyScript إلى الإصدار 0.19.10 (يرجى الاطلاع على [ `دليل الترحيل` ](/release-notes/assemblyscript-migration-guide))
`ethereum.transaction.gasUsed` أعيد تسميته إلى `ethereum.transaction.gasLimit` | -| 0.0.4 | تمت إضافة حقل `functionSignature` إلى كائن Ethereum SmartContractCall | -| 0.0.3 | تمت إضافةحقل `from` إلى كائن Ethereum Call
`etherem.call.address` تمت إعادة تسميته إلى `ethereum.call.to` | -| 0.0.2 | تمت إضافة حقل `input` إلى كائن إجراء Ethereum | +| 0.0.7 | Added `TransactionReceipt` and `Log` classes to the Ethereum types
Added `receipt` field to the Ethereum Event object | +| 0.0.6 | Added `nonce` field to the Ethereum Transaction object
Added `baseFeePerGas` to the Ethereum Block object | +| 0.0.5 | AssemblyScript upgraded to version 0.19.10 (this includes breaking changes, please see the [`Migration Guide`](/release-notes/assemblyscript-migration-guide))
`ethereum.transaction.gasUsed` renamed to `ethereum.transaction.gasLimit` | +| 0.0.4 | Added `functionSignature` field to the Ethereum SmartContractCall object | +| 0.0.3 | Added `from` field to the Ethereum Call object
`etherem.call.address` renamed to `ethereum.call.to` | +| 0.0.2 | Added `input` field to the Ethereum Transaction object | ### الأنواع المضمنة (Built-in) -يمكن العثور على الوثائق الخاصة بالأنواع الأساسية المضمنة في AssemblyScript في [ AssemblyScript wiki ](https://github.com/AssemblyScript/assemblyscript/wiki/Types). +يمكن العثور على الوثائق الخاصة بالأنواع الأساسية المضمنة في أسيمبلي سكريبت في [ أسيمبلي سكريبت ويكي ](https://github.com/AssemblyScript/assemblyscript/wiki/Types). يتم توفير الأنواع الإضافية التالية بواسطة `graphprotocol/graph-ts@`. @@ -65,7 +66,7 @@ npm install --save-dev @graphprotocol/graph-ts # NPM تمثل `ByteArray` مصفوفة `u8`. -_البناء(Construction)_ +_البناء_ - `fromI32(x: i32): ByteArray` - يحلل `x` إلى bytes. - `fromHexString(hex: string): ByteArray` - طول الإدخال يجب أن يكون زوجي. البادئة بـ `0x` اختيارية. @@ -82,7 +83,7 @@ _العوامل_ - `equals(y: ByteArray): bool` – يمكن كتابتها كـ `x == y`. - `concat(other: ByteArray) : ByteArray` - return a new `ByteArray` consisting of `this` directly followed by `other` -- `concatI32(other: i32) : ByteArray` - return a new `ByteArray` consisting of `this` directly follow by the byte representation of `other` +- `concatI32(other: i32) : ByteArray` - return a new `ByteArray` consisting of `this` directly followed by the byte representation of `other` #### BigDecimal @@ -92,7 +93,9 @@ _العوامل_ يستخدم `BigDecimal` للتعبير عن الكسور العشرية. -_البناء(Construction)_ +> Note: [Internally](https://github.com/graphprotocol/graph-node/blob/master/graph/src/data/store/scalar.rs) `BigDecimal` is stored in [IEEE-754 decimal128 floating-point format](https://en.wikipedia.org/wiki/Decimal128_floating-point_format), which supports 34 decimal digits of significand. This makes `BigDecimal` unsuitable for representing fixed-point types that can span wider than 34 digits, such as a Solidity [`ufixed256x18`](https://docs.soliditylang.org/en/latest/types.html#fixed-point-numbers) or equivalent. + +_البناء_ - `constructor(bigInt: BigInt)` – يُنشئ `BigDecimal` من `BigInt`. - `static fromString(s: string): BigDecimal` – يحلل من سلسلة عشرية. @@ -121,11 +124,11 @@ _رياضيات_ 'import { BigInt } from '@graphprotocol/graph-ts ``` -يستخدم `BigInt` لتمثيل أعداد صحيحة كبيرة. يتضمن ذلك قيم Ethereum من النوع `uint32` إلى `uint256` و `int64` إلى `int256`. كل شيء أدناه `uint32` ، مثل `int32` أو `uint24` أو `int8` يتم تمثيله كـ `i32`. +يستخدم `BigInt` لتمثيل أعداد صحيحة كبيرة. يتضمن ذلك قيم إيثيريوم من النوع `uint32` إلى `uint256` و `int64` إلى `int256`. كل شيء أدناه `uint32` ، مثل `int32` أو `uint24` أو `int8` يتم تمثيله كـ `i32`. تحتوي فئة `BigInt` على API التالية: -_البناء(Construction)_ +_البناء_ - `BigInt.fromI32 (x: i32): BigInt` - ينشئ `BigInt` من `i32`. - `BigInt.fromString(s: string): BigInt`– يحلل `BigInt` من سلسلة(string). @@ -136,7 +139,7 @@ _البناء(Construction)_ - `x.toHex(): string` – ترجع `BigInt` إلى سلسلة سداسية العشرية. - `x.toString(): string` – يقوم بإرجاع `BigInt` إلى سلسلة عدد عشري. -- `x.toI32 (): i32` - ترجع `BigInt` كـ `i32` ؛ تفشل إذا كانت القيمة لا تتناسب مع `i32`. إنها لفكرة جيدة أن تتحقق أولا من `()x.isI32`. +- `x.toI32(): i32` – returns the `BigInt` as an `i32`; fails if the value does not fit into `i32`. It's a good idea to first check `x.isI32()`. - `x.toBigDecimal (): BigDecimal` - يحول إلى رقم عشري بدون جزء كسري. _رياضيات_ @@ -169,7 +172,7 @@ _رياضيات_ 'import { TypedMap } from '@graphprotocol/graph-ts ``` -يمكن استخدام `TypedMap` لتخزين أزواج key-value. انظر [هذا المثال ](https://github.com/graphprotocol/aragon-subgraph/blob/29dd38680c5e5104d9fdc2f90e740298c67e4a31/individual-dao-subgraph/mappings/constants.ts#L51). +`TypedMap` can be used to store key-value pairs. See [this example](https://github.com/graphprotocol/aragon-subgraph/blob/29dd38680c5e5104d9fdc2f90e740298c67e4a31/individual-dao-subgraph/mappings/constants.ts#L51). تحتوي فئة `TypedMap` على API التالية: @@ -185,11 +188,11 @@ _رياضيات_ 'import { Bytes } from '@graphprotocol/graph-ts ``` -يتم استخدام `Bytes` لتمثيل مصفوفات بأطول عشوائية من الـ bytes. ويتضمن ذلك قيم إيثريوم من النوع `bytes` و `bytes32` وما إلى ذلك. +`Bytes` is used to represent arbitrary-length arrays of bytes. This includes Ethereum values of type `bytes`, `bytes32`, etc. -فئة `Bytes` ترث من [ Uint8Array ](https://github.com/AssemblyScript/assemblyscript/blob/3b1852bc376ae799d9ebca888e6413afac7b572f/std/assembly/typedarray.ts#L64) و لذا فهو يدعم جميع وظائف `Uint8Array` ، بالإضافة إلى الـ methods الجديدة التالية: +فئة `Bytes` ترث من [ Uint8Array ](https://github.com/AssemblyScript/assemblyscript/blob/3b1852bc376ae799d9ebca888e6413afac7b572f/std/assembly/typedarray.ts#L64) و لذا فهو يدعم جميع وظائف `Uint8Array` ، بالإضافة إلى الـ طُرق الجديدة التالية: -_البناء(Construction)_ +_البناء_ - `fromHexString(hex: string) : Bytes` - Convert the string `hex` which must consist of an even number of hexadecimal digits to a `ByteArray`. The string `hex` can optionally start with `0x` - `fromI32(i: i32) : Bytes` - Convert `i` to an array of bytes @@ -205,7 +208,7 @@ _العوامل_ - `b.concat(other: Bytes) : Bytes` - - return new `Bytes` consisting of `this` directly followed by `other` - `b.concatI32(other: i32) : ByteArray` - return new `Bytes` consisting of `this` directly follow by the byte representation of `other` -#### العنوان (Address) +#### العنوان ```typescript 'import { Address } from '@graphprotocol/graph-ts @@ -228,7 +231,7 @@ The `store` API allows to load, save and remove entities from and to the Graph N Entities written to the store map one-to-one to the `@entity` types defined in the subgraph's GraphQL schema. To make working with these entities convenient, the `graph codegen` command provided by the [Graph CLI](https://github.com/graphprotocol/graph-cli) generates entity classes, which are subclasses of the built-in `Entity` type, with property getters and setters for the fields in the schema as well as methods to load and save these entities. -#### إنشاء الكيانات (entities) +#### إنشاء الكيانات The following is a common pattern for creating entities from Ethereum events. @@ -275,7 +278,7 @@ if (transfer == null) { As the entity may not exist in the store yet, the `load` method returns a value of type `Transfer | null`. It may thus be necessary to check for the `null` case before using the value. -> **ملاحظة:** تحميل الكيانات ضروري فقط إذا كانت التغييرات التي تم إجراؤها في الـ mapping تعتمد على البيانات السابقة للكيان. انظر القسم التالي للتعرف على الطريقتين لتحديث الكيانات الموجودة. +> **Note:** Loading entities is only necessary if the changes made in the mapping depend on the previous data of an entity. See the next section for the two ways of updating existing entities. #### تحديث الكيانات الموجودة @@ -372,6 +375,7 @@ class Event { block: Block transaction: Transaction parameters: Array + receipt: TransactionReceipt | null } class Block { @@ -403,6 +407,34 @@ class Transaction { input: Bytes nonce: BigInt } + +class TransactionReceipt { + transactionHash: Bytes + transactionIndex: BigInt + blockHash: Bytes + blockNumber: BigInt + cumulativeGasUsed: BigInt + gasUsed: BigInt + contractAddress: Address + logs: Array + status: BigInt + root: Bytes + logsBloom: Bytes +} + +class Log { + address: Address + topics: Array + data: Bytes + blockHash: Bytes + blockNumber: Bytes + transactionHash: Bytes + transactionIndex: BigInt + logIndex: BigInt + transactionLogIndex: BigInt + logType: string + removed: bool | null +} ``` #### الوصول إلى حالة العقد الذكي Smart Contract @@ -412,12 +444,12 @@ The code generated by `graph codegen` also includes classes for the smart contra A common pattern is to access the contract from which an event originates. This is achieved with the following code: ```typescript -// Import the generated contract class -import { ERC20Contract } from '../generated/ERC20Contract/ERC20Contract' +// Import the generated contract class and generated Transfer event class +import { ERC20Contract, Transfer as TransferEvent } from '../generated/ERC20Contract/ERC20Contract' // Import the generated entity class import { Transfer } from '../generated/schema' -export function handleTransfer(event: Transfer) { +export function handleTransfer(event: TransferEvent) { // Bind the contract to the address that emitted the event let contract = ERC20Contract.bind(event.address) @@ -426,6 +458,8 @@ export function handleTransfer(event: Transfer) { } ``` +`Transfer` is aliased to `TransferEvent` here to avoid a naming conflict with the entity type + As long as the `ERC20Contract` on Ethereum has a public read-only function called `symbol`, it can be called with `.symbol()`. For public state variables a method with the same name is created automatically. Any other contract that is part of the subgraph can be imported from the generated code and can be bound to a valid address. @@ -582,7 +616,7 @@ let path = 'QmTkzDwWqPbnAh5YiV5VwcTLnGdwSNsNTn2aDxdXBFca7D/Makefile' let data = ipfs.cat(path) ``` -**Note:** `ipfs.cat` is not deterministic at the moment. If the file cannot be retrieved over the IPFS network before the request times out, it will return `null`. Due to this, it's always worth checking the result for `null`. To ensure that files can be retrieved, they have to be pinned to the IPFS node that Graph Node connects to. On the [hosted service](https://thegraph.com/hosted-service), this is [https://api.thegraph.com/ipfs/](https://api.thegraph.com/ipfs). See the [IPFS pinning](/developing/creating-a-subgraph#ipfs-pinning) section for more information. +**Note:** `ipfs.cat` is not deterministic at the moment. If the file cannot be retrieved over the IPFS network before the request times out, it will return `null`. Due to this, it's always worth checking the result for `null`. It is also possible to process larger files in a streaming fashion with `ipfs.map`. The function expects the hash or path for an IPFS file, the name of a callback, and flags to modify its behavior: @@ -667,8 +701,8 @@ When the type of a value is certain, it can be converted to a [built-in type](#b | المصدر(المصادر) | الغاية | دالة التحويل | | -------------------- | -------------------- | ---------------------------- | -| Address | Bytes | لا يوجد | -| Address | String | ()s.toHexString | +| العنوان | Bytes | لا يوجد | +| العنوان | String | s.toHexString() | | BigDecimal | String | s.toString() | | BigInt | BigDecimal | s.toBigDecimal() | | BigInt | String (hexadecimal) | s.toHexString() or s.toHex() | @@ -697,13 +731,14 @@ When the type of a value is certain, it can be converted to a [built-in type](#b | JSON | string | s.toString() | | JSON | Array | s.toArray() | | JSON | Object | s.toObject() | -| String | العنوان (Address) | Address.fromString(s) | +| String | العنوان | Address.fromString(s) | +| Bytes | العنوان | Address.fromBytes(s) | | String | BigInt | BigInt.fromString(s) | | String | BigDecimal | BigDecimal.fromString(s) | | String (hexadecimal) | Bytes | ByteArray.fromHexString(s) | | String (UTF-8) | Bytes | ByteArray.fromUTF8(s) | -### البيانات الوصفية لمصدر البيانات +### Data Source Metadata You can inspect the contract address, network and context of the data source that invoked the handler through the `dataSource` namespace: @@ -711,7 +746,7 @@ You can inspect the contract address, network and context of the data source tha - `dataSource.network(): string` - `dataSource.context(): DataSourceContext` -### الكيان و DataSourceContext +### Entity and DataSourceContext The base `Entity` class and the child `DataSourceContext` class have helpers to dynamically set and get fields: @@ -727,3 +762,10 @@ The base `Entity` class and the child `DataSourceContext` class have helpers to - `getBytes(key: string): Bytes` - `getBoolean(key: string): boolean` - `getBigDecimal(key: string): BigDecimal` + +### Common AssemblyScript Issues + +There are certain [AssemblyScript](https://github.com/AssemblyScript/assemblyscript) issues that are common to run into during subgraph development. They range in debug difficulty, however, being aware of them may help. The following is a non-exhaustive list of these issues: + +- `Private` class variables are not enforced in [AssembyScript](https://www.assemblyscript.org/status.html#language-features). There is no way to protect class variables from being directly changed from the class object. +- Scope is not inherited into [closure functions](https://www.assemblyscript.org/status.html#on-closures), i.e. variables declared outside of closure functions cannot be used. Explanation in [Developer Highlights #3](https://www.youtube.com/watch?v=1-8AW-lVfrA&t=3243s). diff --git a/website/pages/ar/developing/creating-a-subgraph.mdx b/website/pages/ar/developing/creating-a-subgraph.mdx index e90990f11fdb..02b7670e6bb4 100644 --- a/website/pages/ar/developing/creating-a-subgraph.mdx +++ b/website/pages/ar/developing/creating-a-subgraph.mdx @@ -1,57 +1,46 @@ --- -title: إنشاء الـ Subgraph +title: إنشاء رسم بياني فرعي --- -قبل التمكن من استخدام Graph CLI ، يلزمك إنشاء الـ subgraph الخاص بك في [ Subgraph Studio ](https://thegraph.com/studio). ستتمكن بعد ذلك من إعداد مشروع الـ subgraph الخاص بك ونشره على المنصة الي تختارها. لاحظ أنه **أنه لن يتم نشر الـ subgraphs التي لا تقوم بفهرسة Ethereum mainnet على شبكة The Graph**. - -يمكن استخدام الأمر `graph init` لإعداد مشروع subgraph جديد ، إما من عقد موجود على أي من شبكات Ethereum العامة ، أو من مثال subgraph. يمكن استخدام هذا الأمر لإنشاء subgraph في Subgraph Studio عن طريق تمرير `graph init --product subgraph-studio`. إذا كان لديك بالفعل عقد ذكي تم نشره على شبكة Ethereum mainnet أو إحدى شبكات testnets ، فإن تمهيد subgraph جديد من هذا العقد يمكن أن يكون طريقة جيدة للبدء. لكن أولا ، لنتحدث قليلا عن الشبكات التي يدعمها The Graph. - -## الشبكات المدعومة - -تدعم شبكة Graph الـ subgraphs لفهرسة mainnet Ethereum: - -- `mainnet` - -**يتم دعم الشبكات الإضافية في الإصدار beta على Hosted Service**: - -- `mainnet` -- `rinkeby` -- `goerli` -- `poa-core` -- `poa-sokol` -- `gnosis` -- `near-mainnet` -- `near-testnet` -- `matic` -- `mumbai` -- `fantom` -- `bnb` -- `chapel` -- `clover` -- `avalanche` -- `fuji` -- `celo` -- `celo-alfajores` -- `fuse` -- `moonriver` -- `mbase` -- `arbitrum-one` -- `arbitrum-rinkeby` -- `arbitrum-goerli` -- `optimism` -- `optimism-goerli` -- `aurora` -- `aurora-testnet` -- `harmony` -- `zkSync2-testnet` - -يعتمد Graph's Hosted Service على استقرار وموثوقية التقنيات الأساسية ، وهي نقاط JSON RPC endpoints. المتوفرة. سيتم تمييز الشبكات الأحدث على أنها في مرحلة beta حتى تثبت الشبكة نفسها من حيث الاستقرار والموثوقية وقابلية التوسع. خلال فترة beta ، هناك خطر حدوث عطل وسلوك غير متوقع. - -تذكر أنك ** لن تكون قادرا** على نشر subgraph يقوم بفهرسة شبكة non-mainnet لـ شبكة Graph اللامركزية في [Subgraph Studio](/deploying/subgraph-studio). +A subgraph extracts data from a blockchain, processing it and storing it so that it can be easily queried via GraphQL. + +![Defining a Subgraph](/img/defining-a-subgraph.png) + +يتكون تعريف الفرعيةرسم بياني من عدة ملفات: + +- `Subgraph.yaml` ملف YAML يحتوي على الفرعيةرسم بياني يظهر + +- `schema.graphql`: مخطط GraphQL يحدد البيانات المخزنة في الفرعيةرسم بياني وكيفية الاستعلام عنها عبر GraphQL + +- `AssemblyScript Mappings`: [AssemblyScript](https://github.com/AssemblyScript/assemblyscript) كود يترجم من بيانات الحدث إلى الكيانات المعرفة في مخططك (مثل`mapping.ts` في هذا الدرس) + +> In order to use your subgraph on The Graph's decentralized network, you will need to [create an API key](/deploying/subgraph-studio-faqs/#2-how-do-i-create-an-api-key). It is recommended that you [add signal](/network/curating/#how-to-signal) to your subgraph with at least [10,000 GRT](/network-transition-faq/#how-can-i-ensure-that-my-subgraph-will-be-picked-up-by-indexer-on-the-graph-network). + +قبل الخوض في التفاصيل حول محتويات ملف يظهر ، تحتاج إلى تثبيت [Graph CLI](https://github.com/graphprotocol/graph-cli) والذي سوف تحتاجه لبناء ونشر الفرعيةرسم بياني. + +## قم بتثبيت Graph CLI + +تمت كتابة Graph CLI بلغة جافا سكريبت ، وستحتاج إلى تثبيت إما `yarn` أو `npm` لاستخدامها ؛ ومن المفترض أن يكون لديك yarn كالتالي. + +بمجرد حصولك على `yarn` ، قم بتثبيت Graph CLI عن طريق تشغيل + +**التثبيت بواسطة yarn:** + +```bash +yarn global add @graphprotocol/graph-cli +``` + +**التثبيت بواسطة npm:** + +```bash +npm install -g @graphprotocol/graph-cli +``` + +Once installed, the `graph init` command can be used to set up a new subgraph project, either from an existing contract or from an example subgraph. This command can be used to create a subgraph on the Subgraph Studio by passing in `graph init --product subgraph-studio`. If you already have a smart contract deployed to your preferred network, bootstrapping a new subgraph from that contract can be a good way to get started. ## من عقد موجود -الأمر التالي ينشئ subgraph يفهرس كل الأحداث للعقد الموجود. إنه يحاول جلب ABI للعقد من Etherscan ويعود إلى طلب مسار ملف محلي. إذا كانت أي من arguments الاختيارية مفقودة ، فسيأخذك عبر نموذج تفاعلي. +الأمر التالي ينشئ الفرعيةرسم بياني يفهرس كل الأحداث للعقد الموجود. إنه يحاول جلب ABI للعقد من Etherscan ويعود إلى طلب مسار ملف محلي. إذا كانت أي من الحجج الاختيارية مفقودة ، فسيأخذك عبر نموذج تفاعلي. ```sh graph init \ @@ -62,28 +51,54 @@ graph init \ [] ``` -`` هو ID لـ subgraph الخاص بك في Subgraph Studio ، ويمكن العثور عليه في صفحة تفاصيل الـ subgraph. +`` هو ID لـ الفرعيةرسم بياني الخاص بك في الفرعيةرسم بياني استوديو ، ويمكن العثور عليه في صفحة تفاصيل الـ الفرعيةرسم بياني. -## من مثال Subgraph +## من مثال الفرعيةرسم بياني -الوضع الثاني `graph init` يدعم إنشاء مشروع جديد من مثال subgraph. الأمر التالي يقوم بهذا: +الوضع الثاني الذي يدعمه `graph init` هو إنشاء مشروع جديد من مثال subgraph. الأمر التالي يقوم بهذا: -``` +```sh graph init --studio ``` -يعتمد مثال الـ subgraph على عقد Gravity بواسطة Dani Grant الذي يدير avatars للمستخدم ويصدر أحداث `NewGravatar` أو `UpdateGravatar` كلما تم إنشاء avatars أو تحديثها. يعالج الـ subgraph هذه الأحداث عن طريق كتابة كيانات `Gravatar` إلى مخزن Graph Node والتأكد من تحديثها وفقا للأحداث. ستنتقل الأقسام التالية إلى الملفات التي تشكل الـ subgraph manifest لهذا المثال. +يعتمد مثال الـ الفرعيةرسم بياني على عقد Gravity بواسطة Dani Grant الذي يدير avatars للمستخدم ويصدر أحداث `NewGravatar` أو `UpdateGravatar` كلما تم إنشاء avatars أو تحديثها. يعالج الـ الفرعيةرسم بياني هذه الأحداث عن طريق كتابة كيانات `Gravatar` إلى مخزن Graph Node والتأكد من تحديثها وفقا للأحداث. ستنتقل الأقسام التالية إلى الملفات التي تشكل الـ الفرعيةرسم بياني يظهر لهذا المثال. + +## Add New dataSources To An Existing Subgraph + +Since `v0.31.0` the `graph-cli` supports adding new dataSources to an existing subgraph through the `graph add` command. + +```sh +graph add
[] + +Options: + + --abi Path to the contract ABI (default: download from Etherscan) + --contract-name Name of the contract (default: Contract) + --merge-entities Whether to merge entities with the same name (default: false) + --network-file Networks config file path (default: "./networks.json") +``` + +The `add` command will fetch the ABI from Etherscan (unless an ABI path is specified with the `--abi` option), and will create a new `dataSource` in the same way that `graph init` command creates a `dataSource` `--from-contract`, updating the schema and mappings accordingly. + +The `--merge-entities` option identifies how the developer would like to handle `entity` and `event` name conflicts: + +- If `true`: the new `dataSource` should use existing `eventHandlers` & `entities`. +- If `false`: a new entity & event handler should be created with `${dataSourceName}{EventName}`. + +The contract `address` will be written to the `networks.json` for the relevant network. + +> **Note:** When using the interactive cli, after successfully running `graph init`, you'll be prompted to add a new `dataSource`. ## The Subgraph Manifest -Subgraph manifest `subgraph.yaml` تحدد العقود الذكية لفهارس الـ subgraph الخاص بك ، والأحداث من هذه العقود التي يجب الانتباه إليها ، وكيفية عمل map لبيانات الأحداث للكيانات التي تخزنها Graph Node وتسمح بالاستعلام عنها. يمكن العثور على المواصفات الكاملة لـ subgraph manifests [ هنا ](https://github.com/graphprotocol/graph-node/blob/master/docs/subgraph-manifest.md). +الفرعيةرسم بياني يظهر `subgraph.yaml` تحدد العقود الذكية لفهارس الـ الفرعيةرسم بياني الخاص بك ، والأحداث من هذه العقود التي يجب الانتباه إليها ، وكيفية عمل map لبيانات الأحداث للكيانات التي تخزنها Graph Node وتسمح بالاستعلام عنها. يمكن العثور على المواصفات الكاملة لـ الفرعيةرسم بياني يظهر [ هنا ](https://github.com/graphprotocol/graph-node/blob/master/docs/subgraph-manifest.md). -بالنسبة لمثال الـ subgraph ،يكون الـ `subgraph.yaml`: +بالنسبة لمثال الـ الفرعيةرسم بياني ،يكون الـ `subgraph.yaml`: ```yaml specVersion: 0.0.4 description: Gravatar for Ethereum -repository: https://github.com/graphprotocol/example-subgraph +repository: https://github.com/graphprotocol/example-subgraphs schema: file: ./schema.graphql dataSources: @@ -119,34 +134,34 @@ dataSources: file: ./src/mapping.ts ``` -الإدخالات الهامة لتحديث manifest هي: +الإدخالات الهامة لتحديث يظهر هي: -- `description`: وصف يمكن قراءته لماهية الـ subgraph. يتم عرض هذا الوصف بواسطة Graph Explorer عند نشر الـ subgraph على الـ Hosted Service. +- `description`: وصف يمكن قراءته لماهية الـ الفرعيةرسم بياني. يتم عرض هذا الوصف بواسطة مستكشف الرسم البياني عند نشر الـ الفرعيةرسم بياني على الـ خدمة مستضافة. -- `repository`: عنوان URL للمخزن حيث يمكن العثور على subgraph manifest. يتم أيضا عرض هذا بواسطة Graph Explorer. +- `repository`: the URL of the repository where the subgraph manifest can be found. This is also displayed by The Graph Explorer. - `features`: قائمة بجميع أسماء الـ [ الميزات](#experimental-features) المستخدمة. -- `dataSources.source`: عنوان العقد الذكي الصادر من الـ subgraph ، و Abi العقد الذكي الذي سيستخدم. حيث أن العنوان اختياري ، وبحذفه يسمح بفهرسة الأحداث المطابقة من جميع العقود. +- `dataSources.source`: the address of the smart contract the subgraph sources, and the ABI of the smart contract to use. The address is optional; omitting it allows to index matching events from all contracts. -- `dataSources.source.startBlock`: الرقم الاختياري للكتلة والتي يبدأ مصدر البيانات بالفهرسة منها. في معظم الحالات نقترح استخدام الكتلة التي تم إنشاء العقد من خلالها. +- `dataSources.source.startBlock`: the optional number of the block that the data source starts indexing from. In most cases, we suggest using the block in which the contract was created. -- `dataSources.mapping.entities`: الكيانات التي يكتبها مصدر البيانات للمخزن. ويتم تحديد مخطط كل كيان في ملف schema.graphql. +- `dataSources.mapping.entities`: the entities that the data source writes to the store. The schema for each entity is defined in the schema.graphql file. - `dataSources.mapping.abis`: ملف ABI واحد أو أكثر لعقد المصدر بالإضافة إلى العقود الذكية الأخرى والتي تتفاعل معها من داخل الـ mappings. - `dataSources.mapping.eventHandlers`: يضع قائمة بأحداث العقود الذكية والتي يتفاعل معها هذا الـ subgraph ويعالجها في (mapping) الـتخطيط —./src/mapping.ts في المثال - والتي تحول هذه الأحداث إلى كيانات في المخزن. -- `dataSources.mapping.callHandlers`: يضع قائمة بدوال العقود الذكية والتي يتفاعل معها هذا الـ subgraph ويعالجها في الـ mapping التي تحول المدخلات والمخرجات لاستدعاءات الدوال إلى كيانات في المخزن. +- `dataSources.mapping.callHandlers`: يضع قائمة بدوال العقود الذكية والتي يتفاعل معها هذا الـ الفرعيةرسم بياني ويعالجها في الـ mapping التي تحول المدخلات والمخرجات لاستدعاءات الدوال إلى كيانات في المخزن. -- `dataSources.mapping.blockHandlers`: يضع قائمة بـالكتل (blocks) التي يتفاعل معها هذا الـ subgraph ويعالجها في الـ mapping لتشغيلها عند إلحاق كتلة بالسلسلة. وبدون فلتر، سيتم تشغيل معالج الكتلة في كل كتلة. ويمكن توفير فلتر اختياري مع الأنواع التالية:call. سيقوم فلتر `call بتشغيل المعالج إذا كانت الكتلة تحتوي على استدعاء واحد على الأقل لعقد مصدر البيانات. +- `dataSources.mapping.blockHandlers`: lists the blocks this subgraph reacts to and handlers in the mapping to run when a block is appended to the chain. Without a filter, the block handler will be run every block. An optional call-filter can be provided by adding a `filter` field with `kind: call` to the handler. This will only run the handler if the block contains at least one call to the data source contract. -يمكن لـ subgraph واحد فهرسة البيانات من عقود ذكية متعددة. أضف إدخالا لكل عقد يجب فهرسة البيانات منه إلى مصفوفة `dataSources`. +يمكن لـ الفرعيةرسم بياني واحد فهرسة البيانات من عقود ذكية متعددة. أضف إدخالا لكل عقد يجب فهرسة البيانات منه إلى مصفوفة `dataSources`. يتم ترتيب المشغلات (triggers) لمصدر البيانات داخل الكتلة باستخدام العملية التالية: 1. يتم ترتيب triggers الأحداث والاستدعاءات أولا من خلال فهرس الإجراء داخل الكتلة. -2. يتم ترتيب triggers الحدث والاستدعاء في نفس الإجراء باستخدام العبارة: يتم تفعيل مشغلات الحدث أولا ثم مشغلات الاستدعاء (event triggers first then call triggers) ، ويحترم كل نوع الترتيب المحدد في الـ manifest. +2. Event and call triggers within the same transaction are ordered using a convention: event triggers first then call triggers, each type respecting the order they are defined in the manifest. 3. يتم تشغيل مشغلات الكتلة بعد مشغلات الحدث والاستدعاء، بالترتيب المحدد في الـ manifest. قواعد الترتيب هذه عرضة للتغيير. @@ -156,16 +171,16 @@ dataSources: يجب أن تتطابق ملف (ملفات) ABI مع العقد (العقود) الخاصة بك. هناك عدة طرق للحصول على ملفات ABI: - إذا كنت تقوم ببناء مشروعك الخاص ، فمن المحتمل أن تتمكن من الوصول إلى أحدث ABIs. -- إذا كنت تقوم ببناء subgraph لمشروع عام ، فيمكنك تنزيل هذا المشروع على جهاز الكمبيوتر الخاص بك والحصول على ABI باستخدام [ `truffle compile` ](https://truffleframework.com/docs/truffle/overview) أو استخدام solc للترجمة. +- إذا كنت تقوم ببناء الفرعيةرسم بياني لمشروع عام ، فيمكنك تنزيل هذا المشروع على جهاز الكمبيوتر الخاص بك والحصول على ABI باستخدام [ `truffle compile` ](https://truffleframework.com/docs/truffle/overview) أو استخدام solc للترجمة. - يمكنك أيضا العثور على ABI على [ Etherscan ](https://etherscan.io/) ، ولكن هذا ليس موثوقا به دائما ، حيث قد يكون ABI الذي تم تحميله هناك قديما. تأكد من أن لديك ABI الصحيح ، وإلا فإن تشغيل الـ subgraph الخاص بك سيفشل. ## مخطط GraphQL -مخطط الـ subgraph الخاص بك موجود في الملف `schema.graphql`. يتم تعريف مخططات GraphQL باستخدام لغة تعريف واجهة GraphQL. إذا لم تقم مطلقا بكتابة مخطط GraphQL ، فمن المستحسن أن تقوم بقراءة هذا التمهيد على نظام نوع GraphQL. يمكن العثور على الوثائق المرجعية لمخططات GraphQL في قسم [ GraphQL API ](/querying/graphql-api). +The schema for your subgraph is in the file `schema.graphql`. GraphQL schemas are defined using the GraphQL interface definition language. If you've never written a GraphQL schema, it is recommended that you check out this primer on the GraphQL type system. Reference documentation for GraphQL schemas can be found in the [GraphQL API](/querying/graphql-api) section. -## تعريف الكيانات (Entities) +## تعريف الكيانات -قبل تعريف الكيانات ، من المهم التراجع والتفكير في كيفية هيكلة بياناتك وربطها. سيتم إجراء جميع الاستعلامات لنموذج البيانات المعرفة في مخطط الـ subgraph والكيانات المفهرسة بواسطة الـ subgraph. لهذا السبب ، من الجيد تعريف مخطط الـ subgraph بطريقة تتوافق مع احتياجات الـ dapp الخاص بك. قد يكون من المفيد تصور الكيانات على أنها "كائنات (objects) تحتوي على بيانات" ، وليس أحداثا أو دوال. +قبل تعريف الكيانات ، من المهم التراجع والتفكير في كيفية هيكلة بياناتك وربطها. سيتم إجراء جميع الاستعلامات لنموذج البيانات المعرفة في مخطط الـ الفرعيةرسم بياني والكيانات المفهرسة بواسطة الـ الفرعيةرسم بياني. لهذا السبب ، من الجيد تعريف مخطط الـ الفرعيةرسم بياني بطريقة تتوافق مع احتياجات الـ dapp الخاص بك. قد يكون من المفيد تصور الكيانات على أنها "كائنات تحتوي على بيانات" ، وليس أحداثا أو دوال. With The Graph, you simply define entity types in `schema.graphql`, and Graph Node will generate top level fields for querying single instances and collections of that entity type. Each type that should be an entity is required to be annotated with an `@entity` directive. By default, entities are mutable, meaning that mappings can load existing entities, modify them and store a new version of that entity. Mutability comes at a price, and for entity types for which it is known that they will never be modified, for example, because they simply contain data extracted verbatim from the chain, it is recommended to mark them as immutable with `@entity(immutable: true)`. Mappings can make changes to immutable entities as long as those changes happen in the same block in which the entity was created. Immutable entities are much faster to write and to query, and should therefore be used whenever possible. @@ -215,7 +230,7 @@ Each entity must have an `id` field, which must be of type `Bytes!` or `String!` For some entity types the `id` is constructed from the id's of two other entities; that is possible using `concat`, e.g., `let id = left.id.concat(right.id)` to form the id from the id's of `left` and `right`. Similarly, to construct an id from the id of an existing entity and a counter `count`, `let id = left.id.concatI32(count)` can be used. The concatenation is guaranteed to produce unique id's as long as the length of `left` is the same for all such entities, for example, because `left.id` is an `Address`. -### أنواع المقاييس المضمنة (Scalar Types) +### أنواع المقاييس المضمنة #### المقاييس المدعومة من GraphQL @@ -223,12 +238,12 @@ We support the following scalars in our GraphQL API: | النوع | الوصف | | --- | --- | -| `Bytes` | مصفوفة Byte ، ممثلة كسلسلة سداسية عشرية. يشيع استخدامها في Ethereum hashes وعناوينه. | +| `Bytes` | مصفوفة Byte ، ممثلة كسلسلة سداسية عشرية. يشيع استخدامها في إيثيريوم hashes وعناوينه. | | `String` | Scalar for `string` values. Null characters are not supported and are automatically removed. | | `Boolean` | Scalar for `boolean` values. | -| `Int` | The GraphQL spec defines `Int` to have size of 32 bytes. | +| `Int` | The GraphQL spec defines `Int` to have a size of 32 bytes. | | `BigInt` | Large integers. Used for Ethereum's `uint32`, `int64`, `uint64`, ..., `uint256` types. Note: Everything below `uint32`, such as `int32`, `uint24` or `int8` is represented as `i32`. | -| `BigDecimal` | `BigDecimal` High precision decimals represented as a signficand and an exponent. The exponent range is from −6143 to +6144. Rounded to 34 significant digits. | +| `BigDecimal` | `BigDecimal` High precision decimals represented as a significand and an exponent. The exponent range is from −6143 to +6144. Rounded to 34 significant digits. | #### Enums @@ -246,7 +261,7 @@ Once the enum is defined in the schema, you can use the string representation of More detail on writing enums can be found in the [GraphQL documentation](https://graphql.org/learn/schema/). -#### علاقات الكيانات (Entity) +#### علاقات الكيانات An entity may have a relationship to one or more other entities in your schema. These relationships may be traversed in your queries. Relationships in The Graph are unidirectional. It is possible to simulate bidirectional relationships by defining a unidirectional relationship on either "end" of the relationship. @@ -284,7 +299,7 @@ type TokenBalance @entity { } ``` -#### البحث العكسي (Reverse Lookups) +#### البحث العكسي Reverse lookups can be defined on an entity through the `@derivedFrom` field. This creates a virtual field on the entity that may be queried but cannot be set manually through the mappings API. Rather, it is derived from the relationship defined on the other entity. For such relationships, it rarely makes sense to store both sides of the relationship, and both indexing and query performance will be better when only one side is stored and the other is derived. @@ -382,7 +397,7 @@ type MyFirstEntity @entity { ## تعريف حقول البحث عن النص الكامل -Fulltext search queries filter and rank entities based on a text search input. Fulltext queries are able to return matches for similar words by processing the query text input into stems before comparing to the indexed text data. +Fulltext search queries filter and rank entities based on a text search input. Fulltext queries are able to return matches for similar words by processing the query text input into stems before comparing them to the indexed text data. A fulltext query definition includes the query name, the language dictionary used to process the text fields, the ranking algorithm used to order the results, and the fields included in the search. Each fulltext query may span multiple fields, but all included fields must be from a single entity type. @@ -409,7 +424,7 @@ type Band @entity { } ``` -The example `bandSearch` field can be used in queries to filter `Band` entities based on the text documents in the `name`, `description`, and `bio` fields. Jump to [GraphQL API - Queries](/querying/graphql-api#queries) for a description of the Fulltext search API and for more example usage. +The example `bandSearch` field can be used in queries to filter `Band` entities based on the text documents in the `name`, `description`, and `bio` fields. Jump to [GraphQL API - Queries](/querying/graphql-api#queries) for a description of the fulltext search API and more example usage. ```graphql query { @@ -426,28 +441,28 @@ query { ### اللغات المدعومة -Choosing a different language will have a definitive, though sometimes subtle, effect on the fulltext search API. Fields covered by a fulltext query field are examined in the context of the chosen language, so the lexemes produced by analysis and search queries vary language to language. For example: when using the supported Turkish dictionary "token" is stemmed to "toke" while, of course, the English dictionary will stem it to "token". +Choosing a different language will have a definitive, though sometimes subtle, effect on the fulltext search API. Fields covered by a fulltext query field are examined in the context of the chosen language, so the lexemes produced by analysis and search queries vary from language to language. For example: when using the supported Turkish dictionary "token" is stemmed to "toke" while, of course, the English dictionary will stem it to "token". Supported language dictionaries: -| الرمز | القاموس | -| ------ | ------- | -| simple | عام | -| da | دنماركي | -| nl | هولندي | -| en | إنجليزي | -| fi | فنلندي | -| fr | فرنسي | -| de | ألماني | -| hu | مجري | -| it | إيطالي | -| no | نرويجي | -| pt | برتغالي | -| ro | روماني | -| ru | روسي | -| es | إسباني | -| sv | سويدي | -| tr | تركي | +| الرمز | القاموس | +| ------ | ---------- | +| simple | عام | +| da | دنماركي | +| nl | هولندي | +| en | إنجليزي | +| fi | فنلندي | +| fr | فرنسي | +| de | ألماني | +| hu | مجري | +| it | إيطالي | +| no | نرويجي | +| pt | Portuguese | +| ro | روماني | +| ru | روسي | +| es | إسباني | +| sv | سويدي | +| tr | تركي | ### خوارزميات التصنيف @@ -460,7 +475,7 @@ Supported algorithms for ordering results: ## كتابة الـ Mappings -The mappings transform the Ethereum data your mappings are sourcing into entities defined in your schema. Mappings are written in a subset of [TypeScript](https://www.typescriptlang.org/docs/handbook/typescript-in-5-minutes.html) called [AssemblyScript](https://github.com/AssemblyScript/assemblyscript/wiki) which can be compiled to WASM ([WebAssembly](https://webassembly.org/)). AssemblyScript is stricter than normal TypeScript, yet provides a familiar syntax. +The mappings take data from a particular source and transform it into entities that are defined within your schema. Mappings are written in a subset of [TypeScript](https://www.typescriptlang.org/docs/handbook/typescript-in-5-minutes.html) called [AssemblyScript](https://github.com/AssemblyScript/assemblyscript/wiki) which can be compiled to WASM ([WebAssembly](https://webassembly.org/)). AssemblyScript is stricter than normal TypeScript, yet provides a familiar syntax. For each event handler that is defined in `subgraph.yaml` under `mapping.eventHandlers`, create an exported function of the same name. Each handler must accept a single parameter called `event` with a type corresponding to the name of the event which is being handled. @@ -493,7 +508,7 @@ export function handleUpdatedGravatar(event: UpdatedGravatar): void { The first handler takes a `NewGravatar` event and creates a new `Gravatar` entity with `new Gravatar(event.params.id.toHex())`, populating the entity fields using the corresponding event parameters. This entity instance is represented by the variable `gravatar`, with an id value of `event.params.id.toHex()`. -The second handler tries to load the existing `Gravatar` from the Graph Node store. If it does not exist yet, it is created on demand. The entity is then updated to match the new event parameters, before it is saved back to the store using `gravatar.save()`. +The second handler tries to load the existing `Gravatar` from the Graph Node store. If it does not exist yet, it is created on-demand. The entity is then updated to match the new event parameters before it is saved back to the store using `gravatar.save()`. ### الـ IDs الموصى بها لإنشاء كيانات جديدة @@ -505,7 +520,7 @@ Every entity has to have an `id` that is unique among all entities of the same t We provide the [Graph Typescript Library](https://github.com/graphprotocol/graph-ts) which contains utilies for interacting with the Graph Node store and conveniences for handling smart contract data and entities. You can use this library in your mappings by importing `@graphprotocol/graph-ts` in `mapping.ts`. -## توليد الكود(Code Generation) +## توليد الكود In order to make it easy and type-safe to work with smart contracts, events and entities, the Graph CLI can generate AssemblyScript types from the subgraph's GraphQL schema and the contract ABIs included in the data sources. @@ -525,7 +540,7 @@ yarn codegen npm run codegen ``` -This will generate an AssemblyScript class for every smart contract in the ABI files mentioned in `subgraph.yaml`, allowing you to bind these contracts to specific addresses in the mappings and call read-only contract methods against the block being processed. It will also generate a class for every contract event to provide easy access to event parameters as well as the block and transaction the event originated from. All of these types are written to `//.ts`. In the example subgraph, this would be `generated/Gravity/Gravity.ts`, allowing mappings to import these types with +This will generate an AssemblyScript class for every smart contract in the ABI files mentioned in `subgraph.yaml`, allowing you to bind these contracts to specific addresses in the mappings and call read-only contract methods against the block being processed. It will also generate a class for every contract event to provide easy access to event parameters, as well as the block and transaction the event originated from. All of these types are written to `//.ts`. In the example subgraph, this would be `generated/Gravity/Gravity.ts`, allowing mappings to import these types with. ```javascript import { @@ -543,17 +558,19 @@ In addition to this, one class is generated for each entity type in the subgraph 'import { Gravatar } from '../generated/schema ``` -> **Note:** يجب إجراء إنشاء الكود مرة أخرى بعد كل تغيير في مخطط GraphQL أو ABI المضمنة في الـ manifest. يجب أيضا إجراؤه مرة واحدة على الأقل قبل بناء أو نشر الـ subgraph. +> **ملحوظات:** يجب إجراء إنشاء الكود مرة أخرى بعد كل تغيير في مخطط GraphQL أو ABI المضمنة في الـ يظهر. يجب أيضا إجراؤه مرة واحدة على الأقل قبل بناء أو نشر الـ الفرعيةرسم بياني. Code generation does not check your mapping code in `src/mapping.ts`. If you want to check that before trying to deploy your subgraph to the Graph Explorer, you can run `yarn build` and fix any syntax errors that the TypeScript compiler might find. -## قوالب مصدر البيانات(data source templates) +## قوالب مصدر البيانات -A common pattern in Ethereum smart contracts is the use of registry or factory contracts, where one contract creates, manages or references an arbitrary number of other contracts that each have their own state and events. The addresses of these sub-contracts may or may not be known upfront and many of these contracts may be created and/or added over time. This is why, in such cases, defining a single data source or a fixed number of data sources is impossible and a more dynamic approach is needed: _data source templates_. +A common pattern in EVM-compatible smart contracts is the use of registry or factory contracts, where one contract creates, manages, or references an arbitrary number of other contracts that each have their own state and events. + +The addresses of these sub-contracts may or may not be known upfront and many of these contracts may be created and/or added over time. This is why, in such cases, defining a single data source or a fixed number of data sources is impossible and a more dynamic approach is needed: _data source templates_. ### مصدر البيانات للعقد الرئيسي -First, you define a regular data source for the main contract. The snippet below shows a simplified example data source for the [Uniswap](https://uniswap.io) exchange factory contract. Note the `NewExchange(address,address)` event handler. This is emitted when a new exchange contract is created on chain by the factory contract. +First, you define a regular data source for the main contract. The snippet below shows a simplified example data source for the [Uniswap](https://uniswap.org) exchange factory contract. Note the `NewExchange(address,address)` event handler. This is emitted when a new exchange contract is created on-chain by the factory contract. ```yaml dataSources: @@ -580,7 +597,7 @@ dataSources: ### قوالب مصدر البيانات للعقود التي تم إنشاؤها ديناميكيا -Then, you add _data source templates_ to the manifest. These are identical to regular data sources, except that they lack a predefined contract address under `source`. Typically, you would define one template for each type of sub-contract managed or referenced by the parent contract. +Then, you add _data source templates_ to the manifest. These are identical to regular data sources, except that they lack a pre-defined contract address under `source`. Typically, you would define one template for each type of sub-contract managed or referenced by the parent contract. ```yaml dataSources: @@ -632,7 +649,7 @@ export function handleNewExchange(event: NewExchange): void { > > إذا كانت الكتل السابقة تحتوي على بيانات ذات صلة بمصدر البيانات الجديد ، فمن الأفضل فهرسة تلك البيانات من خلال قراءة الحالة الحالية للعقد وإنشاء كيانات تمثل تلك الحالة في وقت إنشاء مصدر البيانات الجديد. -### سياق (Context) مصدر البيانات +### سياق مصدر البيانات Data source contexts allow passing extra configuration when instantiating a template. In our example, let's say exchanges are associated with a particular trading pair, which is included in the `NewExchange` event. That information can be passed into the instantiated data source, like so: @@ -657,7 +674,7 @@ let tradingPair = context.getString('tradingPair') There are setters and getters like `setString` and `getString` for all value types. -## كتل البدء (Start Blocks) +## كتل البدء The `startBlock` is an optional setting that allows you to define from which block in the chain the data source will start indexing. Setting the start block allows the data source to skip potentially millions of blocks that are irrelevant. Typically, a subgraph developer will set `startBlock` to the block in which the smart contract of the data source was created. @@ -697,11 +714,11 @@ While events provide an effective way to collect relevant changes to the state o Call handlers will only trigger in one of two cases: when the function specified is called by an account other than the contract itself or when it is marked as external in Solidity and called as part of another function in the same contract. -> **ملاحظة:** معالجات الاستدعاء غير مدعومة في Rinkeby أو Goerli أو Ganache. تعتمد معالجات الاستدعاء حاليا على Parity tracing API و هذه الشبكات لا تدعمها. +> **Note:** Call handlers currently depend on the Parity tracing API. Certain networks, such as BNB chain and Arbitrum, does not support this API. If a subgraph indexing one of these networks contain one or more call handlers, it will not start syncing. Subgraph developers should instead use event handlers. These are far more performant than call handlers, and are supported on every evm network. ### تعريف معالج الاستدعاء -To define a call handler in your manifest simply add a `callHandlers` array under the data source you would like to subscribe to. +To define a call handler in your manifest, simply add a `callHandlers` array under the data source you would like to subscribe to. ```yaml dataSources: @@ -747,9 +764,9 @@ export function handleCreateGravatar(call: CreateGravatarCall): void { The `handleCreateGravatar` function takes a new `CreateGravatarCall` which is a subclass of `ethereum.Call`, provided by `@graphprotocol/graph-ts`, that includes the typed inputs and outputs of the call. The `CreateGravatarCall` type is generated for you when you run `graph codegen`. -## معالجات الكتلة (Block Handlers) +## معالجات الكتلة -In addition to subscribing to contract events or function calls, a subgraph may want to update its data as new blocks are appended to the chain. To achieve this a subgraph can run a function after every block or after blocks that match a predefined filter. +In addition to subscribing to contract events or function calls, a subgraph may want to update its data as new blocks are appended to the chain. To achieve this a subgraph can run a function after every block or after blocks that match a pre-defined filter. ### الفلاتر المدعومة @@ -760,7 +777,9 @@ filter: _The defined handler will be called once for every block which contains a call to the contract (data source) the handler is defined under._ -The absense of a filter for a block handler will ensure that the handler is called every block. A data source can only contain one block handler for each filter type. +> **Note:** The `call` filter currently depend on the Parity tracing API. Certain networks, such as BNB chain and Arbitrum, does not support this API. If a subgraph indexing one of these networks contain one or more block handlers with a `call` filter, it will not start syncing. + +The absence of a filter for a block handler will ensure that the handler is called every block. A data source can only contain one block handler for each filter type. ```yaml dataSources: @@ -801,29 +820,44 @@ export function handleBlock(block: ethereum.Block): void { } ``` -## أحداث الـ Anonymous +## أحداث الـ مجهول If you need to process anonymous events in Solidity, that can be achieved by providing the topic 0 of the event, as in the example: ```yaml eventHandlers: - event: LogNote(bytes4,address,bytes32,bytes32,uint256,bytes) - topic0: '0xbaa8529c00000000000000000000000000000000000000000000000000000000' + topic0: '0x644843f351d3fba4abcd60109eaff9f54bac8fb8ccf0bab941009c21df21cf31' handler: handleGive ``` An event will only be triggered when both the signature and topic 0 match. By default, `topic0` is equal to the hash of the event signature. -## الميزات التجريبية +## Transaction Receipts in Event Handlers + +Starting from `specVersion` `0.0.5` and `apiVersion` `0.0.7`, event handlers can have access to the receipt for the transaction which emitted them. + +To do so, event handlers must be declared in the subgraph manifest with the new `receipt: true` key, which is optional and defaults to false. + +```yaml +eventHandlers: + - event: NewGravatar(uint256,address,string,string) + handler: handleNewGravatar + receipt: true +``` + +Inside the handler function, the receipt can be accessed in the `Event.receipt` field. When the `receipt` key is set to `false` or omitted in the manifest, a `null` value will be returned instead. + +## Experimental features Starting from `specVersion` `0.0.4`, subgraph features must be explicitly declared in the `features` section at the top level of the manifest file, using their `camelCase` name, as listed in the table below: -| الميزة | الاسم | -| ----------------------------------------------------- | ------------------------- | -| [أخطاء غير فادحة](#non-fatal-errors) | `nonFatalErrors` | -| [البحث عن نص كامل](#defining-fulltext-search-fields) | `fullTextSearch` | -| [تطعيم(Grafting)](#grafting-onto-existing-subgraphs) | `grafting` | -| [IPFS على عقود Ethereum](#ipfs-on-ethereum-contracts) | `ipfsOnEthereumContracts` | +| الميزة | الاسم | +| ----------------------------------------------------- | --------------------------------------------------- | +| [أخطاء غير فادحة](#non-fatal-errors) | `nonFatalErrors` | +| [البحث عن نص كامل](#defining-fulltext-search-fields) | `fullTextSearch` | +| [تطعيم](#grafting-onto-existing-subgraphs) | `grafting` | +| [IPFS على عقود إيثيريوم](#ipfs-on-ethereum-contracts) | `ipfsOnEthereumContracts` or `nonDeterministicIpfs` | For instance, if a subgraph uses the **Full-Text Search** and the **Non-fatal Errors** features, the `features` field in the manifest should be: @@ -836,27 +870,25 @@ features: dataSources: ... ``` -Note that using a feature without declaring it will incur in a **validation error** during subgraph deployment, but no errors will occur if a feature is declared but not used. - -### IPFS على عقود Ethereum +Note that using a feature without declaring it will incur a **validation error** during subgraph deployment, but no errors will occur if a feature is declared but not used. -A common use case for combining IPFS with Ethereum is to store data on IPFS that would be too expensive to maintain on chain, and reference the IPFS hash in Ethereum contracts. +### IPFS على عقود إيثيريوم -Given such IPFS hashes, subgraphs can read the corresponding files from IPFS using `ipfs.cat` and `ipfs.map`. To do this reliably, however, it is required that these files are pinned on the IPFS node that the Graph Node indexing the subgraph connects to. In the case of the [hosted service](https://thegraph.com/hosted-service), this is [https://api.thegraph.com/ipfs/](https://api.thegraph.com/ipfs/). +A common use case for combining IPFS with Ethereum is to store data on IPFS that would be too expensive to maintain on-chain, and reference the IPFS hash in Ethereum contracts. -> **ملاحظة:** لا تدعم شبكة Graph حتى الآن `ipfs.cat` و `ipfs.map` ، ويجب على المطورين عدم النشر الـ subgraphs للشبكة باستخدام تلك الدالة عبر الـ Studio. +Given such IPFS hashes, subgraphs can read the corresponding files from IPFS using `ipfs.cat` and `ipfs.map`. To do this reliably, it is required that these files are pinned to an IPFS node with high availability, so that the [hosted service](https://thegraph.com/hosted-service) IPFS node can find them during indexing. -In order to make this easy for subgraph developers, The Graph team wrote a tool for transfering files from one IPFS node to another, called [ipfs-sync](https://github.com/graphprotocol/ipfs-sync). +> **ملاحظة:** لا تدعم شبكة رسم بياني حتى الآن `ipfs.cat` و `ipfs.map` ، ويجب على المطورين عدم النشر الـ الفرعيةرسم بياني للشبكة باستخدام تلك الدالة عبر الـ استوديو. -> **[إدارة الميزات](#experimental-features):** يجب الإعلان عن `ipfsOnEthereumContracts` ضمن `features` في subgraph manifest. +> **[Feature Management](#experimental-features):** `ipfsOnEthereumContracts` must be declared under `features` in the subgraph manifest. For non EVM chains, the `nonDeterministicIpfs` alias can also be used for the same purpose. When running a local Graph Node, the `GRAPH_ALLOW_NON_DETERMINISTIC_IPFS` environment variable must be set in order to index subgraphs using this experimental functionality. ### أخطاء غير فادحة -Indexing errors on already synced subgraphs will, by default, cause the subgraph to fail and stop syncing. Subgraphs can alternatively be configured to continue syncing in the presence of errors, by ignoring the changes made by the handler which provoked the error. This gives subgraph authors time to correct their subgraphs while queries continue to be served against the latest block, though the results will possibly be inconsistent due to the bug that caused the error. Note that some errors are still always fatal, to be non-fatal the error must be known to be deterministic. +Indexing errors on already synced subgraphs will, by default, cause the subgraph to fail and stop syncing. Subgraphs can alternatively be configured to continue syncing in the presence of errors, by ignoring the changes made by the handler which provoked the error. This gives subgraph authors time to correct their subgraphs while queries continue to be served against the latest block, though the results might be inconsistent due to the bug that caused the error. Note that some errors are still always fatal. To be non-fatal, the error must be known to be deterministic. -> **ملاحظة:** لا تدعم شبكة Graph حتى الآن الأخطاء غير الفادحة ، ويجب على المطورين عدم نشر الـ subgraphs على الشبكة باستخدام تلك الدالة عبر الـ Studio. +> **ملاحظة:** لا تدعم شبكة رسم بياني حتى الآن الأخطاء غير الفادحة ، ويجب على المطورين عدم نشر الـ الفرعيةرسم بياني على الشبكة باستخدام تلك الدالة عبر الـ استوديو. Enabling non-fatal errors requires setting the following feature flag on the subgraph manifest: @@ -880,7 +912,7 @@ _meta { } ``` -If the subgraph encounters an error that query will return both the data and a graphql error with the message `"indexing_error"`, as in this example response: +If the subgraph encounters an error, that query will return both the data and a graphql error with the message `"indexing_error"`, as in this example response: ```graphql "data": { @@ -900,11 +932,11 @@ If the subgraph encounters an error that query will return both the data and a g ] ``` -### Grafting على Subgraphs موجودة +### Grafting على الفرعيةرسم بياني موجودة -When a subgraph is first deployed, it starts indexing events at the genesis block of the corresponding chain (or at the `startBlock` defined with each data source) In some circumstances, it is beneficial to reuse the data from an existing subgraph and start indexing at a much later block. This mode of indexing is called _Grafting_. Grafting is, for example, useful during development to get past simple errors in the mappings quickly, or to temporarily get an existing subgraph working again after it has failed. +When a subgraph is first deployed, it starts indexing events at the genesis block of the corresponding chain (or at the `startBlock` defined with each data source) In some circumstances; it is beneficial to reuse the data from an existing subgraph and start indexing at a much later block. This mode of indexing is called _Grafting_. Grafting is, for example, useful during development to get past simple errors in the mappings quickly or to temporarily get an existing subgraph working again after it has failed. -A subgraph is grafted onto a base subgraph when the subgraph manifest in `subgraph.yaml` contains a `graft` block at the toplevel: +A subgraph is grafted onto a base subgraph when the subgraph manifest in `subgraph.yaml` contains a `graft` block at the top-level: ```yaml description: ... @@ -915,16 +947,232 @@ graft: When a subgraph whose manifest contains a `graft` block is deployed, Graph Node will copy the data of the `base` subgraph up to and including the given `block` and then continue indexing the new subgraph from that block on. The base subgraph must exist on the target Graph Node instance and must have indexed up to at least the given block. Because of this restriction, grafting should only be used during development or during an emergency to speed up producing an equivalent non-grafted subgraph. -Because grafting copies rather than indexes base data it is much quicker in getting the subgraph to the desired block than indexing from scratch, though the initial data copy can still take several hours for very large subgraphs. While the grafted subgraph is being initialized, the Graph Node will log information about the entity types that have already been copied. +Because grafting copies rather than indexes base data, it is much quicker to get the subgraph to the desired block than indexing from scratch, though the initial data copy can still take several hours for very large subgraphs. While the grafted subgraph is being initialized, the Graph Node will log information about the entity types that have already been copied. -The grafted subgraph can use a GraphQL schema that is not identical to the one of the base subgraph, but merely compatible with it. It has to be a valid subgraph schema in its own right but may deviate from the base subgraph's schema in the following ways: +The grafted subgraph can use a GraphQL schema that is not identical to the one of the base subgraph, but merely compatible with it. It has to be a valid subgraph schema in its own right, but may deviate from the base subgraph's schema in the following ways: - يضيف أو يزيل أنواع الكيانات - يزيل الصفات من أنواع الكيانات - يضيف صفات nullable لأنواع الكيانات - يحول صفات non-nullable إلى صفات nullable - يضيف قيما إلى enums -- يضيف أو يزيل الواجهات (interfaces) +- يضيف أو يزيل الواجهات - يغير للكيانات التي يتم تنفيذ الواجهة لها -> **[إدارة الميزات](#experimental-features):**يجب الإعلان عن `التطعيم` ضمن `features` في subgraph manifest. +> **[Feature Management](#experimental-features):** `grafting` must be declared under `features` in the subgraph manifest. + +## File Data Sources + +File data sources are a new subgraph functionality for accessing off-chain data during indexing in a robust, extendable way, starting with IPFS. + +> This also lays the groundwork for deterministic indexing of off-chain data, as well as the potential introduction of arbitrary HTTP-sourced data. + +### نظره عامة + +Rather than fetching files "in line" during handler exectuion, this introduces templates which can be spawned as new data sources for a given file identifier. These new data sources fetch the files, retrying if they are unsuccessful, running a dedicated handler when the file is found. + +This is similar to the [existing data source templates](https://thegraph.com/docs/en/developing/creating-a-subgraph/#data-source-templates), which are used to dynamically create new chain-based data sources. + +> This replaces the existing `ipfs.cat` API + +### Migration guide + +#### Update `graph-ts` and `graph-cli` + +File data sources requires graph-ts >=0.29.0 and graph-cli >=0.33.1 + +#### Add a new entity type which will be updated when files are found + +File data sources cannot access or update chain-based entities, but must update file specific entities. + +This may mean splitting out fields from existing entities into separate entities, linked together. + +Original combined entity: + +```graphql +type Token @entity { + id: ID! + tokenID: BigInt! + tokenURI: String! + externalURL: String! + ipfsURI: String! + image: String! + name: String! + description: String! + type: String! + updatedAtTimestamp: BigInt + owner: User! +} +``` + +New, split entity: + +```graphql +type Token @entity { + id: ID! + tokenID: BigInt! + tokenURI: String! + ipfsURI: TokenMetadata + updatedAtTimestamp: BigInt + owner: String! +} + +type TokenMetadata @entity { + id: ID! + image: String! + externalURL: String! + name: String! + description: String! +} +``` + +If the relationship is 1:1 between the parent entity and the resulting file data source entity, the simplest pattern is to link the parent entity to a resulting file entity by using the IPFS CID as the lookup. Get in touch on Discord if you are having difficulty modelling your new file-based entities! + +> You can use [nested filters](https://thegraph.com/docs/en/querying/graphql-api/#example-for-nested-entity-filtering) to filter parent entities on the basis of these nested entities. + +#### Add a new templated data source with `kind: file/ipfs` + +This is the data source which will be spawned when a file of interest is identified. + +```yaml +templates: + - name: TokenMetadata + kind: file/ipfs + mapping: + apiVersion: 0.0.7 + language: wasm/assemblyscript + file: ./src/mapping.ts + handler: handleMetadata + entities: + - TokenMetadata + abis: + - name: Token + file: ./abis/Token.json +``` + +> Currently `abis` are required, though it is not possible to call contracts from within file data sources + +The file data source must specifically mention all the entity types which it will interact with under `entities`. See [limitations](#Limitations) for more details. + +#### Create a new handler to process files + +This handler should accept one `Bytes` parameter, which will be the contents of the file, when it is found, which can then be processed. This will often be a JSON file, which can be processed with `graph-ts` helpers ([documentation](https://thegraph.com/docs/en/developing/assemblyscript-api/#json-api)). + +The CID of the file as a readable string can be accessed via the `dataSource` as follows: + +```typescript +const cid = dataSource.stringParam() +``` + +Example handler: + +```typescript +import { json, Bytes, dataSource } from '@graphprotocol/graph-ts' +import { TokenMetadata } from '../generated/schema' + +export function handleMetadata(content: Bytes): void { + let tokenMetadata = new TokenMetadata(dataSource.stringParam()) + const value = json.fromBytes(content).toObject() + if (value) { + const image = value.get('image') + const name = value.get('name') + const description = value.get('description') + const externalURL = value.get('external_url') + + if (name && image && description && externalURL) { + tokenMetadata.name = name.toString() + tokenMetadata.image = image.toString() + tokenMetadata.externalURL = externalURL.toString() + tokenMetadata.description = description.toString() + } + + tokenMetadata.save() + } +} +``` + +#### Spawn file data sources when required + +You can now create file data sources during execution of chain-based handlers: + +- Import the template from the auto-generated `templates` +- call `TemplateName.create(cid: string)` from within a mapping, where the cid is a valid IPFS content identifier + +> Currently Graph Node supports [v0 and v1 content identifiers](https://docs.ipfs.tech/concepts/content-addressing/), and content identifers with directories (e.g. `bafyreighykzv2we26wfrbzkcdw37sbrby4upq7ae3aqobbq7i4er3tnxci/metadata.json`) + +Example: + +```typescript +import { TokenMetadata as TokenMetadataTemplate } from '../generated/templates' + +const ipfshash = 'QmaXzZhcYnsisuue5WRdQDH6FDvqkLQX1NckLqBYeYYEfm' +//This example code is for a Crypto coven subgraph. The above ipfs hash is a directory with token metadata for all crypto coven NFTs. + +export function handleTransfer(event: TransferEvent): void { + let token = Token.load(event.params.tokenId.toString()) + if (!token) { + token = new Token(event.params.tokenId.toString()) + token.tokenID = event.params.tokenId + + token.tokenURI = '/' + event.params.tokenId.toString() + '.json' + const tokenIpfsHash = ipfshash + token.tokenURI + //This creates a path to the metadata for a single Crypto coven NFT. It concats the directory with "/" + filename + ".json" + + token.ipfsURI = tokenIpfsHash + + TokenMetadataTemplate.create(tokenIpfsHash) + } + + token.updatedAtTimestamp = event.block.timestamp + token.owner = event.params.to.toHexString() + token.save() +} +``` + +This will create a new file data source, which will poll Graph Node's configured IPFS endpoint, retrying if it is not found. When the file is found, the file data source handler will be executed. + +This example is using the CID as the lookup between the parent `Token` entity and the resulting `TokenMetadata` entity. + +> Previously, this is the point at which a subgraph developer would have called `ipfs.cat(CID)` to fetch the file + +Congratulations, you are using file data sources! + +#### Deploying your subgraphs + +You can now `build` and `deploy` your subgraph to any Graph Node >=v0.30.0-rc.0. + +#### Limitations + +File data source handlers and entities are isolated from other subgraph entities, ensuring that they are deterministic when executed, and ensuring no contamination of chain-based data sources. To be specific: + +- Entities created by File Data Sources are immutable, and cannot be updated +- File Data Source handlers cannot access entities from other file data sources +- Entities associated with File Data Sources cannot be accessed by chain-based handlers + +> While this constraint should not be problematic for most use-cases, it may introduce complexity for some. Please get in touch via Discord if you are having issues modelling your file-based data in a subgraph! + +Additionally, it is not possible to create data sources from a file data source, be it an onchain data source or another file data source. This restriction may be lifted in the future. + +#### Best practices + +If you are linking NFT metadata to corresponding tokens, use the metadata's IPFS hash to reference a Metadata entity from the Token entity. Save the Metadata entity using the IPFS hash as an ID. + +You can use [DataSource context](https://thegraph.com/docs/en/developing/assemblyscript-api/#entity-and-data-source-context) when creating File Data Sources to pass extra information which will be available to the File Data Source handler. + +If you have entities which are refreshed multiple times, create unique file-based entities using the IPFS hash & the entity ID, and reference them using a derived field in the chain-based entity. + +> We are working to improve the above recommendation, so queries only return the "most recent" version + +#### Known issues + +File data sources currently require ABIs, even though ABIs are not used ([issue](https://github.com/graphprotocol/graph-cli/issues/961)). Workaround is to add any ABI. + +Handlers for File Data Sources cannot be in files which import `eth_call` contract bindings, failing with "unknown import: `ethereum::ethereum.call` has not been defined" ([issue](https://github.com/graphprotocol/graph-cli/issues/4309)). Workaround is to create file data source handlers in a dedicated file. + +#### أمثلة + +[Crypto Coven Subgraph migration](https://github.com/azf20/cryptocoven-api/tree/file-data-sources-refactor) + +#### المراجع + +[GIP File Data Sources](https://forum.thegraph.com/t/gip-file-data-sources/2721) diff --git a/website/pages/ar/developing/developer-faqs.mdx b/website/pages/ar/developing/developer-faqs.mdx index 59867c8a9c46..756af3b352b3 100644 --- a/website/pages/ar/developing/developer-faqs.mdx +++ b/website/pages/ar/developing/developer-faqs.mdx @@ -2,35 +2,39 @@ title: الأسئلة الشائعة للمطورين --- -### 1. هل يمكنني حذف ال Subgraph الخاص بي؟ +### 1. What is a subgraph? -لا يمكن حذف ال Subgraph بمجرد إنشائها. +A subgraph is a custom API built on blockchain data. Subgraphs are queried using the GraphQL query language and are deployed to a Graph Node using the Graph CLI. Once deployed and published to The Graph's decentralized network, Indexers process subgraphs and make them available to be queried by subgraph consumers. -### 2. هل يمكنني تغيير اسم ال Subgraph الخاص بي؟ +### 2. Can I delete my subgraph? -لا. بمجرد إنشاء ال Subgraph ، لا يمكن تغيير الاسم. تأكد من التفكير بعناية قبل إنشاء ال Subgraph الخاص بك حتى يسهل البحث عنه والتعرف عليه من خلال ال Dapps الأخرى. +لا يمكن حذف ال الفرعيةرسم بياني بمجرد إنشائها. -### 3. هل يمكنني تغيير حساب GitHub المرتبط ب Subgraph الخاص بي؟ +### 3. Can I change my subgraph name? -لا. بمجرد إنشاء ال Subgraph ، لا يمكن تغيير حساب GitHub المرتبط. تأكد من التفكير بعناية قبل إنشاء ال Subgraph الخاص بك. +لا. بمجرد إنشاء ال الفرعيةرسم بياني ، لا يمكن تغيير الاسم. تأكد من التفكير بعناية قبل إنشاء ال الفرعيةرسم بياني الخاص بك حتى يسهل البحث عنه والتعرف عليه من خلال ال Dapps الأخرى. -### 4. هل يمكنني إنشاء Subgraph إذا لم تكن العقود الذكية الخاصة بي تحتوي على أحداث؟ +### 4. Can I change the GitHub account associated with my subgraph? -من المستحسن جدا أن تقوم بإنشاء عقودك الذكية بحيث يكون لديك أحداث مرتبطة بالبيانات التي ترغب في الاستعلام عنها. يتم تشغيل معالجات الأحداث في subgraph بواسطة أحداث العقد، وهي إلى حد بعيد أسرع طريقة لاسترداد البيانات المفيدة. +لا. بمجرد إنشاء ال الفرعيةرسم بياني ، لا يمكن تغيير حساب جيثب المرتبط. تأكد من التفكير بعناية قبل إنشاء ال الفرعيةرسم بياني الخاص بك. -إذا كانت العقود التي تعمل معها لا تحتوي على أحداث، فيمكن أن يستخدم ال Subgraph معالجات الـ block والاستدعاء لتشغيل الفهرسة. وهذا غير موصى به لأن الأداء سيكون أبطأ بشكل ملحوظ. +### 5. Am I still able to create a subgraph if my smart contracts don't have events? -### 5. هل من الممكن نشر Subgraph واحد تحمل نفس الاسم لشبكات متعددة؟ +It is highly recommended that you structure your smart contracts to have events associated with data you are interested in querying. Event handlers in the subgraph are triggered by contract events and are by far the fastest way to retrieve useful data. -ستحتاج إلى أسماء مختلفه لشبكات متعددة. ولا يمكن أن يكون لديك Subgraph مختلف تحت نفس الاسم ، إلا أن هناك طرقًا ملائمة لأمتلاك قاعدة بيانات واحدة لشبكات متعددة. اكتشف المزيد حول هذا الأمر في وثائقنا: [ إعادة نشر ال Subgraph ](/deploying/deploying-a-subgraph-to-hosted#redeploying-a-subgraph) +If the contracts you are working with do not contain events, your subgraph can use call and block handlers to trigger indexing. Although this is not recommended, as performance will be significantly slower. -### 6. كيف تختلف النماذج عن مصادر البيانات؟ +### 6. Is it possible to deploy one subgraph with the same name for multiple networks? -تسمح لك النماذج بإنشاء مصادر البيانات على الفور ، أثناء فهرسة ال Subgraph الخاص بك. قد يكون الأمر هو أن عقدك سينتج عنه عقود جديدة عندما يتفاعل الأشخاص معه ، وبما أنك تعرف شكل هذه العقود (ABI ، الأحداث ، إلخ) مسبقًا ، يمكنك تحديد الطريقة التي تريد فهرستها بها في النموذج ومتى يتم إنتاجها ، وسيقوم ال Subgraph الخاص بك بإنشاء مصدر بيانات ديناميكي عن طريق توفير عنوان العقد. +You will need separate names for multiple networks. While you can't have different subgraphs under the same name, there are convenient ways of having a single codebase for multiple networks. Find more on this in our documentation: [Redeploying a Subgraph](/deploying/deploying-a-subgraph-to-hosted#redeploying-a-subgraph) -راجع قسم "إنشاء نموذج مصدر بيانات" في: [ نماذج مصدر البيانات ](/developing/creating-a-subgraph#data-source-templates). +### 7. How are templates different from data sources? -### 7. كيف أتأكد من أنني أستخدم أحدث إصدار من graph-node لعمليات النشر المحلية الخاصة بي؟ +Templates allow you to create data sources on the fly, while your subgraph is indexing. It might be the case that your contract will spawn new contracts as people interact with it, and since you know the shape of those contracts (ABI, events, etc) upfront you can define how you want to index them in a template and when they are spawned your subgraph will create a dynamic data source by supplying the contract address. + +Check out the "Instantiating a data source template" section on: [Data Source Templates](/developing/creating-a-subgraph#data-source-templates). + +### 8. How do I make sure I'm using the latest version of graph-node for my local deployments? يمكنك تشغيل الأمر التالي: @@ -40,29 +44,29 @@ docker pull graphprotocol/graph-node:latest **ملاحظة:** سيستخدم docker / docker-compose دائما أي إصدار من graph-node تم سحبه في المرة الأولى التي قمت بتشغيلها ، لذلك من المهم القيام بذلك للتأكد من أنك محدث بأحدث إصدار من graph-node. -### 8. كيف يمكنني استدعاء دالة العقد أو الوصول إلى متغير الحالة العامة من Subgraph mappings الخاصة بي؟ +### 9. How do I call a contract function or access a public state variable from my subgraph mappings? -ألقِ نظرة على حالة `الوصول إلى العقد الذكي` داخل القسم [ AssemblyScript API ](/developing/assemblyscript-api). +Take a look at `Access to smart contract` state inside the section [AssemblyScript API](/developing/assemblyscript-api). -### 9. هل من الممكن إنشاء Subgraph باستخدام`graph init` من `graph-cli` بعقدين؟ أو هل يجب علي إضافة مصدر بيانات آخر يدويا في `subgraph.yaml` بعد تشغيل `graph init`؟ +### 10. Is it possible to set up a subgraph using `graph init` from `graph-cli` with two contracts? Or should I manually add another datasource in `subgraph.yaml` after running `graph init`? -للأسف هذا غير ممكن حاليا. الغرض من `graph init` هو أن تكون نقطة بداية أساسية حيث يمكنك من خلالها إضافة المزيد من مصادر البيانات يدويًا. +Unfortunately, this is currently not possible. `graph init` is intended as a basic starting point, from which you can then add more data sources manually. -### 10. أرغب في المساهمة أو إضافة مشكلة GitHub ، أين يمكنني العثور على مستودعات (repositories) مفتوحة المصدر؟ +### 11. I want to contribute or add a GitHub issue. Where can I find the open source repositories? - [graph-node](https://github.com/graphprotocol/graph-node) - [graph-cli](https://github.com/graphprotocol/graph-cli) - [graph-ts](https://github.com/graphprotocol/graph-ts) -### 11. ما هي الطريقة الموصى بها لإنشاء معرفات "تلقائية" لكيان عند معالجة الأحداث؟ +### 12. What is the recommended way to build "autogenerated" ids for an entity when handling events? إذا تم إنشاء كيان واحد فقط أثناء الحدث ولم يكن هناك أي شيء متاح بشكل أفضل ، فسيكون hash الإجراء + فهرس السجل فريدا. يمكنك إبهامها عن طريق تحويلها إلى Bytes ثم تمريرها عبر `crypto.keccak256` ولكن هذا لن يجعلها فريدة من نوعها. -### 12. عند الاستماع إلى عدة عقود ، هل من الممكن تحديد أمر العقد للاستماع إلى الأحداث؟ +### 13. When listening to multiple contracts, is it possible to select the contract order to listen to events? -ضمن ال Subgraph ، تتم معالجة الأحداث دائمًا بالترتيب الذي تظهر به في الكتل ، بغض النظر عما إذا كان ذلك عبر عقود متعددة أم لا. +ضمن ال الفرعيةرسم بياني، تتم معالجة الأحداث دائمًا بالترتيب الذي تظهر به في الكتل ، بغض النظر عما إذا كان ذلك عبر عقود متعددة أم لا. -### 13. هل من الممكن التفريق بين الشبكات (mainnet، Goerli، local) من داخل معالجات الأحداث؟ +### 14. Is it possible to differentiate between networks (mainnet, Goerli, local) from within event handlers? نعم. يمكنك القيام بذلك عن طريق استيراد `graph-ts` كما في المثال أدناه: @@ -73,100 +77,66 @@ docker pull graphprotocol/graph-node:latest ()dataSource.address ``` -### 14. هل يتم دعم معالجات الكتل والإستدعاء في Rinkeby؟ +### 15. Do you support block and call handlers on Goerli? -في Rinkeby ، ندعم معالجات الكتل ، لكن بدون `filter: call`. معالجات الاستدعاء غير مدعومة في الوقت الحالي. +Yes. Goerli supports block handlers, call handlers and event handlers. It should be noted that event handlers are far more performant than the other two handlers, and they are supported on every EVM-compatible network. -### 15. هل يمكنني استيراد ethers.js أو مكتبات JS الأخرى إلى ال Subgraph mappings الخاصة بي؟ +### 16. Can I import ethers.js or other JS libraries into my subgraph mappings? -ليس حاليًا ، حيث تتم كتابة ال mappings في AssemblyScript. أحد الحلول البديلة الممكنة لذلك هو تخزين البيانات الأولية في الكيانات وتنفيذ المنطق الذي يتطلب مكتبات JS على ال client. +ليس حاليًا ، حيث تتم كتابة ال mappings في أسيمبلي سكريبت. أحد الحلول البديلة الممكنة لذلك هو تخزين البيانات الأولية في الكيانات وتنفيذ المنطق الذي يتطلب مكتبات JS على ال عميل. -### 16. هل من الممكن تحديد الكتلة التي سيتم بدء الفهرسة عليها؟ +### 17. Is it possible to specify what block to start indexing on? -نعم. `dataSources.source.startBlock` في ملف `subgraph.yaml` يحدد رقم الكتلة الذي يبدأ مصدر البيانات بالفهرسة منها. في معظم الحالات نقترح استخدام الكتلة التي تم إنشاء العقد من خلالها: Start blocks +Yes. `dataSources.source.startBlock` in the `subgraph.yaml` file specifies the number of the block that the data source starts indexing from. In most cases, we suggest using the block in which the contract was created: Start blocks -### 17. هل هناك بعض النصائح لتحسين أداء الفهرسة؟ تستغرق مزامنة ال subgraph وقتًا طويلاً جدًا. +### 18. Are there some tips to increase the performance of indexing? My subgraph is taking a very long time to sync. -نعم ، يجب إلقاء نظرة على ميزة start block الاختيارية لبدء الفهرسة من الكتل التي تم نشر العقد فيها:[Start blocks](/developing/creating-a-subgraph#start-blocks) +Yes, you should take a look at the optional start block feature to start indexing from the block that the contract was deployed: [Start blocks](/developing/creating-a-subgraph#start-blocks) -### 18. هل توجد طريقة مباشرة للاستعلام عن الـ Subgraph وذلك لتحديد رقم الكتلة الأخير والتي تمت فهرستها؟ +### 19. Is there a way to query the subgraph directly to determine the latest block number it has indexed? -نعم! جرب الأمر التالي ، مع استبدال "Organization / subgraphName" بالمؤسسة واسم الـ subgraph الخاص بك: +نعم! جرب الأمر التالي ، مع استبدال "Organization / subgraphName" بالمؤسسة واسم الـ الفرعيةرسم بياني الخاص بك: ```sh curl -X POST -d '{ "query": "{indexingStatusForCurrentVersion(subgraphName: \"organization/subgraphName\") { chains { latestBlock { hash number }}}}"}' https://api.thegraph.com/index-node/graphql ``` -### 19. ما هي الشبكات الذي يدعمها The Graph؟ - -تدعم graph-node أي سلسلة API JSON RPC متوافقة مع EVM. - -شبكة The Graph تدعم ال subgraph وذلك لفهرسة mainnet Ethereum: - -- `mainnet` - -في ال Hosted Service ، يتم دعم الشبكات التالية: - -- Ethereum mainnet -- Rinkeby -- Goerli -- PoA-Core -- PoA-Sokol -- Gnosis Chain -- NEAR -- NEAR testnet -- Matic -- Mumbai -- Fantom -- Binance Smart Chain -- Clover -- Avalanche -- Fuji -- Celo -- Celo-Alfajores -- Fuse -- Moonbeam -- Moonriver -- Moonbase Alpha (Moonbeam/Moonriver Testnet) -- Arbitrum One -- (Arbitrum Testnet (on Rinkeby -- Optimism -- (Optimism Testnet (on Goerli) +### 20. What networks are supported by The Graph? -هناك عمل قيد التقدم من أجل دمج ال blockchain الأخرى ، يمكنك قراءة المزيد في مرجعنا: [RFC-0003: Multi-Blockchain Support](https://github.com/graphprotocol/rfcs/pull/8/files). +You can find the list of the supported networks [here](/developing/supported-networks). -### 20. هل من الممكن نسخ الsubgraph إلى حساب آخر أو إلى endpoint دون إعادة التوزيع؟ +### 21. Is it possible to duplicate a subgraph to another account or endpoint without redeploying? -يجب عليك إعادة نشر ال Subgraph ، ولكن إذا لم يتغير (subgraph ID (IPFS hash ، فلن يضطر إلى المزامنة من البداية. +يجب عليك إعادة نشر ال الفرعيةرسم بياني ، ولكن إذا لم يتغير الفرعيةرسم بياني (ID (IPFS hash ، فلن يضطر إلى المزامنة من البداية. -### 21. هل من الممكن استخدام Apollo Federation أعلى graph-node؟ +### 22. Is this possible to use Apollo Federation on top of graph-node? لم يتم دعم Federation بعد ، على الرغم من أننا نريد دعمه في المستقبل. و في الوقت الحالي ، الذي يمكنك القيام به هو استخدام schema stitching ، إما على client أو عبر خدمة البروكسي. -### 22. هل يوجد حد معين لعدد الكائنات (objects) التي يمكن ل TheGraph إرجاعها لكل استعلام؟ +### 23. Is there a limit to how many objects The Graph can return per query? -بشكل افتراضي ، تقتصر ردود الاستعلام على 100 عنصر لكل مجموعة. فإذا كنت ترغب في تلقي المزيد ، فيمكنك زيادة ما يصل إلى 1000 عنصر لكل مجموعة وما بعد ذلك يمكنك ترقيم الصفحات باستخدام: +By default, query responses are limited to 100 items per collection. If you want to receive more, you can go up to 1000 items per collection and beyond that, you can paginate with: ```graphql someCollection(first: 1000, skip: ) { ... } ``` -### 23. إذا كانت الواجهة الأمامية ل dapp الخاصة بي تستخدم TheGraph للاستعلام ، فهل أحتاج إلى كتابة مفتاح الاستعلام الخاص بي في الواجهة الأمامية مباشرةً؟ وماذا لو دفعنا رسوم الاستعلام للمستخدمين - هل سيتسبب المستخدمون الضارون في أن تكون رسوم الاستعلام الخاصة بنا عالية جدا؟ +### 24. If my dapp frontend uses The Graph for querying, do I need to write my query key into the frontend directly? What if we pay query fees for users – will malicious users cause our query fees to be very high? -في الوقت الحالي ، الطريقة الموصى بها لتطبيق dapp هي إضافة المفتاح إلى الواجهة الأمامية وكشفه للمستخدمين. ومع ذلك ، يمكنك تقييد هذا المفتاح باسم مضيف ، مثل*yourdapp.io* و Subgraph. ويتم تشغيل gateway حاليا بواسطة Edge&؛ Node. جزء من مسؤولية gateway هي مراقبة السلوك المسيء وحظر حركة البيانات من العملاء الضارين. +Currently, the recommended approach for a dapp is to add the key to the frontend and expose it to end users. That said, you can limit that key to a hostname, like _yourdapp.io_ and subgraph. The gateway is currently being run by Edge & Node. Part of the responsibility of a gateway is to monitor for abusive behavior and block traffic from malicious clients. -### 24. كيف يمكنني للعثور على ال Subgraph الحالي الخاص بي في Hosted Service؟ +### 25. Where do I go to find my current subgraph on the Hosted Service? -توجه إلى Hosted Service للعثور على ال Subgraphs التي نشرتها أنت أو الآخرين في ال Hosted Service. يمكنك العثور عليه [ هنا. ](https://thegraph.com/hosted-service) +Head over to the Hosted Service in order to find subgraphs that you or others deployed to the Hosted Service. You can find it [here](https://thegraph.com/hosted-service). -### 25. هل ستبدأ ال Hosted service في فرض رسوم الاستعلام؟ +### 26. Will the Hosted Service start charging query fees? -لن يقوم TheGraph بفرض رسوم على Hosted Service أبدًا. و TheGraph عبارة عن بروتوكول لامركزي ، ولا يتماشى فرض رسوم على خدمة مركزية مع قيم TheGraph. وال Hosted Service خطوة مؤقتة للمساعدة في الوصول إلى الشبكة اللامركزية. وسيكون لدى المطورين وقت كافٍ للانتقال إلى الشبكة اللامركزية. +لن يقوم رسم بياني بفرض رسوم على خدمة مستضافة أبدًا. و رسم بياني عبارة عن بروتوكول لامركزي ، ولا يتماشى فرض رسوم على خدمة مركزية مع قيم رسم بياني. وال خدمة مستضافة خطوة مؤقتة للمساعدة في الوصول إلى الشبكة اللامركزية. وسيكون لدى المطورين وقت كافٍ للانتقال إلى الشبكة اللامركزية. -### 26. متى سيتم إيقاف تشغيل الخدمة المستضافة؟ +### 27. When will the Hosted Service be shut down? -عندما نخطط لذلك ، فسيتم اعلامكم مسبقًا بوقت كافٍ مع مراعاة أي Subgraph مبنية على ال Hosted service. +The Hosted Service will shut down in Q1 2023. Read the announcement blog post [here](https://thegraph.com/blog/sunsetting-hosted-service). All dapps using the Hosted Service are encouraged to migrate to the decentralized network. Migration Grants are available for developers to help migrate their subgraph. If your dapp is migrating a subgraph you can apply [here](https://thegraph.typeform.com/to/Zz8UAPri?typeform-source=thegraph.com). -### 27. كيف يمكنني ترقية ال subgraph على mainnet؟ +### 28. How do I upgrade a subgraph on mainnet? -إذا كنت مطور ل Subgraph ، فيمكنك ترقية إصدار جديد من ال Subgraph إلى Studio وذلك باستخدام CLI. وستكون خاصة في تلك المرحلة ولكن إذا كنت راضيًا عنها ، يمكنك نشرها إلى Graph Explorer اللامركزي. وسيؤدي هذا إلى إنشاء نسخة جديدة من subgraph الخاص بك حيث يمكن للمنسقين (Curators) البدء في الإشارة إليه. +If you’re a subgraph developer, you can upgrade a new version of your subgraph to the Studio using the CLI. It’ll be private at that point, but if you’re happy with it, you can publish to the decentralized Graph Explorer. This will create a new version of your subgraph that Curators can start signaling on. diff --git a/website/pages/ar/developing/supported-networks.mdx b/website/pages/ar/developing/supported-networks.mdx new file mode 100644 index 000000000000..6ced97c42dea --- /dev/null +++ b/website/pages/ar/developing/supported-networks.mdx @@ -0,0 +1,74 @@ +--- +title: الشبكات المدعومة +--- + +## The Graph's Decentralized Network + +The following networks are supported on The Graph's Decentralized Network: + +- `mainnet` (Ethereum) +- `gnosis`\* +- `celo`\* +- `avalanche`\* +- `arbitrum-one`\* + +\*In beta. + +## الخدمة المستضافة + +> The hosted service relies on the stability and reliability of the underlying technologies, namely the provided JSON RPC endpoints. + +The following networks are supported in beta on the Hosted Service: + +- `goerli` +- `poa-core` +- `poa-sokol` +- `matic` (now known as Polygon) +- `mumbai` +- `fantom` +- `fantom-testnet` +- `bsc` (now known as BNB Chain) +- `chapel` +- `clover` +- `fuji` +- `fuse` +- `moonriver` +- `moonbeam` +- `mbase` +- `optimism` +- `optimism-goerli` +- `aurora` +- `aurora-testnet` +- `boba` +- `harmony` +- `zkSync2-testnet` +- `osmosis-1` +- `base-testnet` + +### Near + +- `near-mainnet` +- `near-testnet` + +### Cosmos + +- `cosmoshub-4` +- `theta-testnet-001` (this is the current Cosmos Hub testnet) + +### Arweave + +- `arweave-mainnet` + +You will **not be able** to publish a subgraph that indexes a non-mainnet network to the decentralized Graph Network in [Subgraph Studio](/deploying/subgraph-studio). + +Ropsten, Rinkeby and Kovan are being deprecated. Read more on the [Ethereum Foundation Blog](https://blog.ethereum.org/2022/06/21/testnet-deprecation). As of Feb 25th 2023, Ropsten, Rinkeby and Kovan are no longer supported by the Hosted Service. Goerli will be maintained by client developers post-merge, and is also supported by the Hosted Service. Developers who currently use Ropsten, Rinkeby or Kovan as their staging/testing environment are encouraged to migrate to Goerli. + +Subgraphs indexing Gnosis Chain can now be deployed with the `gnosis` network identifier. `xdai` is still supported for existing hosted service subgraphs. + +For a full list of which features are supported on the decentralized network, see [this page](https://github.com/graphprotocol/indexer/blob/main/docs/networks/mainnet.md#feature-support). + +## Graph Node + +If your preferred network isn't support on The Graph's decentralized network, you can run your own Graph Node to index any EVM-compatible network. Make sure that the [version](https://github.com/graphprotocol/graph-node/releases) you are using supports the network and you have the needed configuration. + +Graph Node can also index other protocols, via a Firehose integration. Firehose integrations have been created for NEAR, Arweave and Cosmos-based networks. diff --git a/website/pages/ar/developing/unit-testing-framework.mdx b/website/pages/ar/developing/unit-testing-framework.mdx index 93990996cce1..0feb89dfd1fd 100644 --- a/website/pages/ar/developing/unit-testing-framework.mdx +++ b/website/pages/ar/developing/unit-testing-framework.mdx @@ -1,8 +1,8 @@ --- -title: اختبار وحدة Framework +title: Unit Testing Framework --- -Matchstick هو اختبار وحدة framework ، تم تطويره بواسطة [ LimeChain ](https://limechain.tech/) ، والذي يسمح لمطوري الـ subgraph من اختبار منطق الـ mapping في بيئة sandboxed ونشر الـ subgraphs الخاصة بهم بثقة! +Matchstick is a unit testing framework, developed by [LimeChain](https://limechain.tech/), that enables subgraph developers to test their mapping logic in a sandboxed environment and deploy their subgraphs with confidence! ## Getting Started @@ -24,6 +24,12 @@ Postgres installation command: brew install postgresql ``` +Create a symlink to the latest libpq.5.lib _You may need to create this dir first_ `/usr/local/opt/postgresql/lib/` + +```sh +ln -sf /usr/local/opt/postgresql@14/lib/postgresql@14/libpq.5.dylib /usr/local/opt/postgresql/lib/libpq.5.dylib +``` + #### Linux Postgres installation command (depends on your distro): @@ -32,9 +38,79 @@ Postgres installation command (depends on your distro): sudo apt install postgresql ``` -### OS-specific release binaries +### WSL (Windows Subsystem for Linux) + +You can use Matchstick on WSL both using the Docker approach and the binary approach. As WSL can be a bit tricky, here's a few tips in case you encounter issues like + +``` +static BYTES = Symbol("Bytes") SyntaxError: Unexpected token = +``` + +or + +``` +/node_modules/gluegun/build/index.js:13 throw up; +``` + +Please make sure you're on a newer version of Node.js graph-cli doesn't support **v10.19.0** anymore, and that is still the default version for new Ubuntu images on WSL. For instance Matchstick is confirmed to be working on WSL with **v18.1.0**, you can switch to it either via **nvm** or if you update your global Node.js. Don't forget to delete `node_modules` and to run `npm install` again after updating you nodejs! Then, make sure you have **libpq** installed, you can do that by running + +``` +sudo apt-get install libpq-dev +``` + +And finally, do not use `graph test` (which uses your global installation of graph-cli and for some reason that looks like it's broken on WSL currently), instead use `yarn test` or `npm run test` (that will use the local, project-level instance of graph-cli, which works like a charm). For that you would of course need to have a `"test"` script in your `package.json` file which can be something as simple as + +```json +{ + "name": "demo-subgraph", + "version": "0.1.0", + "scripts": { + "test": "graph test", + ... + }, + "dependencies": { + "@graphprotocol/graph-cli": "^0.30.0", + "@graphprotocol/graph-ts": "^0.27.0", + "matchstick-as": "^0.5.0" + } +} +``` + +### الاستخدام + +To use **Matchstick** in your subgraph project just open up a terminal, navigate to the root folder of your project and simply run `graph test [options] ` - it downloads the latest **Matchstick** binary and runs the specified test or all tests in a test folder (or all existing tests if no datasource flag is specified). + +### CLI options + +This will run all tests in the test folder: + +```sh +graph test +``` + +This will run a test named gravity.test.ts and/or all test inside of a folder named gravity: + +```sh +graph test gravity +``` + +This will run only that specific test file: + +```sh +graph test path/to/file.test.ts +``` -The release binary comes in two flavours - for **МacOS** and **Linux**. To add **Matchstick** to your subgraph project just open up a terminal, navigate to the root folder of your project and simply run `graph test` - it downloads the latest **Matchstick** binary and runs the specified test or all tests in a test folder (or all existing tests if no datasource flag is specified). Example usage: `graph test gravity`. +**Options:** + +```sh +-c, --coverage Run the tests in coverage mode +-d, --docker Run the tests in a docker container (Note: Please execute from the root folder of the subgraph) +-f --force Binary: Redownloads the binary. Docker: Redownloads the Dockerfile and rebuilds the docker image. +-h, --help Show usage information +-l, --logs Logs to the console information about the OS, CPU model and download url (debugging purposes) +-r, --recompile Forces tests to be recompiled +-v, --version Choose the version of the rust binary that you want to be downloaded/used +``` ### Docker @@ -42,7 +118,7 @@ From `graph-cli 0.25.2`, the `graph test` command supports running `matchstick` ❗ If you have previously ran `graph test` you may encounter the following error during docker build: -``` +```sh error from sender: failed to xattr node_modules/binary-install-raw/bin/binary-: permission denied ``` @@ -50,24 +126,405 @@ In this case create a `.dockerignore` in the root folder and add `node_modules/b ### Configuration -Matchstick can be configured to use a custom tests and libs folder via `matchstick.yaml` config file: +Matchstick can be configured to use a custom tests, libs and manifest path via `matchstick.yaml` config file: ```yaml -testsFolder: ./folderName +testsFolder: path/to/tests libsFolder: path/to/libs +manifestPath: path/to/subgraph.yaml ``` -### Example Subgraph +### Demo subgraph -You can try out and play around with the examples from this guide by cloning the [Example Subgraph repo](https://github.com/graphprotocol/example-subgraph) +You can try out and play around with the examples from this guide by cloning the [Demo Subgraph repo](https://github.com/LimeChain/demo-subgraph) ### Video tutorials Also you can check out the video series on ["How to use Matchstick to write unit tests for your subgraphs"](https://www.youtube.com/playlist?list=PLTqyKgxaGF3SNakGQwczpSGVjS_xvOv3h) +## Tests structure (>=0.5.0) + +_**IMPORTANT: Requires matchstick-as >=0.5.0**_ + +### describe() + +`describe(name: String , () => {})` - Defines a test group. + +**_Notes:_** + +- _Describes are not mandatory. You can still use test() the old way, outside of the describe() blocks_ + +Example: + +```typescript +import { describe, test } from "matchstick-as/assembly/index" +import { handleNewGravatar } from "../../src/gravity" + +describe("handleNewGravatar()", () => { + test("Should create a new Gravatar entity", () => { + ... + }) +}) +``` + +Nested `describe()` example: + +```typescript +import { describe, test } from "matchstick-as/assembly/index" +import { handleUpdatedGravatar } from "../../src/gravity" + +describe("handleUpdatedGravatar()", () => { + describe("When entity exists", () => { + test("updates the entity", () => { + ... + }) + }) + + describe("When entity does not exists", () => { + test("it creates a new entity", () => { + ... + }) + }) +}) +``` + +--- + +### test() + +`test(name: String, () =>, should_fail: bool)` - Defines a test case. You can use test() inside of describe() blocks or independently. + +Example: + +```typescript +import { describe, test } from "matchstick-as/assembly/index" +import { handleNewGravatar } from "../../src/gravity" + +describe("handleNewGravatar()", () => { + test("Should create a new Entity", () => { + ... + }) +}) +``` + +or + +```typescript +test("handleNewGravatar() should create a new entity", () => { + ... +}) + + +``` + +--- + +### beforeAll() + +Runs a code block before any of the tests in the file. If `beforeAll` is declared inside of a `describe` block, it runs at the beginning of that `describe` block. + +أمثلة: + +Code inside `beforeAll` will execute once before _all_ tests in the file. + +```typescript +import { describe, test, beforeAll } from "matchstick-as/assembly/index" +import { handleUpdatedGravatar, handleNewGravatar } from "../../src/gravity" +import { Gravatar } from "../../generated/schema" + +beforeAll(() => { + let gravatar = new Gravatar("0x0") + gravatar.displayName = “First Gravatar” + gravatar.save() + ... +}) + +describe("When the entity does not exist", () => { + test("it should create a new Gravatar with id 0x1", () => { + ... + }) +}) + +describe("When entity already exists", () => { + test("it should update the Gravatar with id 0x0", () => { + ... + }) +}) +``` + +Code inside `beforeAll` will execute once before all tests in the first describe block + +```typescript +import { describe, test, beforeAll } from "matchstick-as/assembly/index" +import { handleUpdatedGravatar, handleNewGravatar } from "../../src/gravity" +import { Gravatar } from "../../generated/schema" + +describe("handleUpdatedGravatar()", () => { + beforeAll(() => { + let gravatar = new Gravatar("0x0") + gravatar.displayName = “First Gravatar” + gravatar.save() + ... + }) + + test("updates Gravatar with id 0x0", () => { + ... + }) + + test("creates new Gravatar with id 0x1", () => { + ... + }) +}) +``` + +--- + +### afterAll() + +Runs a code block after all of the tests in the file. If `afterAll` is declared inside of a `describe` block, it runs at the end of that `describe` block. + +Example: + +Code inside `afterAll` will execute once after _all_ tests in the file. + +```typescript +import { describe, test, afterAll } from "matchstick-as/assembly/index" +import { handleUpdatedGravatar, handleNewGravatar } from "../../src/gravity" +import { store } from "@graphprotocol/graph-ts" + +afterAll(() => { + store.remove("Gravatar", "0x0") + ... +}) + +describe("handleNewGravatar, () => { + test("creates Gravatar with id 0x0", () => { + ... + }) +}) + +describe("handleUpdatedGravatar", () => { + test("updates Gravatar with id 0x0", () => { + ... + }) +}) +``` + +Code inside `afterAll` will execute once after all tests in the first describe block + +```typescript +import { describe, test, afterAll, clearStore } from "matchstick-as/assembly/index" +import { handleUpdatedGravatar, handleNewGravatar } from "../../src/gravity" + +describe("handleNewGravatar", () => { + afterAll(() => { + store.remove("Gravatar", "0x1") + ... + }) + + test("It creates a new entity with Id 0x0", () => { + ... + }) + + test("It creates a new entity with Id 0x1", () => { + ... + }) +}) + +describe("handleUpdatedGravatar", () => { + test("updates Gravatar with id 0x0", () => { + ... + }) +}) +``` + +--- + +### beforeEach() + +Runs a code block before every test. If `beforeEach` is declared inside of a `describe` block, it runs before each test in that `describe` block. + +Examples: Code inside `beforeEach` will execute before each tests. + +```typescript +import { describe, test, beforeEach, clearStore } from "matchstick-as/assembly/index" +import { handleNewGravatars } from "./utils" + +beforeEach(() => { + clearStore() // <-- clear the store before each test in the file +}) + +describe("handleNewGravatars, () => { + test("A test that requires a clean store", () => { + ... + }) + + test("Second that requires a clean store", () => { + ... + }) +}) + + ... +``` + +Code inside `beforeEach` will execute only before each test in the that describe + +```typescript +import { describe, test, beforeEach } from 'matchstick-as/assembly/index' +import { handleUpdatedGravatar, handleNewGravatar } from '../../src/gravity' + +describe('handleUpdatedGravatars', () => { + beforeEach(() => { + let gravatar = new Gravatar('0x0') + gravatar.displayName = 'First Gravatar' + gravatar.imageUrl = '' + gravatar.save() + }) + + test('Upates the displayName', () => { + assert.fieldEquals('Gravatar', '0x0', 'displayName', 'First Gravatar') + + // code that should update the displayName to 1st Gravatar + + assert.fieldEquals('Gravatar', '0x0', 'displayName', '1st Gravatar') + store.remove('Gravatar', '0x0') + }) + + test('Updates the imageUrl', () => { + assert.fieldEquals('Gravatar', '0x0', 'imageUrl', '') + + // code that should changes the imageUrl to https://www.gravatar.com/avatar/0x0 + + assert.fieldEquals('Gravatar', '0x0', 'imageUrl', 'https://www.gravatar.com/avatar/0x0') + store.remove('Gravatar', '0x0') + }) +}) +``` + +--- + +### afterEach() + +Runs a code block after every test. If `afterEach` is declared inside of a `describe` block, it runs after each test in that `describe` block. + +أمثلة: + +Code inside `afterEach` will execute after every test. + +```typescript +import { describe, test, beforeEach, afterEach } from "matchstick-as/assembly/index" +import { handleUpdatedGravatar, handleNewGravatar } from "../../src/gravity" + +beforeEach(() => { + let gravatar = new Gravatar("0x0") + gravatar.displayName = “First Gravatar” + gravatar.save() +}) + +afterEach(() => { + store.remove("Gravatar", "0x0") +}) + +describe("handleNewGravatar", () => { + ... +}) + +describe("handleUpdatedGravatar", () => { + test("Upates the displayName", () => { + assert.fieldEquals("Gravatar", "0x0", "displayName", "First Gravatar") + + // code that should update the displayName to 1st Gravatar + + assert.fieldEquals("Gravatar", "0x0", "displayName", "1st Gravatar") + }) + + test("Updates the imageUrl", () => { + assert.fieldEquals("Gravatar", "0x0", "imageUrl", "") + + // code that should changes the imageUrl to https://www.gravatar.com/avatar/0x0 + + assert.fieldEquals("Gravatar", "0x0", "imageUrl", "https://www.gravatar.com/avatar/0x0") + }) +}) +``` + +Code inside `afterEach` will execute after each test in that describe + +```typescript +import { describe, test, beforeEach, afterEach } from "matchstick-as/assembly/index" +import { handleUpdatedGravatar, handleNewGravatar } from "../../src/gravity" + +describe("handleNewGravatar", () => { + ... +}) + +describe("handleUpdatedGravatar", () => { + beforeEach(() => { + let gravatar = new Gravatar("0x0") + gravatar.displayName = "First Gravatar" + gravatar.imageUrl = "" + gravatar.save() + }) + + afterEach(() => { + store.remove("Gravatar", "0x0") + }) + + test("Upates the displayName", () => { + assert.fieldEquals("Gravatar", "0x0", "displayName", "First Gravatar") + + // code that should update the displayName to 1st Gravatar + + assert.fieldEquals("Gravatar", "0x0", "displayName", "1st Gravatar") + }) + + test("Updates the imageUrl", () => { + assert.fieldEquals("Gravatar", "0x0", "imageUrl", "") + + // code that should changes the imageUrl to https://www.gravatar.com/avatar/0x0 + + assert.fieldEquals("Gravatar", "0x0", "imageUrl", "https://www.gravatar.com/avatar/0x0") + }) +}) +``` + +## Asserts + +```typescript +fieldEquals(entityType: string, id: string, fieldName: string, expectedVal: string) + +equals(expected: ethereum.Value, actual: ethereum.Value) + +notInStore(entityType: string, id: string) + +addressEquals(address1: Address, address2: Address) + +bytesEquals(bytes1: Bytes, bytes2: Bytes) + +i32Equals(number1: i32, number2: i32) + +bigIntEquals(bigInt1: BigInt, bigInt2: BigInt) + +booleanEquals(bool1: boolean, bool2: boolean) + +stringEquals(string1: string, string2: string) + +arrayEquals(array1: Array, array2: Array) + +tupleEquals(tuple1: ethereum.Tuple, tuple2: ethereum.Tuple) + +assertTrue(value: boolean) + +assertNull(value: T) + +assertNotNull(value: T) + +entityCount(entityType: string, expectedCount: i32) +``` + ## Write a Unit Test -Let's see how a simple unit test would look like, using the Gravatar [Example Subgraph](https://github.com/graphprotocol/example-subgraph). +Let's see how a simple unit test would look like using the Gravatar examples in the [Demo Subgraph](https://github.com/LimeChain/demo-subgraph/blob/main/src/gravity.ts). Assuming we have the following handler function (along with two helper functions to make our life easier): @@ -156,11 +613,11 @@ test('Next test', () => { That's a lot to unpack! First off, an important thing to notice is that we're importing things from `matchstick-as`, our AssemblyScript helper library (distributed as an npm module). You can find the repository [here](https://github.com/LimeChain/matchstick-as). `matchstick-as` provides us with useful testing methods and also defines the `test()` function which we will use to build our test blocks. The rest of it is pretty straightforward - here's what happens: -- نقوم بإعداد حالتنا الأولية وإضافة كيان Gravatar مخصص ؛; -- نعرف كائني حدث `NewGravatar` بالإضافة لبياناتهم ، باستخدام دالة `() createNewGravatarEvent`; -- نحن نستدعي methods المعالج لتلك الأحداث - `() handleNewGravatars` ونمرر فيه قائمة أحداثنا المخصصة ؛; -- نؤكد حالة المخزن. كيف يعمل هذا؟ - نمرر مجموعة فريدة من نوع Entity و id. ثم نتحقق من حقل معين في ذلك الـ Entity ونؤكد أنه يحتوي على القيمة التي نتوقعها. نحن نقوم بذلك لكلا الـ Gravatar Entity الأولية الذي أضفناه إلى المخزن، بالإضافة إلى كيانين Gravatar اللذان تمت إضافتهما عند استدعاء دالة المعالج; -- وأخيرا - نقوم بتنظيف المخزن باستخدام `() clearStore` بحيث يمكن أن يبدأ اختبارنا التالي بكائن(object) مخزن جديد وفارغ. يمكننا تعريف العديد من كتل الاختبار كما نريد. +- We're setting up our initial state and adding one custom Gravatar entity; +- We define two `NewGravatar` event objects along with their data, using the `createNewGravatarEvent()` function; +- We're calling out handler methods for those events - `handleNewGravatars()` and passing in the list of our custom events; +- We assert the state of the store. How does that work? - We're passing a unique combination of Entity type and id. Then we check a specific field on that Entity and assert that it has the value we expect it to have. We're doing this both for the initial Gravatar Entity we added to the store, as well as the two Gravatar entities that gets added when the handler function is called; +- And lastly - we're cleaning the store using `clearStore()` so that our next test can start with a fresh and empty store object. We can define as many test blocks as we want. There we go - we've created our first test! 👏 @@ -476,7 +933,11 @@ test('Derived fields example test', () => { ### Testing dynamic data sources -Testing dynamic data sources can be be done by mocking the return value of the context(), address() and network() functions of the dataSource namespace. These functions currently return the following: context - returns an empty entity (DataSourceContext), address - returns "0x0000000000000000000000000000000000000000", network - returns "mainnet". The create(...) and createWithContext(...) functions are mocked to do nothing so they don't need to be called in the tests at all. Changes to the return values can be done through the functions of the dataSourceMock namespace in matchstick-as (version 0.3.0+). Example below: First we have the following event handler (which has been intentionally repurposed to showcase datasource mocking): +Testing dynamic data sources can be be done by mocking the return value of the `context()`, `address()` and `network()` functions of the dataSource namespace. These functions currently return the following: `context()` - returns an empty entity (DataSourceContext), `address()` - returns `0x0000000000000000000000000000000000000000`, `network()` - returns `mainnet`. The `create(...)` and `createWithContext(...)` functions are mocked to do nothing so they don't need to be called in the tests at all. Changes to the return values can be done through the functions of the `dataSourceMock` namespace in `matchstick-as` (version 0.3.0+). + +Example below: + +First we have the following event handler (which has been intentionally repurposed to showcase datasource mocking): ```typescript export function handleApproveTokenDestinations(event: ApproveTokenDestinations): void { @@ -541,13 +1002,13 @@ To run the test coverage functionality provided in **Matchstick**, there are a f In order for **Matchstick** to check which handlers are being run, those handlers need to be exported from the **test file**. So for instance in our example, in our gravity.test.ts file we have the following handler being imported: -```ts +```typescript import { handleNewGravatar } from '../../src/gravity' ``` In order for that function to be visible (for it to be included in the `wat` file **by name**) we need to also export it, like this: -```ts +```typescript export { handleNewGravatar } ``` @@ -561,7 +1022,7 @@ graph test -- -c You could also add a custom `coverage` command to your `package.json` file, like so: -```ts +```typescript "scripts": { /.../ "coverage": "graph test -- -c" diff --git a/website/pages/ar/firehose.mdx b/website/pages/ar/firehose.mdx new file mode 100644 index 000000000000..5e2b37ee4bb6 --- /dev/null +++ b/website/pages/ar/firehose.mdx @@ -0,0 +1,11 @@ +--- +title: Firehose +--- + +Firehose provides a files-based and streaming-first approach to processing blockchain data. + +Firehose integrations have been built for Ethereum (and many EVM chains), NEAR, Solana, Cosmos and Arweave, with more in the works. + +Graph Node integrations have been built for multiple chains, so subgraphs can stream data from a Firehose to power performant and scaleable indexing. Firehose also powers [substreams](/substreams), a new transformation technology built by The Graph core developers. + +Visit the [firehose documentation](https://firehose.streamingfast.io/) to learn more. diff --git a/website/pages/ar/glossary.mdx b/website/pages/ar/glossary.mdx new file mode 100644 index 000000000000..2a7c0b281197 --- /dev/null +++ b/website/pages/ar/glossary.mdx @@ -0,0 +1,79 @@ +--- +title: Glossary +--- + +- **The Graph**: A decentralized protocol for indexing and querying data. + +- **Query**: A request for data. In the case of The Graph, a query is a request for data from a subgraph that will be answered by an Indexer. + +- **GraphQL**: A query language for APIs and a runtime for fulfilling those queries with your existing data. The Graph uses GraphQL to query subgraphs. + +- **Subgraph**: A custom API built on blockchain data that can be queried using [GraphQL](https://graphql.org/). Developers can build, deploy and publish subgraphs to The Graph's decentralized network. Then, Indexers can begin indexing subgraphs to make them available to be queried by subgraph consumers. + +- **Hosted Service**: A temporary scaffold service for building and querying subgraphs as The Graph's decentralized network is maturing its cost of service, quality of service, and developer experience. + +- **Indexers**: Network participants that run indexing nodes to index data from blockchains and serve GraphQL queries. + +- **Indexer Revenue Streams**: Indexers are rewarded in GRT with two components: query fee rebates and indexing rewards. + + 1. **Query Fee Rebates**: Payments from subgraph consumers for serving queries on the network. + + 2. **Indexing Rewards**: The rewards that Indexers receive for indexing subgraphs. Indexing rewards are generated via new issuance of 3% GRT annually. + +- **Indexer's Self Stake**: The amount of GRT that Indexers stake to participate in the decentralized network. The minimum is 100,000 GRT, and there is no upper limit. + +- **Delegators**: Network participants who own GRT and delegate their GRT to Indexers. This allows Indexers to increase their stake in subgraphs on the network. In return, Delegators receive a portion of the Indexing Rewards that Indexers receive for processing subgraphs. + +- **Delegation Tax**: A 0.5% fee paid by Delegators when they delegate GRT to Indexers. The GRT used to pay the fee is burned. + +- **Curators**: Network participants that identify high-quality subgraphs, and “curate” them (i.e., signal GRT on them) in exchange for curation shares. When Indexers claim query fees on a subgraph, 10% is distributed to the Curators of that subgraph. Indexers earn indexing rewards proportional to the signal on a subgraph. We see a correlation between the amount of GRT signalled and the number of Indexers indexing a subgraph. + +- **Curation Tax**: A 1% fee paid by Curators when they signal GRT on subgraphs. The GRT used to pay the fee is burned. + +- **Subgraph Consumer**: Any application or user that queries a subgraph. + +- **Subgraph Developer**: A developer who builds and deploys a subgraph to The Graph's decentralized network. + +- **Subgraph Manifest**: A JSON file that describes the subgraph's GraphQL schema, data sources, and other metadata. [Here](https://ipfs.io/ipfs/QmVQdzeGdPUiLiACeqXRpKAYpyj8Z1yfWLMUq7A7WundUf) is an example. + +- **Rebate Pool**: An economic security measure that holds query fees paid by subgraph consumers until they may be claimed by Indexers as query fee rebates. Residual GRT is burned. + +- **Epoch**: A unit of time that in network. One epoch is currently 6,646 blocks or approximately 1 day. + +- **Allocation**: An Indexer can allocate their total GRT stake (including Delegators' stake) towards subgraphs that have been published on The Graph's decentralized network. Allocations exist in one of four phases. + + 1. **Active**: An allocation is considered active when it is created on-chain. This is called opening an allocation, and indicates to the network that the Indexer is actively indexing and serving queries for a particular subgraph. Active allocations accrue indexing rewards proportional to the signal on the subgraph, and the amount of GRT allocated. + + 2. **Closed**: An Indexer may claim the accrued indexing rewards on a given subgraph by submitting a recent, and valid, Proof of Indexing (POI). This is known as closing an allocation. An allocation must have been open for a minimum of one epoch before it can be closed. The maximum allocation period is 28 epochs. If an indexer leaves an allocation open beyond 28 epochs, it is known as a stale allocation. When an allocation is in the **Closed** state, a fisherman can still open a dispute to challenge an Indexer for serving false data. + + 3. **Finalized**: The dispute period has ended, and query fee rebates are available to be claimed by Indexers. + + 4. **Claimed**: The final phase of an allocation, all eligible rewards have been distributed and its query fee rebates have been claimed. + +- **Subgraph Studio**: A powerful dapp for building, deploying, and publishing subgraphs. + +- **Fishermen**: Network participants may dispute Indexers' query responses and POIs. This is called being a Fisherman. A dispute resolved in the Fisherman’s favor results in a financial penalty for the Indexer, along with an award to the Fisherman, thus incentivizing the integrity of the indexing and query work performed by Indexers in the network. The penalty (slashing) is currently set at 2.5% of an Indexer's self stake, with 50% of the slashed GRT going to the Fisherman, and the other 50% being burned. + +- **Arbitrators**: Arbitrators are network participants set via govarnence. The role of the Arbitrator is to decide the outcome of indexing and query disputes. Their goal is to maximize the utility and reliability of The Graph Network. + +- **Slashing**: Indexers can have their staked GRT slashed for providing an incorrect proof of indexing (POI) or for serving inaccurate data. The slashing percentage is a protocol parameter currently set to 2.5% of an Indexer's self stake. 50% of the slashed GRT goes to the Fisherman that disputed the inaccurate data or incorrect POI. The other 50% is burned. + +- **Indexing Rewards**: The rewards that Indexers receive for indexing subgraphs. Indexing rewards are distributed in GRT. + +- **Delegation Rewards**: The rewards that Delegators receive for delegating GRT to Indexers. Delegation rewards are distributed in GRT. + +- **GRT**: The Graph's work utility token. GRT provides economic incentives to network participants for contributing to the network. + +- **POI or Proof of Indexing**: When an Indexer close their allocation and wants to claim their accrued indexer rewards on a given subgraph, they must provide a valid and recent Proof of Indexing (POI). Fishermen may dispute the POI provided by an Indexer. A dispute resolved in the Fisherman's favor will result in slashing of the Indexer. + +- **Graph Node**: Graph Node is the component which indexes subgraphs, and makes the resulting data available to query via a GraphQL API. As such it is central to the indexer stack, and correct operation of Graph Node is crucial to running a successful indexer. + +- **Indexer agent**: The Indexer agent is part of the indexer stack. It facilitates the Indexer's interactions on-chain, including registering on the network, managing subgraph deployments to its Graph Node(s), and managing allocations. + +- **The Graph Client**: A library for building GraphQL-based dapps in a decentralized way. + +- **Graph Explorer**: A dapp designed for network participants to explore subgraphs and interact with the protocol. + +- **Graph CLI**: A command line interface tool for building and deploying to The Graph. + +- **Cooldown Period**: The time remaining until an Indexer who changed their delegation parameters can do so again. diff --git a/website/pages/ar/graphcast.mdx b/website/pages/ar/graphcast.mdx new file mode 100644 index 000000000000..d1de65171b9a --- /dev/null +++ b/website/pages/ar/graphcast.mdx @@ -0,0 +1,21 @@ +--- +title: Graphcast +--- + +## مقدمة + +Is there something you'd like to learn from or share with your fellow Indexers in an automated manner, but it's too much hassle or costs too much gas? + +Currently, the cost to broadcast information to other network participants is determined by gas fees on the Ethereum blockchain. Graphcast solves this problem by acting as an optional decentralized, distributed peer-to-peer (P2P) communication tool that allows Indexers across the network to exchange information in real time. The cost of exchanging P2P messages is near zero, with the tradeoff of no data integrity guarantees. Nevertheless, Graphcast aims to provide message validity guarantees (i.e. that the message is valid and signed by a known protocol participant) with an open design space of reputation models. + +The Graphcast SDK (Software Development Kit) allows developers to build Radios, which are gossip-powered applications that Indexers can run to serve a given purpose. We also intend to create a few Radios (or provide support to other developers/teams that wish to build Radios) for the following use cases: + +- Real-time cross-checking of subgraph data integrity ([POI Radio](https://docs.graphops.xyz/graphcast/radios/poi-radio)). +- Conducting auctions and coordination for warp syncing subgraphs, substreams, and Firehose data from other Indexers. +- Self-reporting on active query analytics, including subgraph request volumes, fee volumes, etc. +- Self-reporting on indexing analytics, including subgraph indexing time, handler gas costs, indexing errors encountered, etc. +- Self-reporting on stack information including graph-node version, Postgres version, Ethereum client version, etc. + +### Learn More + +If you would like to learn more about Graphcast, [check out the documentation here.](https://docs.graphops.xyz/graphcast/intro) diff --git a/website/pages/ar/index.json b/website/pages/ar/index.json index d34ab87234e3..dcb5b59f7bb9 100644 --- a/website/pages/ar/index.json +++ b/website/pages/ar/index.json @@ -23,7 +23,7 @@ "description": "استخدم Studio لإنشاء subgraphs" }, "migrateFromHostedService": { - "title": "الانتقال من Hosted Service", + "title": "Migrate from the Hosted Service", "description": "ترحيل ال Subgraphs إلى شبكة TheGraph" } }, diff --git a/website/pages/ar/managing/deprecating-a-subgraph.mdx b/website/pages/ar/managing/deprecating-a-subgraph.mdx index 671957c99e20..f037fbcebe88 100644 --- a/website/pages/ar/managing/deprecating-a-subgraph.mdx +++ b/website/pages/ar/managing/deprecating-a-subgraph.mdx @@ -1,17 +1,18 @@ --- -title: إهمال Subgraph +title: إهمال الفرعيةرسم بياني --- -إن كنت ترغب في إهمال الـ subgraph الخاص بك في The Graph Explorer. فأنت في المكان المناسب! اتبع الخطوات أدناه: +إن كنت ترغب في إهمال الـ الفرعيةرسم بياني الخاص بك في مستكشف الرسم البياني. فأنت في المكان المناسب! اتبع الخطوات أدناه: 1. قم بزيارة عنوان العقد [ هنا ](https://etherscan.io/address/0xadca0dd4729c8ba3acf3e99f3a9f471ef37b6825#writeProxyContract) -2. استدعِ "devecateSubgraph" بعنوانك الخاص كأول بارامتر -3. في حقل "subgraphNumber" ، قم بإدراج 0 إذا كان أول subgraph تنشره ، 1 إذا كان الثاني ، 2 إذا كان الثالث ، إلخ. -4. يمكن العثور على مدخلات # 2 و # 3 في `` الخاص بك والذي يتكون من `{graphAccount}-{subgraphNumber}`. فمثلا، [Sushi Subgraph's](https://thegraph.com/explorer/subgraph?id=0x4bb4c1b0745ef7b4642feeccd0740dec417ca0a0-0&version=0x4bb4c1b0745ef7b4642feeccd0740dec417ca0a0-0-0&view=Overview) ID هو `<0x4bb4c1b0745ef7b4642feeccd0740dec417ca0a0-0>`,وهو مزيج من `graphAccount` = `<0x4bb4c1b0745ef7b4642feeccd0740dec417ca0a0>` و `subgraphNumber` = `<0>` -5. هاهو! لن يظهر الـ subgraph بعد الآن في عمليات البحث في The Graph Explorer. يرجى ملاحظة ما يلي: +2. Call `deprecateSubgraph` with your `SubgraphID` as your argument. +3. Voilà! Your subgraph will no longer show up on searches on The Graph Explorer. -- لن يتمكن المنسقون من الإشارة على الـ subgraph بعد الآن -- سيتمكن المنسقون الذين قد أشاروا على الـ subgraph من سحب إشاراتهم بمتوسط سعر السهم -- ستتم تحديد الـ subgraphs المهملة برسالة خطأ. +Please note the following: -إذا تفاعلت مع الـ subgraph المهمل ، فستتمكن من العثور عليه في ملف تعريف المستخدم الخاص بك ضمن علامة التبويب "Subgraphs" أو "Indexing" أو "Curating" على التوالي. +- The `deprecateSubgraph` function should be called by the owner's wallet. +- Curators will not be able to signal on the subgraph anymore. +- Curators that already signaled on the subgraph will be able to withdraw their signal at an average share price. +- ستتم تحديد الـ الفرعيةرسم بياني المهملة برسالة خطأ. + +If you interacted with the deprecated subgraph, you'll be able to find it in your user profile under the "Subgraphs", "Indexing", or "Curating" tab, respectively. diff --git a/website/pages/ar/managing/transferring-subgraph-ownership.mdx b/website/pages/ar/managing/transferring-subgraph-ownership.mdx index bc9bddaae9be..736042a38194 100644 --- a/website/pages/ar/managing/transferring-subgraph-ownership.mdx +++ b/website/pages/ar/managing/transferring-subgraph-ownership.mdx @@ -28,12 +28,12 @@ https://rainbow.me/your-wallet-addres To transfer ownership of a subgraph, you can use the UI built into Subgraph Studio: -![Subgraph Ownership Trasfer](/img/subgraph-ownership-transfer-1.png) +![Subgraph Ownership Transfer](/img/subgraph-ownership-transfer-1.png) -And then choosing the address that you would like to transfer the subgraph to: +And then choose the address that you would like to transfer the subgraph to: ![Subgraph Ownership Trasfer](/img/subgraph-ownership-transfer-2.png) -You can also use the built in UI of NFT marketplaces like OpenSea: +You can also use the built-in UI of NFT marketplaces like OpenSea: ![Subgraph Ownership Trasfer from NFT marketplace](/img/subgraph-ownership-transfer-nft-marketplace.png) diff --git a/website/pages/ar/mips-faqs.mdx b/website/pages/ar/mips-faqs.mdx new file mode 100644 index 000000000000..c1a1c8aa64b5 --- /dev/null +++ b/website/pages/ar/mips-faqs.mdx @@ -0,0 +1,125 @@ +--- +title: MIPs FAQs +--- + +## مقدمة + +It's an exciting time to be participating in The Graph ecosystem! During [Graph Day 2022](https://thegraph.com/graph-day/2022/) Yaniv Tal announced the [sunsetting of the hosted service](https://thegraph.com/blog/sunsetting-hosted-service/), a moment The Graph ecosystem has been working towards for many years. + +To support the sunsetting of the hosted service and the migration of all of it's activity to the decentralized network, The Graph Foundation has announced the [Migration Infrastructure Providers (MIPs) program](https://thegraph.com/blog/mips-multi-chain-indexing-incentivized-program). + +The MIPs program is an incentivization program for Indexers to support them with resources to index chains beyond Ethereum mainnet and help The Graph protocol expand the decentralized network into a multi-chain infrastructure layer. + +The MIPs program has allocated 0.75% of the GRT supply (75M GRT), with 0.5% to reward Indexers who contribute to bootstrapping the network and 0.25% allocated to migration grants for subgraph developers using multi-chain subgraphs. + +### Useful Resources + +- [Indexer 2ools from Vincent (Victor) Taglia](https://indexer-2ools.vincenttaglia.com/#/) +- [How to Become an Effective Indexer on The Graph Network](https://thegraph.com/blog/how-to-become-indexer/) +- [Indexer Knowledge Hub](https://thegraph.academy/indexers/) +- [Allocation Optimiser](https://github.com/graphprotocol/allocationopt.jl) +- [Allocation Optimization Tooling](https://github.com/anyblockanalytics/thegraph-allocation-optimization/) + +### 1. Is it possible to generate a valid proof of indexing (POI) even if a subgraph has failed? + +Yes, it is indeed. + +For context, the arbitration charter, [learn more about the charter here](https://hackmd.io/@4Ln8SAS4RX-505bIHZTeRw/BJcHzpHDu#Abstract), specifies the methodology for generating a POI for a failed subgraph. + +A community member, [SunTzu](https://github.com/suntzu93), has created a script to automate this process in compliance with the arbitration charter's methodology. Check out the repo [here](https://github.com/suntzu93/get_valid_poi_subgraph). + +### 2. Which chain will the MIPs program incentivise first? + +The first chain that will be supported on the decentralized network is Gnosis Chain! Formerly known as xDAI, Gnosis Chain is an EVM-based chain. Gnosis Chain was selected as the first given its user-friendliness of running nodes, Indexer readiness, alignment with The Graph and adoption within web3. + +### 3. How will new chains be added to the MIPs program? + +New chains will be announced throughout the MIPs program, based on Indexer readiness, demand, and community sentiment. Chains will firstly be supported on the testnet and, subsequently, a GIP will be passed to support that chain on mainnet. Indexers participating in the MIPs program will choose which chains they are interested in supporting and will earn rewards per chain, in addition to earning query fees and indexing rewards on the network for serving subgraphs. MIPs participants will be scored based on their performance, ability to serve network needs, and community support. + +### 4. How will we know when the network is ready for a new chain? + +The Graph Foundation will be monitoring QoS performance metrics, network performance and community channels to best assess readiness. The priority is ensuring the network meets performance needs for those multi-chain dapps to be able to migrate their subgraphs. + +### 5. How are rewards divided per chain? + +Given that chains vary in their requirements for syncing nodes, and they differ in query volume and adoption, rewards per chain will be decided at the end of that chain's cycle to ensure that all feedback and learnings are captured. However, at all times Indexers will also be able to earn query fees and indexing rewards once the chain is supported on the network. + +### 6. Do we need to index all the chains in the MIPs program or can we pick just one chain and index that? + +You are welcome to index whichever chain you'd like! The goal of the MIPs program is to equip Indexers with the tools & knowledge to index the chains they desire and support the web3 ecosystems they are interested in. However, for every chain, there are phases from testnet to mainnet. Make sure to complete all the phases for the chains you are indexing. See [The MIPs notion page](https://thegraphfoundation.notion.site/MIPs-Home-911e1187f1d94d12b247317265f81059) to learn more about the phases. + +### 7. When will rewards be distributed? + +MIPs rewards will be distributed per chain once performance metrics are met and migrated subgraphs are supported by those Indexers. Look out for info about the total rewards per chain mid-way through that chain's cycle. + +### 8. How does scoring work? + +Indexers will compete for rewards based on scoring throughout the program on the leaderboard. Program scoring will be based on: + +**Subgraph Coverage** + +- Are you providing maximal support for subgraphs per chain? + +- During MIPs, large Indexers are expected to stake 50%+ of subgraphs per chain they support. + +**Quality Of Service** + +- Is the Indexer serving the chain with good Quality of Service (latency, fresh data, uptime, etc.)? + +- Is the Indexer supporting dapp developers being reactive to their needs? + +Is Indexer allocating efficiently, contributing to the overall health of the network? + +**Community Support** + +- Is Indexer collaborating with fellow Indexers to help them get set up for multi-chain? + +- Is Indexer providing feedback to core devs throughout the program or sharing information with Indexers in the Forum? + +### 9. How will the Discord role be assigned? + +Moderators will assign the roles in the next few days. + +### 10. Is it okay to start the program on a testnet and then switch to Mainnet? Will you be able to identify my node and take it into account while distributing rewards? + +Yes, it is actually expected of you to do so. Several phases are on Görli and one is on the mainnet. + +### 11. At what point do you expect participants to add a mainnet deployment? + +There will be a requirement to have a mainnet indexer during phase 3. More infomation on this will be [shared in this notion page soon.](https://thegraphfoundation.notion.site/MIPs-Home-911e1187f1d94d12b247317265f81059) + +### 12. Will rewards be subject to vesting? + +The percentage to be distributed at the end of the program will be subject to vesting. More on this will be shared in the Indexer Agreement. + +### 13. For teams with more than one member, will all the team members be given a MIPs Discord role? + +Yes + +### 14. Is it possible to use the locked tokens from the graph curator program to participate in the MIPs testnet? + +Yes + +### 15. During the MIPs program, will there be a period to dispute invalid POI? + +To be decided. Please return to this page periodically for more details on this or if your request is urgent, please email info@thegraph.foundation + +### 17. Can we combine two vesting contracts? + +No. The options are: you can delegate one to the other one or run two separate indexers. + +### 18. KYC Questions? + +Please email info@thegraph.foundation + +### 19. I am not ready to index Gnosis chain, can I jump in and start indexing from another chain when I am ready? + +Yes + +### 20. Are there recommended regions to run the servers? + +We do not give recommendations on regions. When picking locations you might want to think about where the major markets are for cryptocurrencies. + +### 21. What is “handler gas cost”? + +It is the deterministic measure of the cost of executing a handler. Contrary to what the name might suggest, it is not related to the gas cost on blockchains. diff --git a/website/pages/ar/network-transition-faq.mdx b/website/pages/ar/network-transition-faq.mdx new file mode 100644 index 000000000000..4a10c49ad5be --- /dev/null +++ b/website/pages/ar/network-transition-faq.mdx @@ -0,0 +1,243 @@ +--- +title: Network Transition FAQ +--- + +Developers will have plenty of time to migrate their subgraphs to the decentralized network. Exact timelines will vary from network to network based on Indexer and network readiness-the hosted service will not end support for all networks at once and will not be sunset abruptly. + +Each network on the hosted service, including Ethereum, will sunset gradually as it is supported on the decentralized network to achieve feature parity and a high quality of service. This will happen on a network-to-network basis with help from Indexers in the [MIPs program](https://thegraph.com/blog/mips-multi-chain-indexing-incentivized-program/), to enable full support for each network on the decentralized network. + +To add more clarity around continued support for each network on the hosted service, these FAQs answer common questions regarding the specifics of the network transition process. If you would like to start the subgraph migration process now, here is a [step-by-step guide](https://thegraph.com/blog/how-to-migrate-ethereum-subgraph). To skip to the migration FAQ, [click here](#migration-faqs). + +## Hosted Service Sunset FAQs + +### Will I have to migrate my subgraph before the decentralized network serves core functionalities for subgraphs? + +Subgraph developers can begin migrating their Ethereum mainnet subgraphs now, but will not be forced to migrate subgraphs to the network before feature core functionality exists for the decentralized network and hosted service. Migration of Gnosis network subgraphs will also begin soon, with other networks to follow once Indexers have tested the networks and are ready to index them in production. + +### What is the timeline and process for deprecating the hosted service? + +All networks will have their own timelines, depending on when they are enabled on the network and the timeline it takes to get through each phase. Core developers are working to migrate the majority of hosted service traffic to the decentralized network as soon as possible. + +Most importantly, you will not lose access to the hosted service before core functionality is available for your specific network/subgraph on the decentralized network. + +The three distinct phases of hosted service deprecation for each network are: + +#### Phase 1 (The Sunray): Disable new subgraph creation for blockchains that have quality parity on the network + +In this stage, developers will no longer be able to deploy new subgraphs to the hosted service for that network. Developers will still be able to upgrade existing subgraphs on the hosted service. + +No network has yet begun Phase 1 of transitioning from the hosted service to the decentralized network. + +As networks enter Phase 1, please note that developers can still use the rate limited Developer Preview URL in the Subgraph Studio to develop and test their subgraphs (up to 1,000 free queries) without acquiring GRT or interacting with protocol economics. + +#### Phase 2 (The Sunbeam): Disable subgraph upgrades + +In this phase, upgrades to subgraphs must be made through Subgraph Studio and subsequently published to the decentralized network. Hosted service subgraphs for networks in this phase will still exist and will be queryable, but upgrades to subgraphs must be made on The Graph's decentralized network. + +There are no exact timelines for when any network will move to this phase, as the process is driven by exit criteria surrounding core functionality, not dates. + +#### Phase 3 (The Sunrise): Disable querying subgraphs + +At this phase, subgraphs on the hosted service for networks supported by The Graph Network will no longer process queries. The only way to query blockchain data for subgraphs on networks in this phase will be through the decentralized network. Test queries will still be available in [Subgraph Studio](https://thegraph.com/studio/) via the Development Query URL. + +Networks will not move to Phase 3 until successfully moving to Phase 2 and giving developers ample time to migrate to the decentralized network. + +![subgraph chart](/img/subgraph-chart.png) + +> Note: This diagram reflects the per-network sunsetting process. Hosted service sunsetting times will vary and will not sunset all at once. + +### What happens to test networks like Goerli, Mumbai, etc? + +All networks and test networks are eligible for a free Deployment Query URL in the [Subgraph Studio](https://thegraph.com/studio/). This URL is rate limited and intended for test and development traffic. Production traffic will require a subgraph published to The Graph Network in order to have production grade redundancy and stability. + +![Rate limit](/img/rate-limit.png) + +### Does The Graph Network have the same functionalities as the hosted service? + +Indexers on The Graph Network run the most recent network-approved [release of Graph Node](https://github.com/graphprotocol/graph-node/releases), and can support any subgraph features supported in that release. + +Sometimes unreleased features which are still under development might be available first on the Developer Preview URL, which runs the latest main commit of [Graph Node](https://github.com/graphprotocol/graph-node). These features will then become available on the network with the next Graph Node release. + +Certain subgraph features are not eligible for indexing rewards, if they are not deterministic or verifiable on the network. Specific examples are fetching files from IPFS, and indexing networks not yet supported on The Graph Network. + +Subgraphs with these features can be published to the network, but they may not be picked up by Indexers. However, subgraphs with sufficient signal may still attract Indexers interested in collecting query fees, which any subgraph is eligible for. + +### How much does The Graph Network cost in comparison to running my own infrastructure? + +The Graph's decentralized network is 60-90% less expensive than running dedicated infrastructure, as shown in [these case studies](https://thegraph.com/docs/en/network/benefits/#low-volume-user-less-than-30-000-queries-per-month). + +### Is there anything I should do with my hosted service subgraph after I migrate to the network? + +Hiding your hosted service subgraph is strongly recommended to avoid confusion. [This video](https://www.loom.com/share/7cffd2a7845e4fbd8c51f45c516cb7f9) walks through the process. + +### When will the decentralized network support my preferred network? + +There is no set timeline per network, they will be dictated by Indexer readiness via the [MIPs program](https://thegraph.com/migration-incentive-program/) where new networks are tested by Indexers. As new networks are supported on the network, users will receive ample notification to prepare for migration. Core devs and contributors to The Graph ecosystem are working to implement support for more networks as soon as possible. + +### Is Ethereum mainnet entering Phase 1 of the network transition process? + +While Ethereum was initially anticipated to begin transition off of the hosted service by the end of Q3 2022, this has been [postponed](https://thegraph.com/blog/transitioning-to-decentralized-graph-network) to address user feedback. Additional improvements to user experience, billing, and other fulfillments of user requests will drive Ethereum's hosted service transition timeline. Stay up to date on when Ethereum will enter The Sunray phase via the integration status tracker below and via [The Graph Twitter.](http://www.twitter.com/graphprotocol) + +### The Graph Network integration status tracker + +The table below illustrates where each network is in the network integration process. If your preferred network is not yet listed, integration has not yet begun, and that network is still fully supported by The Graph's hosted service. + +> This table will not include test networks, which remain free in [Subgraph Studio](https://thegraph.com/studio/). + +| الشبكة Network | Announcing integration on The Graph Network | Network Integration complete | Phase 1: disable new subgraphs on hosted service | Phase 2: disable subgraph upgrades on hosted service | Phase 3: disable subgraphs on hosted service | +| --- | :-: | :-: | :-: | :-: | :-: | +| Ethereum | ✓ | ✓ | | | | +| Gnosis (formerly xDAI) | ✓ | ✓\* | | | | +| بوليجون | ✓ | | | | | +| Celo | ✓ | ✓\* | | | | +| Arbitrum One | ✓ | ✓\* | | | | +| Avalanche | ✓ | ✓\* | | | | +| Optimism | ✓ | | | | | +| Fantom | ✓ | | | | | + +\* The network is currently in beta on The Graph's decentralized network. + +## Query Fees, API Keys, and Billing FAQs + +### How are query fees priced? + +Query fee prices are impacted by query demand on the decentralized network. Core developers created a query pricing cost model language called [Agora](https://github.com/graphprotocol/agora). It enables Indexers to price queries efficiently. Learn more in the [Agora documentation](https://github.com/graphprotocol/agora/blob/master/docs/README.md). + +### How can I set a maximum query budget? + +Users can set a max query budget in the Subgraph Studio [API Key](https://thegraph.com/studio/apikeys/) section, under the Budget tab. [Watch this video](https://www.loom.com/share/b5fc533e48584cb694017392c80c75e0) for an overview of that process, as well as adjusting other parts of your API Key. + +Please note that setting your max query budget too low will exclude Indexers, potentially leading to poor quality service in the form of failed queries, slow queries, etc. + +As of the end of September 2022, it's best practice to stay within the $0.00035-$0.0004 range as the lowest max query budget. + +### How can I protect my API Key? + +Users are encouraged to restrict the API key by both subgraph and domain in the [Subgraph Studio](https://thegraph.com/studio/): + +![Restrict domain](/img/restrictdomain.png) + +### How do I fill up my API key to pay for query fees? + +You can fill up your billing balance in the Subgraph Studio [Billing Dashboard](https://thegraph.com/studio/billing/) by pressing the "Add GRT" button. There is ongoing work to improve this experience to add more seamless and recurring payments. + +[This video](https://www.loom.com/share/a81de6ef11d64c62872ea210c58c6af5) has an overview of that process. + +### How do I set alerts for low billing balances in my API key? + +Users should set a billing alert to their email address [here](https://thegraph.com/studio/settings/). + +Also, a banner will flash within a user's UI to warn when a billing balance is getting low. + +What are the best practices for managing my API key settings? + +A max query budget of $0.0004 is recommended to maintain low average query prices while maintaining high quality of service. This can be done in the budget billing tab of the [API Key section](https://thegraph.com/studio/apikeys/). + +## Migration FAQs + +### How can I migrate my subgraph to The Graph's decentralized network? + +Learn how to migrate your subgraph to The Graph Network with this simple [step-by-step guide](https://thegraph.com/blog/how-to-migrate-ethereum-subgraph) or [this video](https://www.youtube.com/watch?v=syXwYEk-VnU&t=1s). + +### Are there migration grants for subgraphs that migrate early to The Graph Network? + +Yes. To apply for a grant, reach out [here](mailto:migration@thegraph.foundation). + +### Is there any financial/technical/marketing support through the migration process from The Graph ecosystem? + +There are migration grants for projects to use to curate subgraphs (to attract Indexers) and pay for initial query fees (apply [here](https://thegraph.typeform.com/to/Zz8UAPri?typeform-source=thegraph.com)), a [direct channel](http://thegraph.com/discord) to engineers to help every step of the way, and prioritized marketing campaigns to showcase your project after migration, exampled in these Twitter threads: [1](https://twitter.com/graphprotocol/status/1496891582401814537), [2](https://twitter.com/graphprotocol/status/1491926128302379008), & [3](https://twitter.com/graphprotocol/status/1491126245396201473). + +### How long do queries take? + +Queries take an average of 150-300 milliseconds on the decentralized network. + +### Is the billing process on The Graph Network more complex than on the hosted service? + +Yes, the UX for the network is not yet at quality parity with the hosted service. The billing UX, in particular, is still in very early stages and there are many moving parts that the core dev teams are working to abstract away from the process. Much of these improvements will be made public in the near future. + +### Can I pay for The Graph Network queries in fiat, credit card, or stablecoins? + +In the coming months, the number of steps that users need to take to pay for their subgraphs will be vastly reduced. While payments will still be made in GRT, efforts to implement a fiat on-ramp and automated payment systems to convert fiat and crypto into GRT to make recurring payments are already underway. + +### Will the network ever have the same UX as the hosted service? + +While there is still work to do, the aim is to offer comparable if not better quality UX on The Graph Network than currently exists on the hosted service. Short term, the aim is to offer a more streamlined and predictable billing experience that helps users focus more time building high-quality dapps. + +### How can I ensure that my subgraph will be picked up by Indexer on The Graph Network? + +It is recommended to curate with at least 10,000 GRT, which users can do in the same transaction as when they publish. Users can also ask the curation community to curate their subgraph [here](https://t.me/CurationStation). + +There are migration grants for the early migrants to cover these initial costs. Feel free to apply [here](mailto:migration@thegraph.foundation). + +### Why does a subgraph need curation signal? What if there isn't enough signal on my subgraph from curators? + +The higher the curation signal, the more attractive a subgraph is to Indexers, as there is a linear correlation between higher signal and higher indexing rewards. Without curation, there is no incentive for Indexers to pick up a subgraph. + +### What happens to the GRT a subgraph developer uses for curation signal? + +If you are the first to signal a subgraph, your GRT signaled amount will not go down. GRT used for curation can be removed later. Also, Curators get 10% of all query fees taken in by Indexers. + +### What improvements are coming to the curation process? + +Short term, the initial curation model on Arbitrum will provide principle-protection to curation signal. Longer term, the core devs will prioritize offering developers the capacity to rent curation signal, opening up a more predictable pricing experience while still ensuring subgraphs are sufficiently indexed. + +### How do I switch the subgraph API in the front-end? + +After at least one Indexer has fully indexed a subgraph, a user can query the decentralized network. + +In order to retrieve the query URL for your subgraph, you can copy/paste it by clicking on the symbol next to the query URL. You will see something like this: + +`https://gateway.thegraph.com/api/[api-key]/subgraphs/id/S9ihna8D733WTEShJ1KctSTCvY1VJ7gdVwhUujq4Ejo` + +Simply replace [api-key] with an API key generated in the Subgraph Studio [API Key section](https://thegraph.com/studio/apikeys/). + +### How much do queries cost? + +The average query cost within the network varies. For the month of September 2022, the average price per query fee cost ranged from $0.00012 - $0.00020. + +### How can I find out how much volume my subgraph has and how much it will cost? + +Hosted service volume data is not public. Please reach out to get volume and cost estimates [here](mailto:migration@thegraph.foundation). + +### How does the gateway work? Is it fully decentralized? + +The gateway process queries so Indexers can serve dapps. The gateways are in an intermediate phase that is being progressively decentralized. More on this soon. + +## Using The Network FAQs + +### Is there a cost to upgrade my subgraph? + +Yes, it is 1% of curation signaled. The 1% is split evenly between Curators (0.5%) and subgraph developers (0.5%). So, for every 10K GRT signaled, it costs subgraph developers 50 GRT to upgrade. + +### How do I speed up sync time? + +Minimize the use of smart contract calls within the subgraph. Accessing a smart contract state requires an eth_call to the RPC, which slows down sync times. + +### Is there multisig support in Subgraph Studio as I migrate? + +Yes, multisig support has recently been added. You can find more information [here](https://thegraph.com/docs/studio/multisig). + +### ما هي عناوين عقود عملة القراف على إيثيريوم و أربترم؟ + +- Ethereum: `0xc944E90C64B2c07662A292be6244BDf05Cda44a7` +- أربترم: `0x9623063377AD1B27544C965cCd7342f7EA7e88C7` + +### How much GRT do projects usually keep in their API Key? + +Many projects keep 30-60 days worth of GRT in their API key, so they don't need to refill often. To understand what your 30-60 day GRT fees would be, please reach out [here](mailto:migration@thegraph.foundation). + +### How are query payments made on the decentralized network?  + +الرسوم يتم فوترتها أسبوعياً وتسحب من مفتاح واجهة تطبيق البرمجة الخاص بالمستخدم, بعملة القراف المجسرة إلى أربترم وتستقر هناك. + +### How are API keys used for subgraphs on the decentralized network? + +API Keys empower users to have a say in both the max query prices they pay and to prioritize factors like price, economic freshness, and query speed. + +### How does quality of service currently compare between the hosted service and the decentralized network? + +The hosted service and decentralized network have about the same median latency, but the decentralized network tends to have higher latency at higher percentiles. 200 rates for queries are generally similar, with both > 99.9%. As a result of its decentralization, the network has not had a broad outage across subgraphs, whereas the hosted service does on rare occasions have temporary outages as a result of its centralized nature. + +### What if my question isn't answered by these FAQs? + +Please reach out to [migration@thegraph.foundation](mailto:migration@thegraph.foundation) for any additional assistance. diff --git a/website/pages/ar/network/benefits.mdx b/website/pages/ar/network/benefits.mdx new file mode 100644 index 000000000000..3be10edc4e03 --- /dev/null +++ b/website/pages/ar/network/benefits.mdx @@ -0,0 +1,94 @@ +--- +title: The Graph Network vs. Self Hosting +socialImage: https://thegraph.com/docs/img/seo/benefits.jpg +--- + +The Graph’s decentralized network has been engineered and refined to create a robust indexing and querying experience—and it’s getting better every day thanks to thousands of contributors around the world. + +The benefits of this decentralized protocol cannot be replicated by running a `graph-node` locally. The Graph Network is more reliable, more efficient, and less expensive. + +Here is an analysis: + +## Why You Should Use The Graph Network + +- 60-98% lower monthly cost +- $0 infrastructure setup costs +- Superior uptime +- Access to 438 Indexers (and counting) +- 24/7 technical support by global community + +## The Benefits Explained + +### Lower & more Flexible Cost Structure + +No contracts. No monthly fees. Only pay for the queries you use—with an average cost-per-query of $0.0002. Queries are priced in USD and paid in GRT. + +Query costs may vary; the quoted cost is the average at time of publication (December 2022). + +## Low Volume User (less than 30,000 queries per month) + +| Cost Comparison | Self Hosted | Graph Network | +| :-: | :-: | :-: | +| Monthly server cost\* | $350 per month | $0 | +| Query costs | $0+ | ~$15 per month | +| Engineering time† | $400 per month | None, built into the network with globally distributed Indexers | +| Queries per month | Limited to infra capabilities | 30,000 (autoscaling) | +| Cost per query | $0 | $0.0005‡ | +| البنية الأساسية | Centralized | Decentralized | +| Geographic redundancy | $750+ per additional node | Included | +| Uptime | Varies | 99.9%+ | +| Total Monthly Costs | $750+ | ~$15 | + +## Medium Volume User (3,000,000+ queries per month) + +| Cost Comparison | Self Hosted | Graph Network | +| :-: | :-: | :-: | +| Monthly server cost\* | $350 per month | $0 | +| Query costs | $500 per month | $750 per month | +| Engineering time† | $800 per month | None, built into the network with globally distributed Indexers | +| Queries per month | Limited to infra capabilities | 3,000,000+ | +| Cost per query | $0 | $0.00025‡ | +| البنية الأساسية | Centralized | Decentralized | +| Engineering expense | $200 per hour | Included | +| Geographic redundancy | $1,200 in total costs per additional node | Included | +| Uptime | Varies | 99.9%+ | +| Total Monthly Costs | $1,650+ | $750 | + +## High Volume User (30,000,000+ queries per month) + +| Cost Comparison | Self Hosted | Graph Network | +| :-: | :-: | :-: | +| Monthly server cost\* | $1100 per month, per node | $0 | +| Query costs | $4000 | $4,500 per month | +| Number of nodes needed | 10 | Not applicable | +| Engineering time† | $6,000 or more per month | None, built into the network with globally distributed Indexers | +| Queries per month | Limited to infra capabilities | 30,000,000+ | +| Cost per query | $0 | $0.00015‡ | +| البنية الأساسية | Centralized | Decentralized | +| Geographic redundancy | $1,200 in total costs per additional node | Included | +| Uptime | Varies | 99.9%+ | +| Total Monthly Costs | $11,000+ | $4,500 | + +\*including costs for backup: $50-$100 per month + +†Engineering time based on $200 per hour assumption + +‡using the max query budget function in the budget billing tab, while maintaining high quality of service + +Estimated costs are only for Ethereum Mainnet subgraphs — costs are even higher when self hosting a `graph-node` on other networks. + +Curating signal on a subgraph is an optional one-time, net-zero cost (e.g., $1k in signal can be curated on a subgraph, and later withdrawn—with potential to earn returns in the process). + +Some users may need to upgrade subgraphs. Due to Ethereum gas fees, upgrades cost ~$50 per upgrade at time of this writing. + +## No Setup Costs & Greater Operational Efficiency + +Zero setup fees. Get started immediately with no setup or overhead costs. No hardware requirements. No outages due to centralized infrastructure, and more time to concentrate on your core product . No need for backup servers, troubleshooting, or expensive engineering resources. + +## Reliability & Resiliency + +The Graph’s decentralized network gives users access to geographic redundancy that does not exist when self-hosting a `graph-node`. Queries are served reliably thanks to 99.9%+ uptime, achieved by 168 Indexers (and counting) securing the network globally. + +Bottom line: The Graph Network is less expensive, easier to use, and produces superior results compared to running a `graph-node` locally. + +Start using The Graph Network today, and learn how to [migrate or deploy your subgraph](https://thegraph.com/blog/how-to-migrate-ethereum-subgraph). diff --git a/website/pages/ar/network/curating.mdx b/website/pages/ar/network/curating.mdx index bb518e177d45..1e5b2979927e 100644 --- a/website/pages/ar/network/curating.mdx +++ b/website/pages/ar/network/curating.mdx @@ -1,16 +1,16 @@ --- -title: (التنسيق) curating +title: Curating --- -المنسقون مهمون للاقتصاد اللامركزي في the Graph. يستخدمون معرفتهم بالنظام البيئي web3 للتقييم والإشارة ل Subgraphs والتي تفهرس بواسطة شبكة The Graph. من خلال المستكشف (Explorer)، يستطيع المنسقون (curators) عرض بيانات الشبكة وذلك لاتخاذ قرارات الإشارة. تقوم شبكة The Graph بمكافئة المنسقين الذين يشيرون إلى ال Subgraphs عالية الجودة بحصة من رسوم الاستعلام التي تولدها ال subgraphs. يتم تحفيز المنسقون(Curators) ليقومون بالإشارة بشكل مبكر. هذه الإشارات من المنسقين مهمة للمفهرسين ، والذين يمكنهم بعد ذلك معالجة أو فهرسة البيانات من ال subgraphs المشار إليها. +Curators are critical to the Graph decentralized economy. They use their knowledge of the web3 ecosystem to assess and signal on the subgraphs that should be indexed by The Graph Network. Through the Explorer, curators are able to view network data to make signaling decisions. The Graph Network rewards curators who signal on good quality subgraphs with a share of the query fees that subgraphs generate. Curators are economically incentivized to signal early. These cues from curators are important for Indexers, who can then process or index the data from these signaled subgraphs. -يمكن للمنسقين اتخاذ القرار إما بالإشارة إلى إصدار معين من Subgraphs أو الإشارة باستخدام الترحيل التلقائي auto-migrate. عند الإشارة باستخدام الترحيل التلقائي ، ستتم دائما ترقية حصص المنسق إلى أحدث إصدار ينشره المطور. وإذا قررت الإشارة إلى إصدار معين، فستظل الحصص دائما في هذا الإصدار المحدد. +يمكن للمنسقين اتخاذ القرار إما بالإشارة إلى إصدار معين من الفرعيةرسم بياني أو الإشارة باستخدام الترحيل التلقائي الترحيل التلقائي. عند الإشارة باستخدام الترحيل التلقائي ، ستتم دائما ترقية حصص المنسق إلى أحدث إصدار ينشره المطور. وإذا قررت الإشارة إلى إصدار معين، فستظل الحصص دائما في هذا الإصدار المحدد. -تذكر أن عملية التنسيق محفوفة بالمخاطر. نتمنى أن تبذل قصارى جهدك وذلك لتنسق ال Subgraphs الموثوقة. إنشاء ال subgraphs لا يحتاج إلى ترخيص، لذلك يمكن للأشخاص إنشاء subgraphs وتسميتها بأي اسم يرغبون فيه. لمزيد من الإرشادات حول مخاطر التنسيق ، تحقق من[The Graph Academy's Curation Guide.](https://thegraph.academy/curators/) +تذكر أن عملية التنسيق محفوفة بالمخاطر. نتمنى أن تبذل قصارى جهدك وذلك لتنسق ال الفرعيةرسم بياني الموثوقة. إنشاء ال الفرعيةرسم بياني لا يحتاج إلى ترخيص، لذلك يمكن للأشخاص إنشاء الفرعيةرسم بياني وتسميتها بأي اسم يرغبون فيه. لمزيد من الإرشادات حول مخاطر التنسيق ، تحقق من[دليل Curation أكاديمية رسم بياني.](https://thegraph.academy/curators/) ## منحنى الترابط 101 -أولا لنعد خطوة إلى الوراء. يحتوي كل subgraphs على منحنى ربط يتم فيه صك حصص التنسيق ، وذلك عندما يضيف المستخدم إشارة **للمنحنى**. لكل Subgraphs منحنى ترابط فريد من نوعه. يتم تصميم منحنيات الترابط بحيث يزداد بشكل ثابت سعر صك حصة التنسيق على Subgraphs ، وذلك مقارنة بعدد الحصص التي تم صكها. +First, we take a step back. Each subgraph has a bonding curve on which curation shares are minted when a user adds signal **into** the curve. Each subgraph’s bonding curve is unique. The bonding curves are architected so that the price to mint a curation share on a subgraph increases linearly, over the number of shares minted. ![سعر السهم](/img/price-per-share.png) @@ -18,78 +18,78 @@ title: (التنسيق) curating ![منحنى الترابط Bonding curve](/img/bonding-curve.png) -ضع في اعتبارك أن لدينا منسقان يشتركان في Subgraph واحد: +ضع في اعتبارك أن لدينا منسقان يشتركان في الفرعيةرسم بياني واحد: -- المنسق (أ) هو أول من أشار إلى ال Subgraphs. من خلال إضافة 120000 GRT إلى المنحنى ، سيكون من الممكن صك 2000 سهم. -- تظهر إشارة المنسق "ب" على ال Subgraph لاحقا. للحصول على نفس كمية حصص المنسق "أ" ، يجب إضافة 360000 GRT للمنحنى. +- المنسق A هو أول من أشار إلى ال الفرعيةرسم بياني. من خلال إضافة 120000 GRT إلى المنحنى ، سيكون من الممكن صك 2000 سهم. +- تظهر إشارة المنسق "ب" على ال الفرعيةرسم بياني لاحقا. للحصول على نفس كمية حصص المنسق "أ" ، يجب إضافة 360000 GRT للمنحنى. - لأن كلا من المنسقين يحتفظان بنصف إجمالي اسهم التنسيق ، فإنهم سيحصلان على قدر متساوي من عوائد المنسقين. - إذا قام أي من المنسقين بحرق 2000 من حصص التنسيق الخاصة بهم ،فإنهم سيحصلون على 360000 GRT. -- سيحصل المنسق المتبقي على جميع عوائد المنسق لهذ ال subgraphs. وإذا قام بحرق حصته للحصول علىGRT ، فإنه سيحصل على 120.000 GRT. -- ** TLDR: ** يكون تقييم أسهم تنسيق GRT من خلال منحنى الترابط ويمكن أن يكون متقلبا. هناك إمكانية لتكبد خسائر كبيرة. الإشارة في وقت مبكر يعني أنك تضع كمية أقل من GRT لكل سهم. هذا يعني أنك تكسب من عائدات المنسق لكل GRT أكثر من المنسقين المتأخرين لنفس ال subgraph. +- سيحصل المنسق المتبقي على جميع عوائد المنسق لهذ ال الفرعيةرسم بياني. وإذا قام بحرق حصته للحصول علىGRT ، فإنه سيحصل على 120.000 GRT. +- **TLDR:** The GRT valuation of curation shares is determined by the bonding curve and can be volatile. There is potential to incur big losses. Signaling early means you put in less GRT for each share. By extension, this means you earn more curator royalties per GRT than later curators for the same subgraph. -بشكل عام ، منحنى الترابط هو منحنى رياضي يحدد العلاقة بين عرض التوكن وسعر الأصول. في الحالة المحددة لتنسيق ال subgraph ، ** يرتفع سعر كل سهم في ال subgraph مع كل توكن مستثمر ** ويقل السعر \*\* لكل سهم مع كل بيع للتوكن. +بشكل عام ، منحنى الترابط هو منحنى رياضي يحدد العلاقة بين عرض التوكن وسعر الأصول. في الحالة المحددة لتنسيق ال الفرعيةرسم بياني ، ** يرتفع سعر كل سهم في ال الفرعيةرسم بياني مع كل توكن مستثمر ** ويقل السعر ** لكل سهم مع كل بيع للتوكن.** -في حالة The Graph +في حالة الرسم البياني ، [ تنفيذ Bancor لصيغة منحنى الترابط ](https://drive.google.com/file/d/0B3HPNP-GDn7aRkVaV3dkVl9NS2M/view?resourcekey=0-mbIgrdd0B9H8dPNRaeB_TA) يتم رفعه. ## كيفية الإشارة -الآن بعد أن غطينا الأساسيات حول كيفية عمل منحنى الترابط ،طريقة الإشارة على ال subgraph هي كالتالي. ضمن علامة التبويب "Curator" في "Graph Explorer" ، سيتمكن المنسقون من الإشارة وإلغاء الإشارة إلى بعض ال subgraphs بناء على إحصائيات الشبكة. للحصول على نظرة عامة خطوة بخطوة حول كيفية القيام بذلك في Explorer ،[انقر هنا](/network/explorer) +Now that we’ve covered the basics about how the bonding curve works, this is how you will proceed to signal on a subgraph. Within the Curator tab on the Graph Explorer, curators will be able to signal and unsignal on certain subgraphs based on network stats. For a step-by-step overview of how to do this in the Explorer, [click here.](/network/explorer) -يمكن للمنسق الإشارة إلى إصدار معين ل subgraph ، أو يمكنه اختيار أن يتم ترحيل migrate إشاراتهم تلقائيا إلى أحدث إصدار لهذا ال subgraph. كلاهما استراتيجيات سليمة ولها إيجابيات وسلبيات. +يمكن للمنسق الإشارة إلى إصدار معين ل الفرعيةرسم بياني ، أو يمكنه اختيار أن يتم ترحيل يهاجر إشاراتهم تلقائيا إلى أحدث إصدار لهذا ال الفرعيةرسم بياني. كلاهما استراتيجيات سليمة ولها إيجابيات وسلبيات. -الإشارة إلى إصدار معين مفيدة بشكل خاص عند استخدام subgraph واحد بواسطة عدة dapps. قد يحتاج ال dapp إلى تحديث ال subgraph بانتظام بميزات جديدة. وقد يفضل dapp آخر استخدام إصدار subgraph أقدم تم اختباره جيدا. عند بداية التنسيق ، يتم فرض ضريبة بنسبة 1٪. +Signaling on a specific version is especially useful when one subgraph is used by multiple dApps. One dApp might need to regularly update the subgraph with new features. Another dApp might prefer to use an older, well-tested subgraph version. Upon initial curation, a 1% standard tax is incurred. -يمكن أن يكون ترحيل migration الإشارة تلقائيا إلى أحدث إصدار أمرا ذا قيمة لضمان استمرار تراكم رسوم الاستعلام. في كل مرة تقوم فيها بالتنسيق ، يتم فرض ضريبة تنسيق بنسبة 1٪. ستدفع أيضًا ضريبة تنسيق 0.5٪ على كل ترحيل. لا يُنصح مطورو ال Subgraph بنشر إصدارات جديدة بشكل متكرر - يتعين عليهم دفع ضريبة تنسيق بنسبة 0.5٪ على جميع أسهم التنسيق المرحلة تلقائيًا. +Having your signal automatically migrate to the newest production build can be valuable to ensure you keep accruing query fees. Every time you curate, a 1% curation tax is incurred. You will also pay a 0.5% curation tax on every migration. Subgraph developers are discouraged from frequently publishing new versions - they have to pay a 0.5% curation tax on all auto-migrated curation shares. -> ** ملاحظة **: العنوان الأول الذي يشير ل subgraph معين يعتبر هو المنسق الأول وسيتعين عليه القيام بأعمال gas أكثر بكثير من بقية المنسقين التاليين لأن المنسق الأول يهيئ توكن أسهم التنسيق، ويهيئ منحنى الترابط ، وكذلك ينقل التوكن إلى the Graph proxy. +> ** ملاحظة **: العنوان الأول الذي يشير ل الفرعيةرسم بياني معين يعتبر هو المنسق الأول وسيتعين عليه القيام بأعمال gas أكثر بكثير من بقية المنسقين التاليين لأن المنسق الأول يهيئ توكن أسهم التنسيق، ويهيئ منحنى الترابط ، وكذلك ينقل التوكن إلى رسم بياني proxy. -## ماذا تعني الإشارة لشبكة The Graph؟ +## ماذا تعني الإشارة لشبكة رسم بياني؟ -لكي يتمكن المستهلك من الاستعلام عن subgraph ، يجب أولا فهرسة ال subgraph. الفهرسة هي عملية يتم فيها النظر إلى الملفات، والبيانات، والبيانات الوصفية وفهرستها بحيث يمكن العثور على النتائج بشكل أسرع. يجب تنظيم بيانات ال subgraph لتكون قابلة للبحث فيها. +لكي يتمكن المستهلك من الاستعلام عن الفرعيةرسم بياني ، يجب أولا فهرسة ال الفرعيةرسم بياني. الفهرسة هي عملية يتم فيها النظر إلى الملفات، والبيانات، والبيانات الوصفية وفهرستها بحيث يمكن العثور على النتائج بشكل أسرع. يجب تنظيم بيانات ال الفرعيةرسم بياني لتكون قابلة للبحث فيها. -وبالتالي ، إذا قام المفهرسون بتخمين ال subgraphs التي يجب عليهم فهرستها ، فستكون هناك فرصة منخفضة في أن يكسبوا رسوم استعلام جيدة لأنه لن يكون لديهم طريقة للتحقق من ال subgraphs ذات الجودة العالية. أدخل التنسيق. +وبالتالي ، إذا قام المفهرسون بتخمين ال الفرعيةرسم بياني التي يجب عليهم فهرستها ، فستكون هناك فرصة منخفضة في أن يكسبوا رسوم استعلام جيدة لأنه لن يكون لديهم طريقة للتحقق من ال الفرعيةرسم بياني ذات الجودة العالية. أدخل التنسيق. -المنسقون بجعلون شبكة The Graph فعالة، والتأشير signaling هي العملية التي يستخدمها المنسقون لإعلام المفهرسين بأن ال subgraph جيدة للفهرسة ، حيث تتم إضافة GRT إلى منحنى الترابط ل subgraph. يمكن للمفهرسين أن يثقوا بإشارة المنسق لأنه عند الإشارة ، يقوم المنسقون بصك سهم تنسيق ال subgraph ، مما يمنحهم حق الحصول على جزء من رسوم الاستعلام المستقبلية التي ينشئها ال subgraph. إشارة المنسق يتم تمثيلها كتوكن ERC20 والتي تسمى (Graph Curation Shares (GCS. المنسقين الراغبين في كسب المزيد من رسوم الاستعلام عليهم إرسال الإشارة بـGRT إلى الـ subgraphs التي يتوقعون أنها ستولد تدفقا قويا للرسوم للشبكة.هناك ضريبة ودائع على المنسقين لتثبيط اتخاذ قرار يمكن أن يضر بسلامة الشبكة. يكسب المنسقون أيضا رسوم استعلام أقل إذا اختاروا التنسيق على subgraph منخفض الجودة ، حيث سيكون هناك عددا أقل من الاستعلامات لمعالجتها أو عددا أقل من المفهرسين لمعالجة هذه الاستعلامات. انظر إلى الرسم البياني أدناه! +Curators make The Graph network efficient and signaling is the process that curators use to let Indexers know that a subgraph is good to index, where GRT is added to a bonding curve for a subgraph. Indexers can inherently trust the signal from a curator because upon signaling, curators mint a curation share for the subgraph, entitling them to a portion of future query fees that the subgraph drives. Curator signal is represented as ERC20 tokens called Graph Curation Shares (GCS). Curators that want to earn more query fees should signal their GRT to subgraphs that they predict will generate a strong flow of fees to the network. Curators cannot be slashed for bad behavior, but there is a deposit tax on Curators to disincentivize poor decision-making that could harm the integrity of the network. Curators also earn fewer query fees if they choose to curate on a low-quality Subgraph since there will be fewer queries to process or fewer Indexers to process those queries. See the diagram below! -![مخطط التأشير Signaling diagram](/img/curator-signaling.png) +![مخطط التأشير مخطط الإشارات](/img/curator-signaling.png) -يمكن للمفهرسين العثور على subgraphs لفهرستها وذلك بناء على إشارات التنسيق التي يرونها في The Graph Explorer (لقطة الشاشة أدناه). +يمكن للمفهرسين العثور على الفرعيةرسم بياني لفهرستها وذلك بناء على إشارات التنسيق التي يرونها في مستكشف الرسم البياني (لقطة الشاشة أدناه). -![مستكشف subgraphs](/img/explorer-subgraphs.png) +![مستكشف الفرعيةرسم بياني](/img/explorer-subgraphs.png) ## المخاطر -1. سوق الاستعلام يعتبر حديثا في The Graph وهناك خطر من أن يكون٪ APY الخاص بك أقل مما تتوقع بسبب ديناميكيات السوق الناشئة. -2. رسوم التنسيق - عندما يشير المنسق إلى GRT على subgraph ، فإنه يتحمل ضريبة تنسيق بنسبة 1٪. يتم حرق هذه الرسوم ويودع الباقي في العرض الاحتياطي لمنحنى الترابط. -3. عندما يحرق المنسقون أسهمهم لسحب GRT ، سينخفض تقييم GRT للأسهم المتبقية. كن على علم بأنه في بعض الحالات ، قد يقرر المنسقون حرق أسهمهم ** كلها مرة واحدة **. قد تكون هذه الحالة شائعة إذا توقف مطور dapp عن الاصدار/ التحسين والاستعلام عن ال subgraph الخاص به أو في حالة فشل ال subgraph. نتيجة لذلك ، قد يتمكن المنسقون المتبقون فقط من سحب جزء من GRT الأولية الخاصة بهم. لدور الشبكة بمخاطر أقل انظر\[Delegators\](/delegating). -4. يمكن أن يفشل ال subgraph بسبب خطأ. ال subgraph الفاشل لا يمكنه إنشاء رسوم استعلام. نتيجة لذلك ، سيتعين عليك الانتظار حتى يصلح المطور الخطأ وينشر إصدارا جديدا. - - إذا كنت مشتركا في أحدث إصدار من subgraph ، فسيتم ترحيل migrate أسهمك تلقائيا إلى هذا الإصدار الجديد. هذا سيتحمل ضريبة تنسيق بنسبة 0.5٪. - - إذا أشرت إلى إصدار معين من subgraph وفشل ، فسيتعين عليك حرق أسهم التنسق الخاصة بك يدويا. لاحظ أنك قد تتلقى GRT أكثر أو أقل مما أودعته في البداية في منحنى التنسيق، وهي مخاطرة مرتبطة بكونك منسقا. You can then signal on the new subgraph version, thus incurring a 1% curation tax. +1. سوق الاستعلام يعتبر حديثا في رسم بياني وهناك خطر من أن يكون٪ APY الخاص بك أقل مما تتوقع بسبب ديناميكيات السوق الناشئة. +2. رسوم التنسيق - عندما يشير المنسق إلى GRT على الفرعيةرسم بياني ، فإنه يتحمل ضريبة تنسيق بنسبة 1٪. يتم حرق هذه الرسوم ويودع الباقي في العرض الاحتياطي لمنحنى الترابط. +3. When curators burn their shares to withdraw GRT, the GRT valuation of the remaining shares will be reduced. Be aware that in some cases, curators may decide to burn their shares **all at once**. This situation may be common if a dApp developer stops versioning/improving and querying their subgraph or if a subgraph fails. As a result, remaining curators might only be able to withdraw a fraction of their initial GRT. For a network role with a lower risk profile, see [Delegators](/network/delegating). +4. يمكن أن يفشل ال الفرعيةرسم بياني بسبب خطأ. ال الفرعيةرسم بياني الفاشل لا يمكنه إنشاء رسوم استعلام. نتيجة لذلك ، سيتعين عليك الانتظار حتى يصلح المطور الخطأ وينشر إصدارا جديدا. + - إذا كنت مشتركا في أحدث إصدار من الفرعيةرسم بياني ، فسيتم ترحيل يهاجر أسهمك تلقائيا إلى هذا الإصدار الجديد. هذا سيتحمل ضريبة تنسيق بنسبة 0.5٪. + - If you have signaled on a specific subgraph version and it fails, you will have to manually burn your curation shares. Note that you may receive more or less GRT than you initially deposited into the curation curve, which is a risk associated with being a curator. You can then signal on the new subgraph version, thus incurring a 1% curation tax. ## الأسئلة الشائعة حول التنسيق ### 1. ما هي النسبة المئوية لرسوم الاستعلام التي يكسبها المنسقون؟ -من خلال الإشارة لل subgraph ، سوف تكسب حصة من جميع رسوم الاستعلام التي يولدها هذا ال subgraph. تذهب 10٪ من جميع رسوم الاستعلام إلى المنسقين بالتناسب مع أسهم التنسيق الخاصة بهم. هذه الـ 10٪ خاضعة للقوانين. +By signalling on a subgraph, you will earn a share of all the query fees that this subgraph generates. 10% of all query fees goes to the Curators pro-rata to their curation shares. This 10% is subject to governance. -### 2. كيف يمكنني تقرير ما إذا كان ال subgraph عالي الجودة لكي أقوم بالإشارة إليه؟ +### 2. كيف يمكنني تقرير ما إذا كان ال الفرعيةرسم بياني عالي الجودة لكي أقوم بالإشارة إليه؟ -يعد العثور على ال subgraphs عالية الجودة مهمة معقدة ، ولكن يمكن التعامل معها بعدة طرق مختلفة. بصفتك منسقا، فأنت تريد البحث عن ال subgraphs الموثوقة والتي تؤدي إلى زيادة حجم الاستعلام. ال subgraph الجدير بالثقة يكون ذا قيمة إذا كان مكتملا ودقيقا ويدعم احتياجات بيانات ال dapp. قد يحتاج ال subgraph الذي تم تكوينه بشكل سيئ إلى المراجعة أو إعادة النشر ، وقد ينتهي به الأمر أيضًا إلى الفشل. من المهم للمنسقين القيام بمراجعة بنية أو كود ال subgraph من أجل تقييم ما إذا كان ال subgraph ذو قيمة أم لا. كنتيجة ل: +Finding high-quality subgraphs is a complex task, but it can be approached in many different ways. As a Curator, you want to look for trustworthy subgraphs that are driving query volume. A trustworthy subgraph may be valuable if it is complete, accurate, and supports a dApp’s data needs. A poorly architected subgraph might need to be revised or re-published, and can also end up failing. It is critical for Curators to review a subgraph’s architecture or code in order to assess if a subgraph is valuable. As a result: -- يمكن للمنسقين استخدام فهمهم للشبكة لمحاولة التنبؤ كيف لل subgraph أن يولد حجم استعلام أعلى أو أقل في المستقبل -- يجب أن يفهم المنسقون أيضا المقاييس المتوفرة من خلال the Graph Explorer. المقاييس مثل حجم الاستعلام السابق ومن هو مطور ال subgraph تساعد في تحديد ما إذا كان ال subgraph يستحق الإشارة إليه أم لا. +- يمكن للمنسقين استخدام فهمهم للشبكة لمحاولة التنبؤ كيف لل الفرعيةرسم بياني أن يولد حجم استعلام أعلى أو أقل في المستقبل +- Curators should also understand the metrics that are available through The Graph Explorer. Metrics like past query volume and who the subgraph developer is can help determine whether or not a subgraph is worth signalling on. -### 3. ما هي تكلفة ترقية ال subgraph؟ +### 3. ما هي تكلفة ترقية ال الفرعيةرسم بياني؟ -ترحيل أسهم التنسيق الخاصة بك إلى إصدار subgraph جديد يؤدي إلى فرض ضريبة تنسيق بنسبة 1٪. يمكن للمنسقين الاشتراك في أحدث إصدار من ال subgraph. عندما يتم ترحيل أسهم المنسقين تلقائيا إلى إصدار جديد ، سيدفع المنسقون أيضا نصف ضريبة التنسيق ، أي. 0.5٪ ، لأن ترقية ال subgraphs هي إجراء متسلسل يكلف غاز gas. +Migrating your curation shares to a new subgraph version incurs a curation tax of 1%. Curators can choose to subscribe to the newest version of a subgraph. When curator shares get auto-migrated to a new version, Curators will also pay half curation tax, ie. 0.5%, because upgrading subgraphs is an on-chain action that costs gas. -### 4. كم مرة يمكنني ترقية ال subgraph الخاص بي؟ +### 4. كم مرة يمكنني ترقية ال الفرعيةرسم بياني الخاص بي؟ -يفضل عدم ترقية ال subgraphs بشكل متكرر. ارجع للسؤال أعلاه لمزيد من التفاصيل. +يفضل عدم ترقية ال الفرعيةرسم بياني بشكل متكرر. ارجع للسؤال أعلاه لمزيد من التفاصيل. ### 5. هل يمكنني بيع أسهم التنسيق الخاصة بي؟ -لا يمكن "شراء" أو "بيع" أسهم التنسيق مثل توكنات ERC20 الأخرى التي قد تكون على دراية بها. يمكن فقط صكها (إنشاؤها) أو حرقها (إتلافها) على طول منحنى الترابط ل subgraph معين. من خلال منحنى الترابط يتم تحديد مقدار GRT اللازمة لصك إشارة جديدة ، وكمية GRT التي تتلقاها عندما تحرق إشارتك الحالية. بصفتك منسقا، عليك أن تعرف أنه عندما تقوم بحرق أسهم التنسيق الخاصة بك لسحب GRT ، فيمكن أن ينتهي بك الأمر ب GRT أكثر أو أقل مما قمت بإيداعه في البداية. +Curation shares cannot be "bought" or "sold" like other ERC20 tokens that you may be familiar with. They can only be minted (created) or burned (destroyed) along the bonding curve for a particular subgraph. The amount of GRT needed to mint a new signal, and the amount of GRT you receive when you burn your existing signal are determined by that bonding curve. As a Curator, you need to know that when you burn your curation shares to withdraw GRT, you can end up with more or less GRT than you initially deposited. لازلت مشوشا؟ راجع فيديو دليل التنسيق أدناه: diff --git a/website/pages/ar/network/delegating.mdx b/website/pages/ar/network/delegating.mdx index 0ca35665a8ac..117a96f2dda6 100644 --- a/website/pages/ar/network/delegating.mdx +++ b/website/pages/ar/network/delegating.mdx @@ -1,26 +1,26 @@ --- -title: المفوض(Delegator) +title: Delegating --- لا يمكن شطب المفوضين بسبب السلوك السيئ ، ولكن هناك ضريبة ودائع على المفوضين لتثبيط اتخاذ القرار السيئ الذي قد يضر بسلامة الشبكة. -سيشرح هذا الدليل كيف تكون مفوضا فعالا في Graph Network. يشارك المفوضون أرباح حصتهم المفوضة مع المفهرسين. يجب أن يستخدم المفوض أفضل حكم لديه لاختيار المفهرسين بناء على عوامل متعددة. يرجى ملاحظة أن هذا الدليل لن يتطرق لخطوات مثل إعداد Metamask ، حيث أن هذه المعلومات متاحة على نطاق واسع على الإنترنت. يوجد ثلاثة أقسام في هذا الدليل: +من خلال التفويض إلى المفهرس ، يكسب المندوبون جزءًا من رسوم ومكافآت استعلام المفهرس. يعتمد مقدار الاستعلامات التي يمكن للمفهرس معالجتها على حصة المفهرس الخاصة (والمفوضة) والسعر الذي يفرضه المفهرس لكل استعلام ، لذلك كلما زادت الحصة المخصصة للمفهرس ، زادت الاستفسارات المحتملة التي يمكنهم معالجتها. ## دليل المفوض -سيشرح هذا الدليل كيف تصبح مفوضا فعالا في Graph Network. يشارك المفوضون أرباح حصتهم المفوضة مع المفهرسين. يجب على المفوض اختيار المفهرس المناسب بحكمة بناء على عوامل متعددة. يرجى ملاحظة أن هذا الدليل لن يتطرق لخطوات مثل إعداد Metamask ، حيث أن هذه المعلومات متاحة على نطاق واسع على الإنترنت. يوجد ثلاثة أقسام في هذا الدليل: +This guide will explain how to be an effective Delegator in the Graph Network. Delegators share earnings of the protocol alongside all Indexers based on their delegated stake. A Delegator must use their best judgment to choose Indexers based on multiple factors. Please note this guide will not go over steps such as setting up Metamask properly, as that information is widely available on the internet. There are three sections in this guide: -- مخاطر تفويض التوكن في شبكة The Graph +- مخاطر تفويض التوكن في شبكة رسم بياني - كيفية حساب العوائد المتوقعة كمفوض -- فيديو يوضح خطوات التفويض في شبكة the Graph +- A video guide showing the steps to delegate in the Graph Network UI -## مخاطر التفويض (Delegation) +## مخاطر التفويض القائمة أدناه هي المخاطر الرئيسية لكونك مفوضا في البروتوكول. ### رسوم التفويض -لا يمكن شطب المفوضين بسبب السلوك السيئ ، ولكن هناك ضريبة على المفوضين لتثبيط اتخاذ القرار السيئ الذي قد يضر بسلامة الشبكة. +Delegators cannot be slashed for bad behavior, but there is a tax on Delegators to disincentivize poor decision-making that could harm the integrity of the network. من المهم أن تفهم أنه في كل مرة تقوم فيها بالتفويض ، سيتم حرق 0.5٪. هذا يعني أنه إذا كنت تفوض 1000 GRT ، فستحرق 5 GRT تلقائيا. @@ -28,9 +28,9 @@ title: المفوض(Delegator) ### فترة إلغاء التفويض -عندما يرغب أحد المفوضين في إلغاء التفويض ، تخضع التوكن الخاصة به إلى فترة 28 يوما وذلك لإلغاء التفويض. هذا يعني أنه لا يمكنهم تحويل التوكن الخاصة بهم ، أو كسب أي مكافآت لمدة 28 يوما. +Whenever a Delegator wants to undelegate, their tokens are subject to a 28-day unbonding period. This means they cannot transfer their tokens, or earn any rewards for 28 days. -إذا اخترت مفهرسا ليس جديرا بالثقة ، أو لا يقوم بعمل جيد ، فستحتاج إلى إلغاء التفويض ، مما يعني أنك ستفقد الكثير من الفرص لكسب المكافآت وعند قيامك بالتفويض مرة أخرى عند مفهرس آخر فحينها سيتم حرق 0.5% من GRT المفوضة. +One thing to consider as well is choosing an Indexer wisely. If you choose an Indexer who was not trustworthy, or not doing a good job, you will want to undelegate, which means you will be losing a lot of opportunities to earn rewards, which can be just as bad as burning GRT.
لاحظ 0.5٪ رسوم التفويض ، بالإضافة إلى فترة 28 يوما لإلغاء التفويض.
@@ -38,7 +38,7 @@ title: المفوض(Delegator) هذا جزء مهم عليك أن تفهمه. أولاً ، دعنا نناقش ثلاث قيم مهمة للغاية وهي بارامترات التفويض. -اقتطاع مكافأة الفهرسة Indexing Reward Cut - هو جزء من المكافآت التي سيحتفظ بها المفهرس لنفسه. هذا يعني أنه إذا تم تعيينه على 100٪ ، فستحصل كمفوض على 0 كمكافآت فهرسة. إذا رأيت 80٪ في واجهة المستخدم ، فهذا يعني أنك كمفوض ، ستتلقى 20٪. ملاحظة مهمة - في بداية الشبكة ، مكافآت الفهرسة تمثل غالبية المكافآت. +Indexing Reward Cut - The indexing reward cut is the portion of the rewards that the Indexer will keep for themselves. That means if it is set to 100%, as a Delegator you will get 0 indexing rewards. If you see 80% in the UI, that means as a Delegator, you will receive 20%. An important note - at the beginning of the network, Indexing Rewards will account for the majority of the rewards.
*المفهرس الأعلى يمنح المفوضين 90٪ من المكافآت. والمتوسط يمنح المفوضين 20٪. والأدنى يعطي المفوضين ~ 83٪.* @@ -46,7 +46,7 @@ title: المفوض(Delegator) - اقتطاع رسوم الاستعلام Query Fee Cut - هذا تماما مثل اقتطاع مكافأة الفهرسة Indexing Reward Cut. ومع ذلك ، فهو مخصص بشكل خاص للعائدات على رسوم الاستعلام التي يجمعها المفهرس. وتجدر الإشارة إلى أنه في بداية الشبكة ، سيكون العائد من رسوم الاستعلام صغيرا جدا مقارنة بمكافأة الفهرسة. من المستحسن الاهتمام بالشبكة لتحديد متى ستصبح رسوم الاستعلام في الشبكة أكثر أهمية. -كما ترى ، تحتاج للكثير من التفكير لاختيار المفهرس الصحيح. ولهذا نوصي بشدة باستكشاف The Graph Discord لتحديد من هم المفهرسون الذين يتمتعون بأفضل سمعة اجتماعية وتقنية لمكافأة المفوضين على أساس ثابت. العديد من المفهرسين نشيطون جدا في Discord ، وسيسعدهم الرد على أسئلتك. يقوم العديد منهم بالفهرسة لعدة أشهر في testnet ، ويبذلون قصارى جهدهم لمساعدة المفوضين على كسب عائد جيد ، حيث يعمل ذلك على تحسين الشبكة ونجاحها. +As you can see, there is a lot of thought that must go into choosing the right Indexer. This is why we highly recommend you explore The Graph Discord to determine who the Indexers are with the best social reputation, and technical reputation, to reward Delegators consistently. Many of the Indexers are very active in Discord and will be happy to answer your questions. Many of them have been Indexing for months in the testnet, and are doing their best to help Delegators earn a good return, as it improves the health and success of the network. ### حساب العائد المتوقع للمفوضين @@ -73,9 +73,9 @@ title: المفوض(Delegator) ### النظر في سعة التفويض (delegation capacity) -شيء آخر للأخذ بعين الاعتبار وهو سعة التفويض. حاليا نسبة التفويض (Delegation Ratio) تم تعيينه على 16. هذا يعني أنه إذا قام المفهرس بعمل staking ل 1،000،000 GRT ، فإن سعة التفويض الخاصة به هي 16،000،000 GRT من التوكن المفوضة التي يمكنهم استخدامها في البروتوكول. وأي توكن مفوّضة تزيد عن هذا المبلغ ستقلل من جميع مكافآت المفوضين. +Another thing to consider is the delegation capacity. Currently, the Delegation Ratio is set to 16. This means that if an Indexer has staked 1,000,000 GRT, their Delegation Capacity is 16,000,000 GRT of Delegated tokens that they can use in the protocol. Any delegated tokens over this amount will dilute all the Delegator rewards. -لنفرض أن المفهرس لديه 100،000،000 GRT مفوضة ، وسعته هي فقط 16،000،000 GRT. هذا يعني أنه لا يتم استخدام 84,000,000 GRT لكسب التوكنات. وجميع المفوضين والمفهرس يحصلون على مكافآت أقل مما يمكن أن يحصلوا عليه. +Imagine an Indexer has 100,000,000 GRT delegated to them, and their capacity is only 16,000,000 GRT. This means effectively, 84,000,000 GRT tokens are not being used to earn tokens. And all the Delegators, and the Indexer, are earning way less rewards than they could be. لذلك يجب على المفوض دائما أن يأخذ في الاعتبار سعة التفويض (Delegation Capacity) للمفهرس ، وأن يأخذها في الاعتبار عند اتخاذ القرار. diff --git a/website/pages/ar/network/developing.mdx b/website/pages/ar/network/developing.mdx new file mode 100644 index 000000000000..fa5c64a977e9 --- /dev/null +++ b/website/pages/ar/network/developing.mdx @@ -0,0 +1,53 @@ +--- +title: Developing +--- + +Developers are the demand side of The Graph ecosystem. Developers build subgraphs and publish them to The Graph Network. Then, they query live subgraphs with GraphQL in order to power their applications. + +## دورة حياة الـ الفرعيةرسم بياني + +Subgraphs deployed to the network have a defined lifecycle. + +#### Build locally + +As with all subgraph development, it starts with local development and testing. Developers can use the same local setup whether they are building for The Graph Network, the hosted service or a local Graph Node, leveraging `graph-cli` and `graph-ts` to build their subgraph. Developers are encouraged to use tools such as [Matchstick](https://github.com/LimeChain/matchstick) for unit testing to improve the robustness of their subgraphs. + +> There are certain constraints on The Graph Network, in terms of feature and network support. Only subgraphs on [supported networks](/developing/supported-networks) will earn indexing rewards, and subgraphs which fetch data from IPFS are also not eligible. + +#### Deploy to the Subgraph Studio + +Once defined, the subgraph can be built and deployed to the [Subgraph Studio](https://thegraph.com/docs/en/deploying/subgraph-studio-faqs/). The Subgraph Studio is a sandbox environment which will index the deployed subgraph and make it available for rate-limited development and testing. This gives developers an opportunity to verify that their subgraph does not encounter any indexing errors, and works as expected. + +#### Publish to the Network + +When the developer is happy with their subgraph, they can publish it to The Graph Network. This is an on-chain action, which registers the subgraph so that it is discoverable by Indexers. Published subgraphs have a corresponding NFT, which is then easily transferable. The published subgraph has associated metadata, which provides other network participants with useful context and information. + +#### Signal to Encourage Indexing + +Published subgraphs are unlikely to be picked up by Indexers without the addition of signal. Signal is locked GRT associated with a given subgraph, which indicates to Indexers that a given subgraph will receive query volume, and also contributes to the indexing rewards available for processing it. Subgraph developers will generally add signal to their subgraph, in order to encourage indexing. Third party Curators may also signal on a given subgraph, if they deem the subgraph likely to drive query volume. + +#### Querying & Application Development + +Once a subgraph has been processed by Indexers and is available for querying, developers can start to use the subgraph in their applications. Developers query subgraphs via a gateway, which forwards their queries to an Indexer who has processed the subgraph, paying query fees in GRT. + +In order to make queries, developers must generate an API key, which can be done in the Subgraph Studio. This API key must be funded with GRT, in order to pay query fees. Developers can set a maximum query fee, in order to control their costs, and limit their API key to a given subgraph or origin domain. The Subgraph Studio provides developers with data on their API key usage over time. + +Developers are also able to express an Indexer preference to the gateway, for example preferring Indexers whose query response is faster, or whose data is most up to date. These controls are set in the Subgraph Studio. + +#### Upgrading Subgraphs + +After a time a subgraph developer may want to update their subgraph, perhaps fixing a bug or adding new functionality. The subgraph developer may deploy new version(s) of their subgraph to the Subgraph Studio for rate-limited development and testing. + +Once the Subgraph Developer is ready to upgrade, they can initiate a transaction to point their subgraph at the new version. Upgrading the subgraph migrates any signal to the new version (assuming the user who applied the signal selected "auto-migrate"), which also incurs a migration tax. This signal migration should prompt Indexers to start indexing the new version of the subgraph, so it should soon become available for querying. + +#### Deprecating Subgraphs + +At some point a developer may decide that they no longer need a published subgraph. At that point they may deprecate the subgraph, which returns any signalled GRT to the Curators. + +### Diverse Developer Roles + +Some developers will engage with the full subgraph lifecycle on the network, publishing, querying and iterating on their own subgraphs. Some may be focused on subgraph development, building open APIs which others can build on. Some may be application focused, querying subgraphs deployed by others. + +## Developers and Network Economics + +Developers are a key economic actor in the network, locking up GRT in order to encourage indexing, and crucially querying subgraphs, which is the network's primary value exchange. Subgraph developers also burn GRT whenever a subgraph is upgraded. diff --git a/website/pages/ar/network/explorer.mdx b/website/pages/ar/network/explorer.mdx index adc07959c09d..ad67ace94263 100644 --- a/website/pages/ar/network/explorer.mdx +++ b/website/pages/ar/network/explorer.mdx @@ -1,66 +1,66 @@ --- -title: مستكشف +title: مستكشف الرسم البياني --- -مرحبا بك في مستكشف Graph ، أو كما نحب أن نسميها ، بوابتك اللامركزية في عالم subgraphs وبيانات الشبكة. 👩🏽‍🚀 مستكشف TheGraph يتكون من عدة اجزاء حيث يمكنك التفاعل مع مطوري Subgraphs الاخرين ، ومطوري dApp ،والمنسقين والمفهرسين، والمفوضين. للحصول على نظرة عامة حول the Graph Explorer، راجع الفيديو أدناه (أو تابع القراءة أدناه): +مرحبا بك في مستكشف رسم بياني ، أو كما نحب أن نسميها ، بوابتك اللامركزية في عالم الفرعيةرسم بياني وبيانات الشبكة. 👩🏽‍🚀 مستكشف رسم بياني يتكون من عدة اجزاء حيث يمكنك التفاعل مع مطوري الفرعيةرسم بياني الاخرين ، ومطوري dApp ،والمنسقين والمفهرسين، والمفوضين. للحصول على نظرة عامة حول رسم بياني، راجع الفيديو أدناه (أو تابع القراءة أدناه): -## Subgraphs +## الفرعيةرسم بياني -أولا ، إذا انتهيت من نشر Subgraphs الخاص بك في Subgraph Studio ، فإن علامة التبويب Subgraphs في الجزء العلوي من شريط التنقل هي المكان المناسب لعرض Subgraphs الخاصة بك (و Subgraphs الآخرين) على الشبكة اللامركزية. هنا ، ستتمكن من العثور على Subgraphs الذي تبحث عنه بدقة بناء على تاريخ الإنشاء أو مقدار الإشارة(signal amount) أو الاسم. +First things first, if you just finished deploying and publishing your subgraph in the Subgraph Studio, the Subgraphs tab on the top of the navigation bar is the place to view your own finished subgraphs (and the subgraphs of others) on the decentralized network. Here, you’ll be able to find the exact subgraph you’re looking for based on the date created, signal amount, or name. ![صورة المستكشف 1](/img/Subgraphs-Explorer-Landing.png) -عند النقر على Subgraphs ، يمكنك اختبار الاستعلامات وستكون قادرا على الاستفادة من تفاصيل الشبكة لاتخاذ قرارات صائبة. سيمكنك ايضا من الإشارة إلى GRT على Subgraphs الخاص بك أو subgraphs الآخرين لجعل المفهرسين على علم بأهميته وجودته. هذا أمر مهم جدا وذلك لأن الإشارة ل Subgraphs تساعد المفهرسين في اختيار ذلك ال Subgraph لفهرسته ، مما يعني أنه سيظهر على الشبكة لتقديم الاستعلامات. +عند النقر على الفرعيةرسم بياني ، يمكنك اختبار الاستعلامات وستكون قادرا على الاستفادة من تفاصيل الشبكة لاتخاذ قرارات صائبة. سيمكنك ايضا من الإشارة إلى GRT على الفرعيةرسم بياني الخاص بك أو الفرعيةرسم بياني الآخرين لجعل المفهرسين على علم بأهميته وجودته. هذا أمر مهم جدا وذلك لأن الإشارة ل الفرعيةرسم بياني تساعد المفهرسين في اختيار ذلك ال الفرعيةرسم بياني لفهرسته ، مما يعني أنه سيظهر على الشبكة لتقديم الاستعلامات. ![صورة المستكشف 2](/img/Subgraph-Details.png) -في كل صفحة مخصصة ل subgraphs ، تظهر العديد من التفاصيل. وهذا يتضمن +في كل صفحة مخصصة ل الفرعيةرسم بياني ، تظهر العديد من التفاصيل. وهذا يتضمن: -- أشر/الغي الإشارة على Subgraphs +- أشر/الغي الإشارة على الفرعيةرسم بياني - اعرض المزيد من التفاصيل مثل المخططات و ال ID الحالي وبيانات التعريف الأخرى -- بدّل بين الإصدارات وذلك لاستكشاف التكرارات السابقة ل subgraphs -- استعلم عن subgraphs عن طريق GraphQL -- اختبار subgraphs في playground -- اعرض المفهرسين الذين يفهرسون Subgraphs معين -- إحصائيات subgraphs (المخصصات ، المنسقين ، إلخ) -- اعرض من قام بنشر ال Subgraphs +- بدّل بين الإصدارات وذلك لاستكشاف التكرارات السابقة ل الفرعيةرسم بياني +- استعلم عن الفرعيةرسم بياني عن طريق GraphQL +- اختبار الفرعيةرسم بياني في playground +- اعرض المفهرسين الذين يفهرسون الفرعيةرسم بياني معين +- إحصائيات الفرعيةرسم بياني (المخصصات ، المنسقين ، إلخ) +- اعرض من قام بنشر ال الفرعيةرسم بياني ![صورة المستكشف 3](/img/Explorer-Signal-Unsignal.png) ## المشاركون -ضمن علامة التبويب هذه ، ستحصل على نظرة شاملة لجميع الأشخاص المشاركين في أنشطة الشبكة ، مثل المفهرسين والمفوضين Delegators والمنسقين Curators. سندخل في نظرة شاملة أدناه لما تعنيه كل علامة تبويب. +Within this tab, you’ll get a bird’s eye view of all the people that are participating in the network activities, such as Indexers, Delegators, and Curators. Below, we’ll go into an in-depth review of what each tab means for you. -### 2. المنسقون Curators +### 1. مفهرسات ![صورة المستكشف 4](/img/Indexer-Pane.png) -Let’s start with the Indexers. دعونا نبدأ مع المفهرسين المفهرسون هم العمود الفقري للبروتوكول ، كونهم بقومون بفهرسة ال Subgraph ، وتقديم الاستعلامات إلى أي شخص يستخدم subgraphs. في جدول المفهرسين ، يمكنك رؤية البارامترات الخاصة بتفويض المفهرسين ، وحصتهم ، ومقدار ما قاموا بتحصيله في كل subgraphs ، ومقدار الإيرادات التي حصلو عليها من رسوم الاستعلام ومكافآت الفهرسة. Deep dives below: +دعونا نبدأ مع المفهرسات. دعونا نبدأ مع المفهرسين المفهرسون هم العمود الفقري للبروتوكول ، كونهم بقومون بفهرسة ال الفرعيةرسم بياني ، وتقديم الاستعلامات إلى أي شخص يستخدم الفرعيةرسم بياني. في جدول المفهرسين ، يمكنك رؤية البارامترات الخاصة بتفويض المفهرسين ، وحصتهم ، ومقدار ما قاموا بتحصيله في كل الفرعيةرسم بياني ، ومقدار الإيرادات التي حصلو عليها من رسوم الاستعلام ومكافآت الفهرسة. الغوص العميق أدناه: - اقتطاع رسوم الاستعلام Query Fee Cut - هي النسبة المئوية لخصم رسوم الاستعلام والتي يحتفظ بها المفهرس عند التقسيم مع المفوضين Delegators - اقتطاع المكافأة الفعالة Effective Reward Cut - هو اقتطاع مكافأة الفهرسة indexing reward cut المطبقة على مجموعة التفويضات. إذا كانت سالبة ، فهذا يعني أن المفهرس يتنازل عن جزء من مكافآته. إذا كانت موجبة، فهذا يعني أن المفهرس يحتفظ ببعض مكافآته - فترة التهدئة Cooldown المتبقية - هو الوقت المتبقي حتى يتمكن المفهرس من تغيير بارامترات التفويض. يتم إعداد فترات التهدئة من قبل المفهرسين عندما يقومون بتحديث بارامترات التفويض الخاصة بهم - مملوكة Owned - هذه هي حصة المفهرس المودعة ، والتي قد يتم شطبها بسبب السلوك الضار أو غير الصحيح - مفوضة Delegated - هي حصة مفوضة من قبل المفوضين والتي يمكن تخصيصها بواسطة المفهرس ، لكن لا يمكن شطبها -- مخصصة Allocated - حصة يقوم المفهرسون بتخصيصها بشكل نشط نحو subgraphs التي يقومون بفهرستها -- سعة التفويض المتاحة Available Delegation Capacity - هو مقدار الحصة المفوضة التي يمكن للمفهرسين تلقيها قبل الوصول للحد الأقصى لتلقي التفويضات overdelegated -- سعة التفويض القصوى Max Delegation Capacity - هي الحد الأقصى من الحصة المفوضة التي يمكن للمفهرس قبولها. لا يمكن استخدام الحصة المفوضة الزائدة للمخصصات allocations أو لحسابات المكافآت. +- مخصصة Allocated - حصة يقوم المفهرسون بتخصيصها بشكل نشط نحو الفرعيةرسم بياني التي يقومون بفهرستها +- Available Delegation Capacity - the amount of delegated stake the Indexers can still receive before they become over-delegated +- Max Delegation Capacity - the maximum amount of delegated stake the Indexer can productively accept. An excess delegated stake cannot be used for allocations or rewards calculations. - رسوم الاستعلام Query Fees - هذا هو إجمالي الرسوم التي دفعها المستخدمون للاستعلامات التي يقدمها المفهرس طوال الوقت - مكافآت المفهرس Indexer Rewards - هو مجموع مكافآت المفهرس التي حصل عليها المفهرس ومفوضيهم Delegators. تدفع مكافآت المفهرس ب GRT. -يمكن للمفهرسين كسب كلا من رسوم الاستعلام ومكافآت الفهرسة. يحدث هذا عندما يقوم المشاركون في الشبكة بتفويض GRT للمفهرس. يتيح ذلك للمفهرسين تلقي رسوم الاستعلام ومكافآت بناء على بارامترات المفهرس الخاصة به. يتم تعيين بارامترات الفهرسة عن طريق النقر على الجانب الأيمن من الجدول ، أو بالانتقال إلى ملف تعريف المفهرس والنقر فوق زر "Delegate". +Indexers can earn both query fees and indexing rewards. Functionally, this happens when network participants delegate GRT to an Indexer. This enables Indexers to receive query fees and rewards depending on their Indexer parameters. Indexing parameters are set by clicking on the right-hand side of the table, or by going into an Indexer’s profile and clicking the “Delegate” button. -لمعرفة المزيد حول كيفية أن تصبح مفوضا كل ما عليك فعله هو التوجه إلى [الوثائق الرسمية](/network/delegating) أو [ أكاديمية The Graph ](https://docs.thegraph.academy/network/delegators). +To learn more about how to become an Indexer, you can take a look at the [official documentation](/network/indexing) or [The Graph Academy Indexer guides.](https://thegraph.academy/delegators/choosing-indexers/) ![نافذة تفاصيل الفهرسة](/img/Indexing-Details-Pane.png) ### 3. المفوضون Delegators -يقوم المنسقون بتحليل ال subgraphs لتحديد ال subgraphs ذات الجودة الأعلى. عندما يجد المنسق subgraph يراه جيدا ،فيمكنه تنسيقه من خلال الإشارة إلى منحنى الترابط الخاص به. وبهذا يسمح المنسقون للمفهرسين بمعرفة ماهي ال subgraphs عالية الجودة والتي يجب فهرستها. +Curators analyze subgraphs to identify which subgraphs are of the highest quality. Once a Curator has found a potentially attractive subgraph, they can curate it by signaling on its bonding curve. In doing so, Curators let Indexers know which subgraphs are high quality and should be indexed. -يمكن للمنسقين أن يكونوا من أعضاء المجتمع أو من مستخدمي البيانات أو حتى من مطوري ال subgraph والذين يشيرون إلى ال subgraphs الخاصة بهم وذلك عن طريق إيداع توكن GRT في منحنى الترابط. وبإيداع GRT ، يقوم المنسقون بصك أسهم التنسيق في ال subgraph. نتيجة لذلك ، يكون المنسقون مؤهلين لكسب جزء من رسوم الاستعلام التي يُنشئها ال subgraph المشار إليها. يساعد منحنى الترابط المنسقين على تنسيق مصادر البيانات الأعلى جودة. جدول المنسق في هذا القسم سيسمح لك برؤية: +يمكن للمنسقين أن يكونوا من أعضاء المجتمع أو من مستخدمي البيانات أو حتى من مطوري ال الفرعيةرسم بياني والذين يشيرون إلى ال الفرعيةرسم بياني الخاصة بهم وذلك عن طريق إيداع توكن GRT في منحنى الترابط. وبإيداع GRT ، يقوم المنسقون بصك أسهم التنسيق في ال الفرعيةرسم بياني. نتيجة لذلك ، يكون المنسقون مؤهلين لكسب جزء من رسوم الاستعلام التي يُنشئها ال الفرعيةرسم بياني المشار إليها. يساعد منحنى الترابط المنسقين على تنسيق مصادر البيانات الأعلى جودة. جدول المنسق في هذا القسم سيسمح لك برؤية: - التاريخ الذي بدأ فيه المنسق بالتنسق - عدد ال GRT الذي تم إيداعه @@ -68,32 +68,32 @@ Let’s start with the Indexers. دعونا نبدأ مع المفهرسين ا ![صورة المستكشف 6](/img/Curation-Overview.png) -إذا كنت تريد معرفة المزيد عن دور المنسق ، فيمكنك القيام بذلك عن طريق زيارة الروابط التالية ـ [ أكاديمية The Graph ](https://thegraph.academy/curators/) أو \[ الوثائق الرسمية. \](/network/curating) +If you want to learn more about the Curator role, you can do so by visiting the following links of [The Graph Academy](https://thegraph.academy/curators/) or [official documentation.](/network/curating) ### 3. المفوضون Delegators -يلعب المفوضون دورا رئيسيا في الحفاظ على الأمن واللامركزية في شبكة The Graph. يشاركون في الشبكة عن طريق تفويض (أي ، "Staking") توكن GRT إلى مفهرس واحد أو أكثر. بدون المفوضين، من غير المحتمل أن يربح المفهرسون مكافآت ورسوم مجزية. لذلك ، يسعى المفهرسون إلى جذب المفوضين من خلال منحهم جزءا من مكافآت الفهرسة ورسوم الاستعلام التي يكسبونها. +يلعب المفوضون دورا رئيسيا في الحفاظ على الأمن واللامركزية في شبكة رسم بياني. يشاركون في الشبكة عن طريق تفويض (أي ، "Staking") توكن GRT إلى مفهرس واحد أو أكثر. بدون المفوضين، من غير المحتمل أن يربح المفهرسون مكافآت ورسوم مجزية. لذلك ، يسعى المفهرسون إلى جذب المفوضين من خلال منحهم جزءا من مكافآت الفهرسة ورسوم الاستعلام التي يكسبونها. -يقوم المفوضون بدورهم باختيار المفهرسين بناء على عدد من المتغيرات المختلفة ، مثل الأداء السابق ، ومعدلات مكافأة الفهرسة ، واقتطاع رسوم الاستعلام query fee cuts. يمكن أن تلعب السمعة داخل المجتمع دورا في هذا! يوصى بالتواصل مع المفهرسين المختارين عبر [ The Graph's Discord ](https://thegraph.com/discord) أو [ منتدى The Graph ](https://forum.thegraph.com/)! +يقوم المفوضون بدورهم باختيار المفهرسين بناء على عدد من المتغيرات المختلفة ، مثل الأداء السابق ، ومعدلات مكافأة الفهرسة ، واقتطاع رسوم الاستعلام query fee cuts. يمكن أن تلعب السمعة داخل المجتمع دورا في هذا! يوصى بالتواصل مع المفهرسين المختارين عبر [ الرسم البياني دسکورد ](https://thegraph.com/discord) أو [ منتدى الرسم البياني ](https://forum.thegraph.com/)! ![صورة المستكشف 7](/img/Delegation-Overview.png) جدول المفوضين سيسمح لك برؤية المفوضين النشطين في المجتمع ، بالإضافة إلى مقاييس مثل: - عدد المفهرسين المفوض إليهم -- التفويض الأصلي للمفوض Delegator’s original delegation +- التفويض الأصلي للمفوض وفد المندوب الأصلي - المكافآت التي جمعوها والتي لم يسحبوها من البروتوكول - المكافآت التي تم سحبها من البروتوكول - كمية ال GRT التي يمتلكونها حاليا في البروتوكول - تاريخ آخر تفويض لهم -If you want to learn more about how to become a Delegator, look no further! لمعرفة المزيد حول كيفية أن تصبح مفهرسا ، يمكنك إلقاء نظرة على [ الوثائق الرسمية ](/network/indexing) أو [ دليل مفهرس أكاديمية The Graph. +If you want to learn more about how to become a Delegator, look no further! All you have to do is to head over to the [official documentation](/network/delegating) or [The Graph Academy](https://docs.thegraph.academy/network/delegators). ## الشبكة Network في قسم الشبكة ، سترى KPIs بالإضافة إلى القدرة على التبديل بين الفترات وتحليل مقاييس الشبكة بشكل مفصل. ستمنحك هذه التفاصيل فكرة عن كيفية أداء الشبكة بمرور الوقت. -### النشاط Activity +### النشاط نشاط يحتوي قسم النشاط على جميع مقاييس الشبكة الحالية بالإضافة إلى بعض المقاييس المتراكمة بمرور الوقت. هنا يمكنك رؤية أشياء مثل: @@ -113,7 +113,7 @@ If you want to learn more about how to become a Delegator, look no further! لم ### الفترات Epochs -في قسم الفترات، يمكنك تحليل مقاييس كل فترة مثل: +In the Epochs section, you can analyze on a per-epoch basis, metrics such as: - بداية الفترة أو نهايتها - مكافآت رسوم الاستعلام والفهرسة التي تم جمعها خلال فترة معينة @@ -127,7 +127,7 @@ If you want to learn more about how to become a Delegator, look no further! لم ## ملف تعريف المستخدم الخاص بك -الآن بعد أن تحدثنا عن احصائيات الشبكة ، دعنا ننتقل إلى ملفك الشخصي. ملفك الشخصي هو المكان المناسب لك لمشاهدة نشاط الشبكة ، بغض النظر عن كيفية مشاركتك في الشبكة. ستعمل محفظة Ethereum الخاصة بك كملف تعريف المستخدم الخاص بك ، وباستخدام User Dashboard، ستتمكن من رؤية: +Now that we’ve talked about the network stats, let’s move on to your personal profile. Your personal profile is the place for you to see your network activity, no matter how you’re participating on the network. Your crypto wallet will act as your user profile, and with the User Dashboard, you’ll be able to see: ### نظرة عامة على الملف الشخصي @@ -135,15 +135,15 @@ If you want to learn more about how to become a Delegator, look no further! لم ![صورة المستكشف 10](/img/Profile-Overview.png) -### تبويب ال Subgraphs +### تبويب ال الفرعيةرسم بياني -إذا قمت بالنقر على تبويب Subgraphs ، فسترى ال subgraphs المنشورة الخاصة بك. لن يشمل ذلك أي subgraphs تم نشرها ب CLI لأغراض الاختبار - لن تظهر ال subgraphs إلا عند نشرها على الشبكة اللامركزية. +إذا قمت بالنقر على تبويب الفرعيةرسم بياني ، فسترى ال الفرعيةرسم بياني المنشورة الخاصة بك. لن يشمل ذلك أي الفرعيةرسم بياني تم نشرها ب CLI لأغراض الاختبار - لن تظهر ال الفرعيةرسم بياني إلا عند نشرها على الشبكة اللامركزية. ![صورة المستكشف 11](/img/Subgraphs-Overview.png) ### تبويب الفهرسة -إذا قمت بالنقر على تبويب الفهرسة "Indexing " ، فستجد جدولا به جميع المخصصات النشطة والتاريخية ل subgraphs ، بالإضافة إلى المخططات التي يمكنك تحليلها ورؤية أدائك السابق كمفهرس. +إذا قمت بالنقر على تبويب الفهرسة "Indexing " ، فستجد جدولا به جميع المخصصات النشطة والتاريخية ل الفرعيةرسم بياني ، بالإضافة إلى المخططات التي يمكنك تحليلها ورؤية أدائك السابق كمفهرس. هذا القسم سيتضمن أيضا تفاصيل حول صافي مكافآت المفهرس ورسوم الاستعلام الصافي الخاصة بك. سترى المقاييس التالية: @@ -158,7 +158,7 @@ If you want to learn more about how to become a Delegator, look no further! لم ### تبويب التفويض Delegating Tab -المفوضون مهمون لشبكة the Graph. يجب أن يستخدم المفوض معرفته لاختيار مفهرسا يوفر عائدا على المكافآت. هنا يمكنك العثور على تفاصيل تفويضاتك النشطة والتاريخية ، مع مقاييس المفهرسين الذين قمت بتفويضهم. +المفوضون مهمون لشبكة رسم بياني. يجب أن يستخدم المفوض معرفته لاختيار مفهرسا يوفر عائدا على المكافآت. هنا يمكنك العثور على تفاصيل تفويضاتك النشطة والتاريخية ، مع مقاييس المفهرسين الذين قمت بتفويضهم. في النصف الأول من الصفحة ، يمكنك رؤية مخطط التفويض الخاص بك ، بالإضافة إلى مخطط المكافآت فقط. إلى اليسار ، يمكنك رؤية KPIs التي تعكس مقاييس التفويض الحالية. @@ -178,13 +178,13 @@ If you want to learn more about how to become a Delegator, look no further! لم ### تبويب التنسيق Curating -في علامة التبويب Curation ، ستجد جميع ال subgraphs التي تشير إليها (مما يتيح لك تلقي رسوم الاستعلام). الإشارة تسمح للمنسقين التوضيح للمفهرسين ماهي ال subgraphs ذات الجودة العالية والموثوقة ، مما يشير إلى ضرورة فهرستها. +في علامة التبويب Curation ، ستجد جميع ال الفرعيةرسم بياني التي تشير إليها (مما يتيح لك تلقي رسوم الاستعلام). الإشارة تسمح للمنسقين التوضيح للمفهرسين ماهي ال الفرعيةرسم بياني ذات الجودة العالية والموثوقة ، مما يشير إلى ضرورة فهرستها. ضمن علامة التبويب هذه ، ستجد نظرة عامة حول: -- جميع ال subgraphs التي تقوم بتنسيقها مع تفاصيل الإشارة -- إجمالي الحصة لكل subgraph -- مكافآت الاستعلام لكل subgraph +- جميع ال الفرعيةرسم بياني التي تقوم بتنسيقها مع تفاصيل الإشارة +- إجمالي الحصة لكل الفرعيةرسم بياني +- مكافآت الاستعلام لكل الفرعيةرسم بياني - تحديث في تفاصيل التاريخ ![صورة المستكشف 14](/img/Curation-Stats.png) @@ -193,11 +193,11 @@ If you want to learn more about how to become a Delegator, look no further! لم ضمن ملف تعريف المستخدم الخاص بك ، ستتمكن من إدارة تفاصيل ملفك الشخصي (مثل إعداد اسم ENS). إذا كنت مفهرسا ، فستستطيع الوصول إلى إعدادت أكثر. في ملف تعريف المستخدم الخاص بك ، ستتمكن من إعداد بارامترات التفويض والمشغلين. -- Operators تتخذ إجراءات محدودة في البروتوكول نيابة عن المفهرس ، مثل عمليات فتح وإغلاق المخصصات. Operators هي عناوين Ethereum أخرى ، منفصلة عن محفظة staking الخاصة بهم ، مع بوابة وصول للشبكة التي يمكن للمفهرسين تعيينها بشكل شخصي +- العاملين تتخذ إجراءات محدودة في البروتوكول نيابة عن المفهرس ، مثل عمليات فتح وإغلاق المخصصات. العاملين هي عناوين إيثيريوم أخرى ، منفصلة عن محفظة staking الخاصة بهم ، مع بوابة وصول للشبكة التي يمكن للمفهرسين تعيينها بشكل شخصي - تسمح لك بارامترات التفويض بالتحكم في توزيع GRT بينك وبين المفوضين. ![صورة المستكشف 15](/img/Profile-Settings.png) -كبوابتك الرسمية إلى عالم البيانات اللامركزية ، يتيح لك Graph Explorer اتخاذ مجموعة متنوعة من الإجراءات ، بغض النظر عن دورك في الشبكة. يمكنك الوصول إلى إعدادات ملفك الشخصي عن طريق فتح القائمة المنسدلة بجوار عنوانك ، ثم النقر على زر Settings. +كبوابتك الرسمية إلى عالم البيانات اللامركزية ، يتيح لك مستكشف الرسم البياني اتخاذ مجموعة متنوعة من الإجراءات ، بغض النظر عن دورك في الشبكة. يمكنك الوصول إلى إعدادات ملفك الشخصي عن طريق فتح القائمة المنسدلة بجوار عنوانك ، ثم النقر على زر إعدادات.
تفاصيل المحفظة
diff --git a/website/pages/ar/network/indexing.mdx b/website/pages/ar/network/indexing.mdx index aaa2c5f24602..357bd0cd888f 100644 --- a/website/pages/ar/network/indexing.mdx +++ b/website/pages/ar/network/indexing.mdx @@ -1,48 +1,48 @@ --- -title: فهرسة (indexing) +title: Indexing --- -المفهرسون ( Indexers) هم مشغلي العقد (node) في شبكة TheGraph ويقومون ب staking لتوكن (GRT) من أجل توفير خدمات الفهرسة ( indexing) والاستعلام. المفهرسون(Indexers) يحصلون على رسوم الاستعلام ومكافآت الفهرسة وذلك مقابل خدماتهم. وأيضا يكسبون من مجموعة الخصومات (Rebate Pool) والتي تتم مشاركتها مع جميع المساهمين في الشبكة بما يتناسب مع عملهم ، وفقا ل Cobbs-Douglas Rebate Function. +Indexers are node operators in The Graph Network that stake Graph Tokens (GRT) in order to provide indexing and query processing services. Indexers earn query fees and indexing rewards for their services. They also earn from a Rebate Pool that is shared with all network contributors proportional to their work, following the Cobb-Douglas Rebate Function. -يخضع GRT المخزن في البروتوكول لفترة إذابة thawing period وقد يتم شطبه إذا كان المفهرسون ضارون ويقدمون بيانات غير صحيحة للتطبيقات أو إذا قاموا بالفهرسة بشكل غير صحيح. المفهرسون يتم تفويضهم من قبل المفوضين وذلك للمساهمه في الشبكة. +GRT that is staked in the protocol is subject to a thawing period and can be slashed if Indexers are malicious and serve incorrect data to applications or if they index incorrectly. Indexers also earn rewards for delegated stake from Delegators, to contribute to the network. -يختار المفهرسون subgraphs للقيام بالفهرسة بناء على إشارة تنسيق subgraphs ، حيث أن المنسقون يقومون ب staking ل GRT وذلك للإشارة ل Subgraphs عالية الجودة. يمكن أيضا للعملاء (مثل التطبيقات) تعيين بارامترات حيث يقوم المفهرسون بمعالجة الاستعلامات ل Subgraphs وتسعير رسوم الاستعلام. +يختار المفهرسون الفرعيةرسم بياني للقيام بالفهرسة بناء على إشارة تنسيق الفرعيةرسم بياني ، حيث أن المنسقون يقومون ب staking ل GRT وذلك للإشارة ل الفرعيةرسم بياني عالية الجودة. يمكن أيضا للعملاء (مثل التطبيقات) تعيين بارامترات حيث يقوم المفهرسون بمعالجة الاستعلامات ل الفرعيةرسم بياني وتسعير رسوم الاستعلام. ## الأسئلة الشائعة -### ما هو الحد الأدنى لتكون مفهرسا على الشبكة؟ +### What is the minimum stake required to be an Indexer on the network? -لتكون مفهرسا فإن الحد الأدنى ل Staking هو 100K GRT. +The minimum stake for an Indexer is currently set to 100K GRT. -### ما هي مصادر الدخل للمفهرس؟ +### What are the revenue streams for an Indexer? -** خصومات رسوم الاستعلام Query fee rebates ** - هي مدفوعات مقابل خدمة الاستعلامات على الشبكة. هذه الأجور تكون بواسطة قناة بين المفهرس والبوابة (gateway). كل طلب استعلام من بوابة يحتوي على دفع ،والرد عليه دليل على صحة نتيجة الاستعلام. +**Query fee rebates** - Payments for serving queries on the network. These payments are mediated via state channels between an Indexer and a gateway. Each query request from a gateway contains a payment and the corresponding response a proof of query result validity. -** مكافآت الفهرسة Indexing rewards** - يتم إنشاؤها من خلال تضخم سنوي للبروتوكول بنسبة 3٪ ، ويتم توزيع مكافآت الفهرسة على المفهرسين الذين يقومون بفهرسة ال subgraphs للشبكة. +**Indexing rewards** - Generated via a 3% annual protocol wide inflation, the indexing rewards are distributed to Indexers who are indexing subgraph deployments for the network. -### كيف توزع المكافآت؟ +### How are indexing rewards distributed? -تأتي مكافآت الفهرسة من تضخم البروتوكول والذي تم تعيينه بنسبة 3٪ سنويا. يتم توزيعها عبر subgraphs بناءً على نسبة جميع إشارات التنسيق في كل منها ، ثم يتم توزيعها بالتناسب على المفهرسين بناءً على حصصهم المخصصة على هذا ال subgraph. \*\* يجب إغلاق المخصصة بإثبات صالح للفهرسة (POI) والذي يفي بالمعايير التي حددها ميثاق التحكيم حتى يكون مؤهلاً للحصول على المكافآت. +Indexing rewards come from protocol inflation which is set to 3% annual issuance. They are distributed across subgraphs based on the proportion of all curation signal on each, then distributed proportionally to Indexers based on their allocated stake on that subgraph. **An allocation must be closed with a valid proof of indexing (POI) that meets the standards set by the arbitration charter in order to be eligible for rewards.** -تم إنشاء العديد من الأدوات من قبل المجتمع لحساب المكافآت ؛ ستجد مجموعة منها منظمة في دليل المجتمع. يمكنك أيضا أن تجد قائمة محدثة من الأدوات في قناة #delegators و #indexers على Discord. +Numerous tools have been created by the community for calculating rewards; you'll find a collection of them organized in the [Community Guides collection](https://www.notion.so/Community-Guides-abbb10f4dba040d5ba81648ca093e70c). You can also find an up to date list of tools in the #Delegators and #Indexers channels on the [Discord server](https://discord.gg/vtvv7FP). Here we link a [recommended allocation optimiser](https://github.com/graphprotocol/AllocationOpt.jl) integrated with the indexer software stack. ### ما هو إثبات الفهرسة (POI)؟ -تُستخدم POIs في الشبكة وذلك للتحقق من أن المفهرس يقوم بفهرسة ال subgraphs والتي قد تم تخصيصها. POI للكتلة الأولى من الفترة الحالية تسلم عند إغلاق المخصصة لذلك التخصيص ليكون مؤهلاً لفهرسة المكافآت. كتلة ال POI هي عبارة عن ملخص لجميع معاملات المخزن لنشر subgraph محدد حتى تضمين تلك الكتلة. +POIs are used in the network to verify that an Indexer is indexing the subgraphs they have allocated on. A POI for the first block of the current epoch must be submitted when closing an allocation for that allocation to be eligible for indexing rewards. A POI for a block is a digest for all entity store transactions for a specific subgraph deployment up to and including that block. ### متى يتم توزيع مكافآت الفهرسة؟ -المخصصات تقوم بتجميع المكافآت باستمرار أثناء فاعليتها. يتم جمع المكافآت من قبل المفهرسين وتوزيعها كلما تم إغلاق مخصصاتهم. يحدث هذا إما يدويا عندما يريد المفهرس إغلاقها بالقوة ، أو بعد 28 فترة يمكن للمفوض إغلاق التخصيص للمفهرس ، لكن هذا لا ينتج عنه أي مكافآت. 28 فترة هي أقصى مدة للتخصيص (حاليا، تستمر فترة واحدة لمدة 24 ساعة تقريبًا). +Allocations are continuously accruing rewards while they're active and allocated within 28 epochs. Rewards are collected by the Indexers, and distributed whenever their allocations are closed. That happens either manually, whenever the Indexer wants to force close them, or after 28 epochs a Delegator can close the allocation for the Indexer, but this results in no rewards. 28 epochs is the max allocation lifetime (right now, one epoch lasts for ~24h). -### هل يمكن مراقبة مكافآت المفهرس المعلقة؟ +### Can pending indexing rewards be monitored? -تشمل العديد من لوحات المعلومات dashboards التي أنشأها المجتمع على قيم المكافآت المعلقة ويمكن التحقق منها بسهولة يدويا باتباع الخطوات التالية: +يحتوي عقد RewardsManager على وظيفة [ الحصول على المكافآت ](https://github.com/graphprotocol/contracts/blob/master/contracts/rewards/RewardsManager.sol#L317) للقراءة فقط يمكن استخدامها للتحقق من المكافآت المعلقة لتخصيص معين. -استخدم Etherscan لاستدعاء `getRewards()`: +تشتمل العديد من لوحات المعلومات التي أنشأها المجتمع على قيم المكافآت المعلقة ويمكن التحقق منها بسهولة يدويًا باتباع الخطوات التالية: -1. استعلم عن [mainnet subgraph](https://thegraph.com/hosted-service/subgraph/graphprotocol/graph-network-mainnet) للحصول على IDs لجميع المخصصات النشطة: +1. استعلم عن [mainnet الفرعيةرسم بياني ](https://thegraph.com/hosted-service/subgraph/graphprotocol/graph-network-mainnet) للحصول على IDs لجميع المخصصات النشطة: ```graphql } query indexerAllocations @@ -60,16 +60,16 @@ title: فهرسة (indexing) استخدم Etherscan لاستدعاء `()getRewards`: -- انتقل إلى [ واجهة Etherscan لعقد المكافآت Rewards contract ](https://etherscan.io/address/0x9Ac758AB77733b4150A901ebd659cbF8cB93ED66#readProxyContract) +- انتقل إلى [ واجهة Etherscan لعقد المكافآت عقد المكافآت ](https://etherscan.io/address/0x9Ac758AB77733b4150A901ebd659cbF8cB93ED66#readProxyContract) -* لاستدعاء ()getRewards: - - قم بتوسيع ال\*\* 10. قائمة getRewards المنسدلة. - - انقر على زر **Query استعلام**. - - الاعتراضات لديها **ثلاث** نتائج محتملة ، وكذلك إيداع ال Fishermen. +* لاستدعاء `getRewards()`: + - قم بتوسيع ** 10 .الحصول على المكافآت ** القائمة المنسدلة. + - أدخل ** معرّف التخصيص ** في الإدخال. + - انقر فوق الزر ** الاستعلام **. -### ما هي الاعتراضات disputes وأين يمكنني عرضها؟ +### ما هي الاعتراضات النزاعات وأين يمكنني عرضها؟ -يمكن الاعتراض على استعلامات المفهرس وتخصيصاته على The Graph أثناء فترة الاعتراض dispute. تختلف فترة الاعتراض حسب نوع الاعتراض. تحتوي الاستعلامات / الشهادات Queries/attestations على نافذة اعتراض لـ 7 فترات ، في حين أن المخصصات لها 56 فترة. بعد مرور هذه الفترات ، لا يمكن فتح اعتراضات ضد أي من المخصصات أو الاستعلامات. عند فتح الاعتراض ، يجب على الصيادين Fishermen إيداع على الأقل 10000 GRT ، والتي سيتم حجزها حتى يتم الانتهاء من الاعتراض وتقديم حل. الصيادون Fisherman هم المشاركون في الشبكة الذين يفتحون الاعتراضات. +يمكن الاعتراض على استعلامات المفهرس وتخصيصاته على The رسم بياني أثناء فترة الاعتراض النزاعات. تختلف فترة الاعتراض حسب نوع الاعتراض. تحتوي الاستعلامات / الشهادات Queries/attestations على نافذة اعتراض لـ 7 فترات ، في حين أن المخصصات لها 56 فترة. بعد مرور هذه الفترات ، لا يمكن فتح اعتراضات ضد أي من المخصصات أو الاستعلامات. عند فتح الاعتراض ، يجب على الصيادين Fishermen إيداع على الأقل 10000 GRT ، والتي سيتم حجزها حتى يتم الانتهاء من الاعتراض وتقديم حل. الصيادون Fisherman هم المشاركون في الشبكة الذين يفتحون الاعتراضات. يمكنك عرض الاعتراضات من واجهة المستخدم في صفحة ملف تعريف المفهرس وذلك من علامة التبويب `Disputes`. @@ -81,71 +81,71 @@ title: فهرسة (indexing) ### ما هي خصومات رسوم الاستعلام ومتى يتم توزيعها؟ -يتم تحصيل رسوم الاستعلام بواسطة البوابة gateway وذلك عندما يتم إغلاق الحصة وتجميعها في خصومات رسوم الاستعلام في ال subgraph. تم تصميم مجموعة الخصومات rebate pool لتشجيع المفهرسين على تخصيص حصة تقريبية لمقدار رسوم الاستعلام التي يكسبونها للشبكة. يتم حساب جزء رسوم الاستعلام في المجموعة التي تم تخصيصها لمفهرس معين وذلك باستخدام دالة Cobbs-Douglas Production ؛ المبلغ الموزع لكل مفهرس يعتمد على مساهماتهم في المجموعة pool وتخصيص حصتهم على ال subgraph. +Query fees are collected by the gateway whenever an allocation is closed and accumulated in the subgraph's query fee rebate pool. The rebate pool is designed to encourage Indexers to allocate stake in rough proportion to the amount of query fees they earn for the network. The portion of query fees in the pool that are allocated to a particular Indexer is calculated using the Cobb-Douglas Production Function; the distributed amount per Indexer is a function of their contributions to the pool and their allocation of stake on the subgraph. -بمجرد إغلاق التخصيص ومرور فترة الاعتراض، تكون الخصومات متاحة للمطالبة بها من قبل المفهرس. عند المطالبة ، يتم توزيع خصومات رسوم الاستعلام للمفهرس ومفوضيه بناء على اقتطاع رسوم الاستعلام query fee cut ونسب أسهم التفويض. +Once an allocation has been closed and the dispute period has passed the rebates are available to be claimed by the Indexer. Upon claiming, the query fee rebates are distributed to the Indexer and their Delegators based on the query fee cut and the delegation pool proportions. ### ما المقصود بqueryFeeCut وindexingRewardCut؟ -قيم ال `queryFeeCut` و `indexingRewardCut` هي بارامترات التفويض التي قد يقوم المفهرس بتعيينها مع cooldownBlocks للتحكم في توزيع GRT بين المفهرس ومفوضيه. انظر لآخر الخطوات في [ ال staking في البروتوكول](/network/indexing#stake-in-the-protocol) للحصول على إرشادات حول تعيين بارامترات التفويض. +The `queryFeeCut` and `indexingRewardCut` values are delegation parameters that the Indexer may set along with cooldownBlocks to control the distribution of GRT between the Indexer and their Delegators. See the last steps in [Staking in the Protocol](/network/indexing#stake-in-the-protocol) for instructions on setting the delegation parameters. -- **queryFeeCut** هي النسبة المئوية لخصومات رسوم الاستعلام المتراكمة على subgraph والتي سيتم توزيعها على المفهرس. إذا تم التعيين على 95٪ ، فسيحصل المفهرس على 95٪ من مجموعة خصم رسوم الاستعلام عند المطالبة بالمخصصة و 5٪ إلى المفوضين. +- **queryFeeCut** - the % of query fee rebates accumulated on a subgraph that will be distributed to the Indexer. If this is set to 95%, the Indexer will receive 95% of the query fee rebate pool when an allocation is claimed with the other 5% going to the Delegators. -- **indexingRewardCut** هي النسبة المئوية لمكافآت الفهرسة المتراكمة على subgraph والتي سيتم توزيعها على المفهرس. إذا تم تعيين 95٪ ، فسيحصل المفهرس على 95٪ من مجموع مكافآت الفهرسة عند إغلاق المخصصة وسيقوم المفوضون بتقاسم الـ 5٪ الأخرى. +- **indexingRewardCut** - the % of indexing rewards accumulated on a subgraph that will be distributed to the Indexer. If this is set to 95%, the Indexer will receive 95% of the indexing rewards pool when an allocation is closed and the Delegators will split the other 5%. -### كيف يعرف المفهرسون أي subgraphs عليهم فهرستها؟ +### How do Indexers know which subgraphs to index? -من خلال تطبيق تقنيات متقدمة لاتخاذ قرارات فهرسة ال subgraph ، وسنناقش العديد من المقاييس الرئيسية المستخدمة لتقييم ال subgraphs في الشبكة: +من خلال تطبيق تقنيات متقدمة لاتخاذ قرارات فهرسة ال الفرعيةرسم بياني ، وسنناقش العديد من المقاييس الرئيسية المستخدمة لتقييم ال الفرعيةرسم بياني في الشبكة: -- **إشارة التنسيق Curation signal** ـ تعد نسبة إشارة تنسيق الشبكة على subgraph معين مؤشرا جيدا على الاهتمام بهذا ال subgraph، خاصة أثناء المراحل الأولى عندما يزداد حجم الاستعلام. +- **إشارة التنسيق Curation signal** ـ تعد نسبة إشارة تنسيق الشبكة على subgraph معين مؤشرا جيدا على الاهتمام بهذا ال الفرعيةرسم بياني، خاصة أثناء المراحل الأولى عندما يزداد حجم الاستعلام. -- **مجموعة رسوم الاستعلام Query fees collected** ـ تعد البيانات التاريخية لحجم مجموعة رسوم الاستعلام ل subgraph معين مؤشرا جيدا للطلب المستقبلي. +- **مجموعة رسوم الاستعلام Query fees collected** ـ تعد البيانات التاريخية لحجم مجموعة رسوم الاستعلام ل الفرعيةرسم بياني معين مؤشرا جيدا للطلب المستقبلي. -- **Amount staked** ـ مراقبة سلوك المفهرسين أو النظر إلى نسب إجمالي الحصة المخصصة ل subgraphs معين تسمح للمفهرس بمراقبة جانب العرض لاستعلامات الsubgraph لتحديد ال subgraphs الموثوقة أو subgraphs التي قد تظهر الحاجة إلى مزيد من العرض. +- **Amount staked** - Monitoring the behavior of other Indexers or looking at proportions of total stake allocated towards specific subgraphs can allow an Indexer to monitor the supply side for subgraph queries to identify subgraphs that the network is showing confidence in or subgraphs that may show a need for more supply. -- **ال Subgraphs التي بدون مكافآت فهرسة** ـ بعض الsubgraphs لا تنتج مكافآت الفهرسة بشكل أساسي لأنها تستخدم ميزات غير مدعومة مثل IPFS أو لأنها تستعلم عن شبكة أخرى خارج الشبكة الرئيسية mainnet. سترى رسالة على ال subgraph إذا لا تنتج مكافآت فهرسة. +- **ال الفرعيةرسم بياني التي بدون مكافآت فهرسة** ـ بعض ال الفرعيةرسم بياني لا تنتج مكافآت الفهرسة بشكل أساسي لأنها تستخدم ميزات غير مدعومة مثل IPFS أو لأنها تستعلم عن شبكة أخرى خارج الشبكة الرئيسية mainnet. سترى رسالة على ال الفرعيةرسم بياني إذا لا تنتج مكافآت فهرسة. ### ما هي المتطلبات للهاردوير؟ -- **صغيرة**ـ يكفي لبدء فهرسة العديد من ال subgraphs، من المحتمل أن تحتاج إلى توسيع. +- **صغيرة**ـ يكفي لبدء فهرسة العديد من ال الفرعيةرسم بياني، من المحتمل أن تحتاج إلى توسيع. - ** قياسية ** - هو الإعداد الافتراضي ، ويتم استخدامه في مثال بيانات نشر k8s / terraform. -- **متوسطة** - مؤشر انتاج ​​يدعم 100 subgraphs و 200-500 طلب في الثانية. -- **كبيرة** - مُعدة لفهرسة جميع ال subgraphs المستخدمة حاليا وأيضا لخدمة طلبات حركة مرور البيانات ذات الصلة. +- **Medium** - Production Indexer supporting 100 subgraphs and 200-500 requests per second. +- **كبيرة** - مُعدة لفهرسة جميع ال الفرعيةرسم بياني المستخدمة حاليا وأيضا لخدمة طلبات حركة مرور البيانات ذات الصلة. -| Setup | (CPUs) | (memory in GB) | (disk in TBs) | (CPUs) | (memory in GB) | -| ----- | :----: | :------------: | :-----------: | :----: | :------------: | -| صغير | 4 | 8 | 1 | 4 | 16 | -| قياسي | 8 | 30 | 1 | 12 | 48 | -| متوسط | 16 | 64 | 2 | 32 | 64 | -| كبير | 72 | 468 | 3.5 | 48 | 184 | +| Setup | Postgres
(CPUs) | Postgres
(memory in GBs) | Postgres
(disk in TBs) | VMs
(CPUs) | VMs
(memory in GBs) | +| --- | :-: | :-: | :-: | :-: | :-: | +| صغير | 4 | 8 | 1 | 4 | 16 | +| قياسي | 8 | 30 | 1 | 12 | 48 | +| متوسط | 16 | 64 | 2 | 32 | 64 | +| كبير | 72 | 468 | 3.5 | 48 | 184 | -### ما هي بعض احتياطات الأمان الأساسية التي يجب على المفهرس اتخاذها؟ +### What are some basic security precautions an Indexer should take? -- **محفظة المشغلOperator wallet**- يعد إعداد محفظة المشغل إجراء احترازيًا مهمًا لأنه يسمح للمفهرس بالحفاظ على الفصل بين مفاتيحه التي تتحكم في ال stake وتلك التي تتحكم في العمليات اليومية. انظر [الحصة Stake في البروتوكول](/network/indexing#stake-in-the-protocol) للحصول على تعليمات. +- **Operator wallet** - Setting up an operator wallet is an important precaution because it allows an Indexer to maintain separation between their keys that control stake and those that are in control of day-to-day operations. See [Stake in Protocol](/network/indexing#stake-in-the-protocol) for instructions. -- **الجدار الناريFirewall**- فقط خدمة المفهرس تحتاج إلى كشفها للعامة ويجب تأمين منافذ الإدارة والوصول إلى قاعدة البيانات: the Graph Node JSON-RPC endpoint (المنفذ الافتراضي: 8030) ، API endpoint لإدارة المفهرس (المنفذ الافتراضي: 18000) ، ويجب عدم كشف نقطة نهاية قاعدة بيانات Postgres (المنفذ الافتراضي: 5432). +- **Firewall** - Only the Indexer service needs to be exposed publicly and particular attention should be paid to locking down admin ports and database access: the Graph Node JSON-RPC endpoint (default port: 8030), the Indexer management API endpoint (default port: 18000), and the Postgres database endpoint (default port: 5432) should not be exposed. ## البنية الأساسية -في البنية الأساسية للمفهرس ، توجد فيها Graph Node والتي تراقب Ethereum وتستخرج وتحمل البيانات لكل تعريف subgraph وتقدمها باعتبارها [GraphQL API](/about#how-the-graph-works). يجب توصيل Graph Node ب EVM node endpoints و IPFS node للحصول على البيانات و قاعدة بيانات PostgreSQL ومكونات المفهرس indexer components التي تسهل تفاعلها مع الشبكة. +At the center of an Indexer's infrastructure is the Graph Node which monitors the indexed networks, extracts and loads data per a subgraph definition and serves it as a [GraphQL API](/about/#how-the-graph-works). The Graph Node needs to be connected to an endpoint exposing data from each indexed network; an IPFS node for sourcing data; a PostgreSQL database for its store; and Indexer components which facilitate its interactions with the network. -- **قاعدة بيانات PostgreSQL**-هو المخزن الرئيسي لGraph Node ، وفيه يتم تخزين بيانات ال subgraph. خدمة المفهرس والوكيل تستخدم أيضًا قاعدة البيانات لتخزين بيانات قناة الحالة ونماذج التكلفة وقواعد الفهرسة. +- **PostgreSQL database** - The main store for the Graph Node, this is where subgraph data is stored. The Indexer service and agent also use the database to store state channel data, cost models, indexing rules, and allocation actions. -- **Ethereum endpoint** - هي نقطة نهاية تعرض Ethereum JSON-RPC API. قد يأخذ ذلك نموذج عميل Ethereum واحدا أو قد يكون ذو إعداد أكثر تعقيدا والذي يقوم بتحميل أرصدة عبر عدة نماذج. من المهم أن تدرك أن بعض ال subgraphs تتطلب قدرات معينة لعميل Ethereum مثل الأرشفة وتتبع API. +- **Data endpoint** - For EVM-compatible networks, Graph Node needs to be connected to an endpoint that exposes an EVM-compatible JSON-RPC API. This may take the form of a single client or it could be a more complex setup that load balances across multiple. It's important to be aware that certain subgraphs will require particular client capabilities such as archive mode and/or the parity tracing API. -- **(الإصدار أقل من 5) IPFS node** بيانات ال Subgraph تخزن على شبكة IPFS. يمكن لGraph Node بشكل أساسي الوصول إلى IPFS node أثناء نشر الsubgraph لجلب الsubgraph manifest وجميع الملفات المرتبطة. لا يحتاج مفهرسو الشبكة إلى استضافة IPFS node الخاصة بهم ، حيث يتم استضافة IPFS node للشبكة على https://ipfs.network.thegraph.com. +- **IPFS node (version less than 5)** - Subgraph deployment metadata is stored on the IPFS network. The Graph Node primarily accesses the IPFS node during subgraph deployment to fetch the subgraph manifest and all linked files. Network Indexers do not need to host their own IPFS node, an IPFS node for the network is hosted at https://ipfs.network.thegraph.com. - **خدمة المفهرس Indexer service**- يتعامل مع جميع الاتصالات الخارجية المطلوبة مع الشبكة. ويشارك نماذج التكلفة وحالات الفهرسة ، ويمرر طلبات الاستعلام من البوابات gateways إلى Graph Node ، ويدير مدفوعات الاستعلام عبر قنوات الحالة مع البوابة. -- **Indexer agent**- يسهل تفاعلات المفهرسين على السلسلة بما في ذلك التسجيل في الشبكة ، وإدارة عمليات نشر الsubgraph إلى Graph Node/s الخاصة بها ، وإدارة المخصصات. سيرفر مقاييس +- **Indexer agent** - Facilitates the Indexers interactions on chain including registering on the network, managing subgraph deployments to its Graph Node/s, and managing allocations. -- **Prometheus metrics server** - مكونات The Graph Node والمفهرس يسجلون مقاييسهم على سيرفر المقاييس. +- **Prometheus metrics server** - مكونات رسم بياني العقدة والمفهرس يسجلون مقاييسهم على سيرفر المقاييس. -ملاحظة: لدعم القياس السريع ، يستحسن فصل الاستعلام والفهرسة بين مجموعات مختلفة من العقد Nodes: عقد الاستعلام وعقد الفهرس. +ملاحظة: لدعم القياس السريع ، يستحسن فصل الاستعلام والفهرسة بين مجموعات مختلفة من العقد العقدة: عقد الاستعلام وعقد الفهرس. ### نظرة عامة على المنافذ Ports -> **مهم** كن حذرًا بشأن كشف المنافذ للعامة - **منافذ الإدارة** يجب أن تبقى مغلقة. يتضمن ذلك Graph Node JSON-RPC ونقاط نهاية endpoints إدارة المفهرس التالية. +> **Important**: Be careful about exposing ports publicly - **administration ports** should be kept locked down. This includes the the Graph Node JSON-RPC and the Indexer management endpoints detailed below. #### Graph Node @@ -170,7 +170,9 @@ title: فهرسة (indexing) | ------ | ----------------- | ------ | ------------------------- | --------------------------------------- | | 8000 | API إدارة المفهرس | / | --indexer-management-port | `INDEXER_AGENT_INDEXER_MANAGEMENT_PORT` | -### قم بإعداد البنية الأساسية للسيرفر باستخدام Terraform على Google Cloud +### قم بإعداد البنية الأساسية للسيرفر باستخدام Terraform على جوجل كلاود + +> ملاحظة: يمكن للمفهرسين كبديل استخدام خدمات أمازون ويب، أو مايكروسوفت أزور، أو علي بابا. #### متطلبات التثبيت @@ -180,7 +182,7 @@ title: فهرسة (indexing) #### أنشئ مشروع Google Cloud -- استنسخ أو انتقل إلى مستودع المفهرس. +- Clone or navigate to the Indexer repository. - انتقل إلى الدليل ./terraform ، حيث يجب تنفيذ جميع الأوامر. @@ -217,7 +219,7 @@ gcloud services enable servicenetworking.googleapis.com gcloud services enable sqladmin.googleapis.com ``` -- قم بإنشاء حساب الخدمة service account. +- قم بإنشاء حساب الخدمة حساب الخدمة. ```sh svc_name= @@ -262,7 +264,7 @@ EOF #### استخدم Terraform لإنشاء البنية الأساسية -قبل تشغيل أي من الأوامر ، اقرأ [variables.tf](https://github.com/graphprotocol/indexer/blob/main/terraform/variables.tf) وأنشئ ملف `terraform.tfvars` في هذا الدليل (أو قم بتعديل الدليل الذي أنشأناه في الخطوة الأخيرة). أدخل الإعداد في `terraform.tfvars` لكل متغير تريد أن يتجاهل الافتراضي ، أو تريد تعيين قيمة إليه. +قبل تشغيل أي من الأوامر ، اقرأ [المتغيرات.tf](https://github.com/graphprotocol/indexer/blob/main/terraform/variables.tf) وأنشئ ملف `terraform.tfvars` في هذا الدليل (أو قم بتعديل الدليل الذي أنشأناه في الخطوة الأخيرة). أدخل الإعداد في `terraform.tfvars` لكل متغير تريد أن يتجاهل الافتراضي ، أو تريد تعيين قيمة إليه. - قم بتشغيل الأوامر التالية لإنشاء البنية الأساسية. @@ -285,7 +287,7 @@ kubectl config use-context $(kubectl config get-contexts --output='name' | grep $indexer) ``` -#### إنشاء مكونات ال Kubernetes للمفهرس +#### Creating the Kubernetes components for the Indexer - انسخ الدليل `k8s / Overays` إلى دليل جديد `$dir,` واضبط إدخال `القواعد` في `$dir/ kustomization.yaml` بحيث يشير إلى الدليل `k8s / base`. @@ -295,7 +297,7 @@ kubectl config use-context $(kubectl config get-contexts --output='name' ### Graph Node -[ Graph Node ](https://github.com/graphprotocol/graph-node) هو تطبيق مفتوح المصدر Rust ومصدره Ethereum blockchain لتحديث البيانات والذي يمكن الاستعلام عنها عبر GraphQL endpoint. يستخدم المطورون ال subgraphs لتحديد مخططهم ، ويستخدمون مجموعة من الرسوم لتحويل البيانات التي يتم الحصول عليها من blockchain و the Graph Node والتي تقوم بمعالجة مزامنة السلسلة بأكملها ، ومراقبة الكتل الجديدة ، وتقديمها عبر GraphQL endpoint. +[ عقدة الرسم البياني ](https://github.com/graphprotocol/graph-node) هو تطبيق مفتوح المصدر Rust ومصدره الفرعيةرسم بياني بلوكشين لتحديث البيانات والذي يمكن الاستعلام عنها عبر GraphQL نقطة النهاية. يستخدم المطورون ال الفرعيةرسم بياني لتحديد مخططهم ، ويستخدمون مجموعة من الرسوم لتحويل البيانات التي يتم الحصول عليها من بلوكشين و عقدة الرسم البياني والتي تقوم بمعالجة مزامنة السلسلة بأكملها ، ومراقبة الكتل الجديدة ، وتقديمها عبر GraphQL نقطة النهاية. #### ابدأ من المصدر @@ -307,7 +309,7 @@ kubectl config use-context $(kubectl config get-contexts --output='name' - **IPFS** -- **متطلبات إضافية لمستخدمي Ubuntu **- لتشغيل Graph Node على Ubuntu ، قد تكون هناك حاجة إلى بعض الحزم الإضافية. +- **متطلبات إضافية لمستخدمي Ubuntu **- لتشغيل عقدة الرسم البياني على Ubuntu ، قد تكون هناك حاجة إلى بعض الحزم الإضافية. ```sh sudo apt-get install -y clang libpg-dev libssl-dev pkg-config @@ -363,17 +365,17 @@ docker-compose up ### مكونات المفهرس Indexer components -المشاركة الناجحة في الشبكة تتطلب مراقبة وتفاعلا مستمرين تقريبا ، لذلك قمنا ببناء مجموعة من تطبيقات Typescript لتسهيل مشاركة شبكة المفهرسين. هناك ثلاثة مكونات للمفهرس: +To successfully participate in the network requires almost constant monitoring and interaction, so we've built a suite of Typescript applications for facilitating an Indexers network participation. There are three Indexer components: -- **Indexer agent** - يراقب الشبكة والبنية الأساسية الخاصة بالمفهرس ويدير عمليات نشر subgraph والتي تتم فهرستها وتوزيعها على السلسلة ومقدار ما يتم تخصيصه لكل منها. +- **Indexer agent** - The agent monitors the network and the Indexer's own infrastructure and manages which subgraph deployments are indexed and allocated towards on chain and how much is allocated towards each. -- **Indexer service** - المكون الوحيد الذي يجب الكشف عنه للعامة، حيث تمر الخدمة على استعلامات subgraph إلى graph node ، وتدير قنوات الحالة state channels لمدفوعات الاستعلام ، وتشارك معلومات مهمة بشأن اتخاذ القرار للعملاء مثل البوابات gateways. +- **Indexer service** - المكون الوحيد الذي يجب الكشف عنه للعامة، حيث تمر الخدمة على استعلامات الفرعيةرسم بياني إلى graph node ، وتدير قنوات الحالة state channels لمدفوعات الاستعلام ، وتشارك معلومات مهمة بشأن اتخاذ القرار للعملاء مثل البوابات gateways. -- ** فهرس CLI ** - واجهة سطر الأوامر لإدارة وكيل المفهرس indexer agent. يسمح للمفهرسين بإدارة نماذج التكلفة وقواعد الفهرسة. +- **Indexer CLI** - The command line interface for managing the Indexer agent. It allows Indexers to manage cost models, manual allocations, actions queue, and indexing rules. #### ابدأ -يجب أن يتم وضع وكيل المفهرس indexer agent وخدمة المفهرس indexer service في نفس الموقع مع البنية الأساسية ل Graph Node الخاصة بك. هناك العديد من الطرق لإعداد بيئات التشغيل الافتراضية لمكونات المفهرس ؛ سنشرح هنا كيفية تشغيلها على baremetal باستخدام حزم NPM أو المصدر ، أو عبر kubernetes و docker على Google Cloud Kubernetes Engine. إذا لم تُترجم أمثلة الإعداد هذه بشكل جيد إلى بنيتك الأساسية ، فمن المحتمل أن يكون هناك دليل مجتمعي للرجوع إليه ، تفضل بزيارة [ Discord ](https://thegraph.com/discord)! تذكر أن [ تشارك في البروتوكول ](/network/indexing#stake-in-the-protocol) قبل البدء في تشغيل مكونات المفهرس! +The Indexer agent and Indexer service should be co-located with your Graph Node infrastructure. There are many ways to set up virtual execution environments for your Indexer components; here we'll explain how to run them on baremetal using NPM packages or source, or via kubernetes and docker on the Google Cloud Kubernetes Engine. If these setup examples do not translate well to your infrastructure there will likely be a community guide to reference, come say hi on [Discord](https://thegraph.com/discord)! Remember to [stake in the protocol](/network/indexing#stake-in-the-protocol) before starting up your Indexer components! #### من حزم NPM @@ -449,11 +451,11 @@ docker run -p 7600:7600 -it indexer-service:latest ... docker run -p 18000:8000 -it indexer-agent:latest ... ``` -انظر قسم [ إعداد البنية الأساسية للسيرفر باستخدام Terraform على Google Cloud ](/network/indexing#setup-server-infrastructure-using-terraform-on-google-cloud) +**NOTE**: After starting the containers, the Indexer service should be accessible at [http://localhost:7600](http://localhost:7600) and the Indexer agent should be exposing the Indexer management API at [http://localhost:18000/](http://localhost:18000/). #### استخدام K8s و Terraform -The Indexer CLI هو مكون إضافي لـ [`@graphprotocol/graph-cli`](https://www.npmjs.com/package/@graphprotocol/graph-cli) ويمكن الوصول إليه في النهاية الطرفية عند `graph indexer`. +See the [Setup Server Infrastructure Using Terraform on Google Cloud](/network/indexing#setup-server-infrastructure-using-terraform-on-google-cloud) section #### الاستخدام @@ -484,6 +486,7 @@ graph-indexer-agent start \ --postgres-username \ --postgres-password \ --postgres-database indexer \ + --allocation-management auto \ | pino-pretty ``` @@ -522,31 +525,45 @@ graph indexer connect http://localhost:18000 graph indexer status ``` -#### إدارة المفهرس باستخدام مفهرس CLI +#### Indexer management using Indexer CLI -يحتاج وكيل المفهرس indexer agent إلى مدخلات من المفهرس من أجل التفاعل بشكل مستقل مع الشبكة نيابة عن المفهرس. **قواعد الفهرسة** تقوم بتحديد سلوك وكيل المفهرس indexer agent. باستخدام **قواعد الفهرسة** يمكن للمفهرس تطبيق إستراتيجيته المحددة لانتقاء ال subgraphs للفهرسة وعرض الاستعلامات الخاصة بها. تتم إدارة القواعد عبر GraphQL API التي يقدمها الوكيل وتُعرف باسم API إدارة المفهرس. الأداة المقترحة للتفاعل مع ** API إدارة المفهرس ** هي ** Indexer CLI ** ، وهو امتداد لـ **Graph CLI**. +The suggested tool for interacting with the **Indexer Management API** is the **Indexer CLI**, an extension to the **Graph CLI**. The Indexer agent needs input from an Indexer in order to autonomously interact with the network on the behalf of the Indexer. The mechanism for defining Indexer agent behavior are **allocation management** mode and **indexing rules**. Under auto mode, an Indexer can use **indexing rules** to apply their specific strategy for picking subgraphs to index and serve queries for. Rules are managed via a GraphQL API served by the agent and known as the Indexer Management API. Under manual mode, an Indexer can create allocation actions using **actions queue** and explicitly approve them before they get executed. Under oversight mode, **indexing rules** are used to populate **actions queue** and also require explicit approval for execution. #### الاستخدام -يتصل ** Indexer CLI ** بوكيل المفهرس indexer agent ، عادةً من خلال port-forwarding ، لذلك لا يلزم تشغيل CLI على نفس السيرفر أو المجموعة. ولمساعدتك على البدء سيتم وصف CLI بإيجاز هنا. +The **Indexer CLI** connects to the Indexer agent, typically through port-forwarding, so the CLI does not need to run on the same server or cluster. To help you get started, and to provide some context, the CLI will briefly be described here. -- `graph indexer connect ` - قم بالاتصال بAPI إدارة المفهرس. عادةً ما يتم فتح الاتصال بالسيرفر عبر إعادة توجيه المنفذ port forwarding ، لذلك يمكن تشغيل CLI بسهولة عن بُعد. (مثل: `kubectl port-forward pod/ 8000:8000`) +- `graph indexer connect ` - Connect to the Indexer management API. Typically the connection to the server is opened via port forwarding, so the CLI can be easily operated remotely. (Example: `kubectl port-forward pod/ 8000:8000`) -- `graph indexer rules get [options] ...]` - احصل على قاعدة أو أكثر من قواعد الفهرسة باستخدام `all` مثل `` للحصول على جميع القواعد, أو `global` للحصول على الافتراضات العالمية. يمكن استخدام argument إضافية `--merged` لتحديد قواعد النشر المحددة المدمجة مع القاعدة العامة. هذه هي الطريقة التي يتم تطبيقها في indexer agent. +- `graph indexer rules get [options] [ ...]` - Get one or more indexing rules using `all` as the `` to get all rules, or `global` to get the global defaults. An additional argument `--merged` can be used to specify that deployment specific rules are merged with the global rule. This is how they are applied in the Indexer agent. - `graph indexer rules set [options] ...` - قم بتعيين قاعدة أو أكثر من قواعد الفهرسة. -- `graph indexer rules start [options] ` - ابدأ فهرسة ال subgraph إذا كان متاحًا وقم بتعيين `decisionBasis` إلى `always`, لذلك دائما سيختار وكيل المفهرس فهرسته. إذا تم تعيين القاعدة العامة على دائما always ، فسيتم فهرسة جميع ال subgraphs المتاحة على الشبكة. +- `graph indexer rules start [options] ` - Start indexing a subgraph deployment if available and set its `decisionBasis` to `always`, so the Indexer agent will always choose to index it. If the global rule is set to always then all available subgraphs on the network will be indexed. - `graph indexer rules stop [options] ` - توقف عن فهرسة النشر deployment وقم بتعيين ملف `decisionBasis` إلىnever أبدًا ، لذلك سيتم تخطي هذا النشر عند اتخاذ قرار بشأن عمليات النشر للفهرسة. -- `graph indexer rules maybe [options] ` — ضع `thedecisionBasis` للنشر deployment ل `rules`, بحيث يستخدم وكيل المفهرس قواعد الفهرسة ليقرر ما إذا كان سيفهرس هذا النشر أم لا. +- `graph indexer rules maybe [options] ` — Set the `decisionBasis` for a deployment to `rules`, so that the Indexer agent will use indexing rules to decide whether to index this deployment. + +- `graph indexer actions get [options] ` - Fetch one or more actions using `all` or leave `action-id` empty to get all actions. An additonal argument `--status` can be used to print out all actions of a certain status. + +- `graph indexer action queue allocate ` - Queue allocation action + +- `graph indexer action queue reallocate ` - Queue reallocate action + +- `graph indexer action queue unallocate ` - Queue unallocate action + +- `graph indexer actions cancel [ ...]` - Cancel all action in the queue if id is unspecified, otherwise cancel array of id with space as separator + +- `graph indexer actions approve [ ...]` - Approve multiple actions for execution + +- `graph indexer actions execute approve` - Force the worker to execute approved actions immediately جميع الأوامر التي تعرض القواعد في الخرج output يمكنها الاختيار بين تنسيقات الإخراج المدعومة (`table`, `yaml`, `json`) باستخدام `-output` argument. #### قواعد الفهرسة -يمكن تطبيق قواعد الفهرسة إما كإعدادات افتراضية عامة أو لعمليات نشر subgraph محددة باستخدام معرفاتها IDs. يعد الحقلان `deployment` و `decisionBasis` إلزاميًا ، بينما تعد جميع الحقول الأخرى اختيارية. عندما تحتوي قاعدة الفهرسة على `rules` باعتبارها `decisionBasis` ، فإن وكيل المفهرس indexer agent سيقارن قيم العتبة غير الفارغة في تلك القاعدة بالقيم التي تم جلبها من الشبكة. إذا كان نشر ال subgraph يحتوي على قيم أعلى (أو أقل) من أي من العتبات ، فسيتم اختياره للفهرسة. +Indexing rules can either be applied as global defaults or for specific subgraph deployments using their IDs. The `deployment` and `decisionBasis` fields are mandatory, while all other fields are optional. When an indexing rule has `rules` as the `decisionBasis`, then the Indexer agent will compare non-null threshold values on that rule with values fetched from the network for the corresponding deployment. If the subgraph deployment has values above (or below) any of the thresholds it will be chosen for indexing. على سبيل المثال ، إذا كانت القاعدة العامة لديها`minStake` من ** 5 ** (GRT) ، فأي نشر subgraph به أكثر من 5 (GRT) من الحصة المخصصة ستتم فهرستها. قواعد العتبة تتضمن `maxAllocationPercentage`, `minSignal`, `maxSignal`, `minStake`, `minAverageQueryFees`. @@ -554,28 +571,144 @@ graph indexer status ```graphql type IndexingRule { - deployment: string - allocationAmount: string | null - parallelAllocations: number | null - decisionBasis: IndexingDecisionBasis - maxAllocationPercentage: number | null - minSignal: string | null - maxSignal: string | null - minStake: string | null - minAverageQueryFees: string | null - custom: string | null + identifier: string + identifierType: IdentifierType + decisionBasis: IndexingDecisionBasis! + allocationAmount: number | null + allocationLifetime: number | null + autoRenewal: boolean + parallelAllocations: number | null + maxAllocationPercentage: number | null + minSignal: string | null + maxSignal: string | null + minStake: string | null + minAverageQueryFees: string | null + custom: string | null + requireSupported: boolean | null + } + +IdentifierType { + deployment + subgraph + group } IndexingDecisionBasis { rules never always + offchain } ``` +Example usage of indexing rule: + +``` +graph indexer rules offchain QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK + +graph indexer rules set QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK decisionBasis always allocationAmount 123321 allocationLifetime 14 autoRenewal false requireSupported false + +graph indexer rules stop QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK + +graph indexer rules delete QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK +``` + +#### Actions queue CLI + +The indexer-cli provides an `actions` module for manually working with the action queue. It uses the **Graphql API** hosted by the indexer management server to interact with the actions queue. + +The action execution worker will only grab items from the queue to execute if they have `ActionStatus = approved`. In the recommended path actions are added to the queue with ActionStatus = queued, so they must then be approved in order to be executed on-chain. The general flow will look like: + +- Action added to the queue by the 3rd party optimizer tool or indexer-cli user +- Indexer can use the `indexer-cli` to view all queued actions +- Indexer (or other software) can approve or cancel actions in the queue using the `indexer-cli`. The approve and cancel commands take an array of action ids as input. +- The execution worker regularly polls the queue for approved actions. It will grab the `approved` actions from the queue, attempt to execute them, and update the values in the db depending on the status of execution to `success` or `failed`. +- If an action is successful the worker will ensure that there is an indexing rule present that tells the agent how to manage the allocation moving forward, useful when taking manual actions while the agent is in `auto` or `oversight` mode. +- The indexer can monitor the action queue to see a history of action execution and if needed re-approve and update action items if they failed execution. The action queue provides a history of all actions queued and taken. + +نموذج البيانات Data model: + +```graphql +Type ActionInput { + status: ActionStatus + type: ActionType + deploymentID: string | null + allocationID: string | null + amount: string | null + poi: string | null + force: boolean | null + source: string + reason: string | null + priority: number | null +} + +ActionStatus { + queued + approved + pending + success + failed + canceled +} + +ActionType { + allocate + unallocate + reallocate + collect +} +``` + +Example usage from source: + +```bash +indexer indexer actions get all + +indexer indexer actions get --status queued + +indexer indexer actions queue allocate QmeqJ6hsdyk9dVbo1tvRgAxWrVS3rkERiEMsxzPShKLco6 5000 + +indexer indexer actions queue reallocate QmeqJ6hsdyk9dVbo1tvRgAxWrVS3rkERiEMsxzPShKLco6 0x4a58d33e27d3acbaecc92c15101fbc82f47c2ae5 55000 + +indexer indexer actions queue unallocate QmeqJ6hsdyk9dVbo1tvRgAxWrVS3rkERiEMsxzPShKLco6 0x4a58d33e27d3acbaecc92c15101fbc82f47c2ae + +indexer indexer actions cancel + +indexer indexer actions approve 1 3 5 + +indexer indexer actions execute approve +``` + +Note that supported action types for allocation management have different input requirements: + +- `Allocate` - allocate stake to a specific subgraph deployment + + - required action params: + - deploymentID + - amount + +- `Unallocate` - close allocation, freeing up the stake to reallocate elsewhere + + - required action params: + - allocationID + - deploymentID + - optional action params: + - poi + - force (forces using the provided POI even if it doesn’t match what the graph-node provides) + +- `Reallocate` - atomically close allocation and open a fresh allocation for the same subgraph deployment + + - required action params: + - allocationID + - deploymentID + - amount + - optional action params: + - poi + - force (forces using the provided POI even if it doesn’t match what the graph-node provides) + #### نماذج التكلفة Cost models -نماذج التكلفة تقوم بالتسعير بشكل ديناميكي للاستعلامات بناءً على خصائص السوق والاستعلام. خدمة المفهرس Indexer Service تشارك نموذج التكلفة مع البوابات gateways لكل subgraph للذين يريدون الرد على الاستفسارات. هذه البوابات تستخدم نموذج التكلفة لاتخاذ قرارات اختيار المفهرس لكل استعلام وللتفاوض بشأن الدفع مع المفهرسين المختارين. +Cost models provide dynamic pricing for queries based on market and query attributes. The Indexer Service shares a cost model with the gateways for each subgraph for which they intend to respond to queries. The gateways, in turn, use the cost model to make Indexer selection decisions per query and to negotiate payment with chosen Indexers. #### Agora @@ -606,7 +739,7 @@ default => 0.1 * $SYSTEM_LOAD; #### تطبيق نموذج التكلفة -يتم تطبيق نماذج التكلفة عبر Indexer CLI ، والذي يقوم بتمريرها إلى وكيل المفهرس عبر API إدارة المفهرس للتخزين في قاعدة البيانات. بعد ذلك ستقوم خدمة المفهرس Indexer Service باستلامها وتقديم نماذج التكلفة للبوابات كلما طلبوا ذلك. +Cost models are applied via the Indexer CLI, which passes them to the Indexer Management API of the Indexer agent for storing in the database. The Indexer Service will then pick them up and serve the cost models to gateways whenever they ask for them. ```sh 'indexer cost set variables '{ "SYSTEM_LOAD": 1.4 } @@ -619,17 +752,17 @@ indexer cost set model my_model.agora الخطوات الأولى للمشاركة في الشبكة كمفهرس هي الموافقة على البروتوكول وصناديق الأسهم، و (اختياريا) إعداد عنوان المشغل لتفاعلات البروتوكول اليومية. _ ** ملاحظة **: لأغراض الإرشادات ، سيتم استخدام Remix للتفاعل مع العقد ، ولكن لا تتردد في استخدام الأداة التي تختارها (\[OneClickDapp \](https://oneclickdapp.com/) و [ABItopic](https://abitopic.io/) و [MyCrypto](https://www.mycrypto.com/account) وهذه بعض الأدوات المعروفة)._ -بعد أن تم إنشاؤه بواسطة المفهرس ، يمر التخصيص السليم عبر أربع حالات. +Once an Indexer has staked GRT in the protocol, the [Indexer components](/network/indexing#indexer-components) can be started up and begin their interactions with the network. #### اعتماد التوكن tokens 1. افتح [ تطبيق Remix ](https://remix.ethereum.org/) على المتصفح -2. في `File Explorer` أنشئ ملفا باسم ** GraphToken.abi ** باستخدام \[token ABI \](https://raw.githubusercontent.com/graphprotocol /contracts/mainnet-deploy-build/build/abis/GraphToken.json). +2. في `File Explorer` أنشئ ملفا باسم ** GraphToken.abi ** باستخدام [token ABI](https://raw.githubusercontent.com/graphprotocol/contracts/mainnet-deploy-build/build/abis/GraphToken.json). 3. مع تحديد `GraphToken.abi` وفتحه في المحرر ، قم بالتبديل إلى Deploy و `Run Transactions` في واجهة Remix. -4. تحت البيئة environment ، حدد `Injected Web3` وتحت `Account` حدد عنوان المفهرس. +4. Under environment select `Injected Web3` and under `Account` select your Indexer address. 5. قم بتعيين عنوان GraphToken - الصق العنوان (`0xc944E90C64B2c07662A292be6244BDf05Cda44a7`) بجوار `At Address` وانقر على الزر `At address` لتطبيق ذلك. @@ -643,15 +776,15 @@ indexer cost set model my_model.agora 3. مع تحديد `Staking.abi` وفتحه في المحرر ، قم بالتبديل إلى قسم `Deploy` و `Run Transactions` في واجهة Remix. -4. تحت البيئة environment ، حدد `Injected Web3` وتحت `Account` حدد عنوان المفهرس. +4. Under environment select `Injected Web3` and under `Account` select your Indexer address. 5. عيّن عنوان عقد Staking - الصق عنوان عقد Staking (`0xF55041E37E12cD407ad00CE2910B8269B01263b9`) بجوار `At address` وانقر على الزر `At address` لتطبيق ذلك. 6. استدعي `stake()` لوضع GRT في البروتوكول. -7. (اختياري) يجوز للمفهرسين الموافقة على عنوان آخر ليكون المشغل للبنية الأساسية للمفهرس من أجل فصل المفاتيح keys التي تتحكم بالأموال عن تلك التي تقوم بإجراءات يومية مثل التخصيص على subgraphs وتقديم الاستعلامات (مدفوعة). لتعيين المشغل استدعي `setOperator()` بعنوان المشغل. +7. (Optional) Indexers may approve another address to be the operator for their Indexer infrastructure in order to separate the keys that control the funds from those that are performing day to day actions such as allocating on subgraphs and serving (paid) queries. In order to set the operator call `setOperator()` with the operator address. -8. (اختياري) من أجل التحكم في توزيع المكافآت وجذب المفوضين بشكل استراتيجي ، يمكن للمفهرسين تحديث بارامترات التفويض الخاصة بهم عن طريق تحديث indexingRewardCut (أجزاء لكل مليون) ، و queryFeeCut (أجزاء لكل مليون) ، و cooldownBlocks (عدد الكتل). للقيام بذلك ، استدعي `setDelegationParameters()`. المثال التالي يعيّن queryFeeCut لتوزيع 95٪ من خصومات الاستعلام query rebates للمفهرس و 5٪ للمفوضين ، اضبط indexingRewardCut لتوزيع 60٪ من مكافآت الفهرسة للمفهرس و 40٪ للمفوضين ، وقم بتعيين فترة `thecooldownBlocks` إلى 500 كتلة. +8. (Optional) In order to control the distribution of rewards and strategically attract Delegators Indexers can update their delegation parameters by updating their indexingRewardCut (parts per million), queryFeeCut (parts per million), and cooldownBlocks (number of blocks). To do so call `setDelegationParameters()`. The following example sets the queryFeeCut to distribute 95% of query rebates to the Indexer and 5% to Delegators, set the indexingRewardCutto distribute 60% of indexing rewards to the Indexer and 40% to Delegators, and set `thecooldownBlocks` period to 500 blocks. ``` setDelegationParameters(950000, 600000, 500) @@ -659,12 +792,14 @@ setDelegationParameters(950000, 600000, 500) ### عمر التخصيص allocation -بعد أن يتم إنشاؤه بواسطة المفهرس ، يمر التخصيص السليم بأربع حالات. +After being created by an Indexer a healthy allocation goes through four states. -- ** نشط ** - بمجرد إنشاء تخصيص على السلسلة (\[allocateFrom()\](https://github.com/graphprotocol/contracts/blob/master/contracts/staking/ Staking.sol # L873)) فهذا يعتبر ** نشطا **. يتم تخصيص جزء من حصة المفهرس الخاصة و / أو الحصة المفوضة لنشر subgraph ، مما يسمح لهم بالمطالبة بمكافآت الفهرسة وتقديم الاستعلامات لنشر ال subgraph. يدير وكيل المفهرس indexer agent إنشاء عمليات التخصيص بناء على قواعد المفهرس. +- **Active** - Once an allocation is created on-chain ([allocateFrom()](https://github.com/graphprotocol/contracts/blob/master/contracts/staking/Staking.sol#L873)) it is considered **active**. A portion of the Indexer's own and/or delegated stake is allocated towards a subgraph deployment, which allows them to claim indexing rewards and serve queries for that subgraph deployment. The Indexer agent manages creating allocations based on the Indexer rules. -- **Closed** - An indexer is free to close an allocation once 1 epoch has passed ([closeAllocation()](https://github.com/graphprotocol/contracts/blob/master/contracts/staking/Staking.sol#L873)) or their indexer agent will automatically close the allocation after the **maxAllocationEpochs** (currently 28 days). عندما يتم إغلاق تخصيص بإثبات صالح للفهرسة (POI) ، يتم توزيع مكافآت الفهرسة الخاصة به على المفهرس والمفوضين (انظر "كيف يتم توزيع المكافآت؟" أدناه لمعرفة المزيد). +- **Closed** - An Indexer is free to close an allocation once 1 epoch has passed ([closeAllocation()](https://github.com/graphprotocol/contracts/blob/master/contracts/staking/Staking.sol#L873)) or their Indexer agent will automatically close the allocation after the **maxAllocationEpochs** (currently 28 days). When an allocation is closed with a valid proof of indexing (POI) their indexing rewards are distributed to the Indexer and its Delegators (see "how are rewards distributed?" below to learn more). -- ** مكتمل** - بمجرد إغلاق التخصيص ، توجد فترة اعتراض يتم بعدها اعتبار التخصيص ** مكتملا** ويكون خصومات رسوم الاستعلام متاحة للمطالبة بها (claim()). وكيل المفهرس indexer agent يراقب الشبكة لاكتشاف التخصيصات ** المكتملة ** ويطالب بها إذا كانت أعلى من العتبة (واختياري) ، ** عتبة-مطالبة-التخصيص **. +- **Finalized** - Once an allocation has been closed there is a dispute period after which the allocation is considered **finalized** and it's query fee rebates are available to be claimed (claim()). The Indexer agent monitors the network to detect **finalized** allocations and claims them if they are above a configurable (and optional) threshold, **—-allocation-claim-threshold**. - ** مُطالب به ** - هي الحالة النهائية للتخصيص ؛ وهي التي سلكت مجراها كمخصصة نشطة ، وتم توزيع جميع المكافآت المؤهلة وتمت المطالبة بخصومات رسوم الاستعلام. + +Indexers are recommended to utilize offchain syncing functionality to sync subgraph deployments to chainhead before creating the allocation on-chain. This feature is especially useful for subgraphs that may take longer than 28 epochs to sync or have some chances of failing undeterministically. diff --git a/website/pages/ar/network/overview.mdx b/website/pages/ar/network/overview.mdx index c381302f5c4b..5e530fe7fab5 100644 --- a/website/pages/ar/network/overview.mdx +++ b/website/pages/ar/network/overview.mdx @@ -1,15 +1,15 @@ --- -title: نظرة عامة حول الشبكة +title: Network Overview --- شبكة The Graph هو بروتوكول فهرسة لامركزي لتنظيم بيانات الـ blockchain. التطبيقات تستخدم GraphQL للاستعلام عن APIs المفتوحة والتي تسمى subgraphs ، لجلب البيانات المفهرسة على الشبكة. باستخدام The Graph ، يمكن للمطورين إنشاء تطبيقات بدون خادم تعمل بالكامل على البنية الأساسية العامة. -> عنوان GRT Token: [0xc944e90c64b2c07662a292be6244bdf05cda44a7](https://etherscan.io/token/0xc944e90c64b2c07662a292be6244bdf05cda44a7) - ## نظره عامة شبكة TheGraph تتكون من مفهرسين (Indexers) ومنسقين (Curators) ومفوضين (Delegator) حيث يقدمون خدمات للشبكة ويقدمون البيانات لتطبيقات Web3. حيث يتم استخدام تلك التطبيقات والبيانات من قبل المستهلكين. ![اقتصاد الـ Token](/img/Network-roles@2x.png) -لضمان الأمن الاقتصادي لشبكة The Graph وسلامة البيانات التي يتم الاستعلام عنها ، يقوم المشاركون بـ stake لـ Graph Tokens (GRT). GRT رمزه ERC-20 على Ethereum blockchain ، يستخدم لمحاصصة (allocate) الموارد في الشبكة. المفوضون والمنسقون والمفهرسون النشطون يقدمون الخدمات لذلك يمكنهم الحصول على عوائد من الشبكة ، بما يتناسب مع حجم العمل الذي يؤدونه وحصة GRT الخاصة بهم. +To ensure economic security of The Graph Network and the integrity of data being queried, participants stake and use Graph Tokens ([GRT](/tokenomics)). GRT is a work utility token that is an ERC-20 used to allocate resources in the network. + +Active Indexers, Curators and Delegators can provide services and earn income from the network, proportional to the amount of work they perform and their GRT stake. diff --git a/website/pages/ar/operating-graph-node.mdx b/website/pages/ar/operating-graph-node.mdx new file mode 100644 index 000000000000..5c8c8278efa6 --- /dev/null +++ b/website/pages/ar/operating-graph-node.mdx @@ -0,0 +1,372 @@ +--- +title: Operating Graph Node +--- + +Graph Node is the component which indexes subgraphs, and makes the resulting data available to query via a GraphQL API. As such it is central to the indexer stack, and correct operation of Graph Node is crucial to running a successful indexer. + +This provides a contextual overview of Graph Node, and some of the more advanced options available to indexers. Detailed documentation and instructions can be found in the [Graph Node repository](https://github.com/graphprotocol/graph-node). + +## Graph Node + +[Graph Node](https://github.com/graphprotocol/graph-node) is the reference implementation for indexing Subgraphs on The Graph Network, connecting to blockchain clients, indexing subgraphs and making indexed data available to query. + +Graph Node (and the whole indexer stack) can be run on bare metal, or in a cloud environment. This flexibility of the central indexing component is crucial to the robustness of The Graph Protocol. Similarly, Graph Node can be [built from source](https://github.com/graphprotocol/graph-node), or indexers can use one of the [provided Docker Images](https://hub.docker.com/r/graphprotocol/graph-node). + +#### PostgreSQL database + +The main store for the Graph Node, this is where subgraph data is stored, as well as metadata about subgraphs, and subgraph-agnostic network data such as the block cache, and eth_call cache. + +#### Network clients + +In order to index a network, Graph Node needs access to a network client via an EVM-compatible JSON-RPC API. This RPC may connect to a single client or it could be a more complex setup that load balances across multiple. + +While some subgraphs may just require a full node, some may have indexing features which require additional RPC functionality. Specifically subgraphs which make `eth_calls` as part of indexing will require an archive node which supports [EIP-1898](https://eips.ethereum.org/EIPS/eip-1898), and subgraphs with `callHandlers`, or `blockHandlers` with a `call` filter, require `trace_filter` support ([see trace module documentation here](https://openethereum.github.io/JSONRPC-trace-module)). + +**Upcoming: Network Firehoses** - a Firehose is a gRPC service providing an ordered, yet fork-aware, stream of blocks, developed by The Graph's core developers to better support performant indexing at scale. This is not currently an indexer requirement, but Indexers are encouraged to familiarise themselves with the technology, ahead of full network support. Learn more about the Firehose [here](https://firehose.streamingfast.io/). + +#### IPFS Nodes + +Subgraph deployment metadata is stored on the IPFS network. The Graph Node primarily accesses the IPFS node during subgraph deployment to fetch the subgraph manifest and all linked files. Network indexers do not need to host their own IPFS node. An IPFS node for the network is hosted at https://ipfs.network.thegraph.com. + +#### Prometheus metrics server + +To enable monitoring and reporting, Graph Node can optionally log metrics to a Prometheus metrics server. + +### ابدأ من المصدر + +#### متطلبات التثبيت + +- **Rust** + +- **PostgreSQL** + +- **IPFS** + +- **متطلبات إضافية لمستخدمي Ubuntu **- لتشغيل عقدة الرسم البياني على Ubuntu ، قد تكون هناك حاجة إلى بعض الحزم الإضافية. + +```sh +sudo apt-get install -y clang libpg-dev libssl-dev pkg-config +``` + +#### Setup + +1. شغل سيرفر قاعدة بيانات PostgreSQL + +```sh +initdb -D .postgres +pg_ctl -D .postgres -l logfile start +createdb graph-node +``` + +2. استنسخ [ Graph Node ](https://github.com/graphprotocol/graph-node) وابني المصدر عن طريق تشغيل `cargo build` + +3. ابدأ Graph Node: + +```sh +cargo run -p graph-node --release -- \ + --postgres-url postgresql://[USERNAME]:[PASSWORD]@localhost:5432/graph-node \ + --ethereum-rpc [NETWORK_NAME]:[URL] \ + --ipfs https://ipfs.network.thegraph.com +``` + +### الشروع في استخدام Docker + +#### المتطلبات الأساسية + +- **Ethereum node** - By default, the docker compose setup will use mainnet: [http://host.docker.internal:8545](http://host.docker.internal:8545) to connect to the Ethereum node on your host machine. You can replace this network name and url by updating `docker-compose.yml`. + +#### Setup + +1. انسخ Graph Node وانتقل إلى دليل Docker: + +```sh +git clone http://github.com/graphprotocol/graph-node +cd graph-node/docker +``` + +2. For linux users only - Use the host IP address instead of `host.docker.internal` in the `docker-compose.yml`using the included script: + +```sh +./setup.sh +``` + +3. ابدأ Graph Node محلية والتي ستتصل ب Ethereum endpoint الخاصة بك: + +```sh +docker-compose up +``` + +### Getting started with Kubernetes + +A complete Kubernetes example configuration can be found in the [indexer repository](https://github.com/graphprotocol/indexer/tree/main/k8s). + +### Ports + +When it is running Graph Node exposes the following ports: + +| المنفذ | الغرض | المسار | CLI Argument | متغيرات البيئة | +| --- | --- | --- | --- | --- | +| 8000 | GraphQL HTTP server
(for subgraph queries) | /subgraphs/id/...

/subgraphs/name/.../... | http-port-- | - | +| 8001 | GraphQL WS
(for subgraph subscriptions) | /subgraphs/id/...

/subgraphs/name/.../... | ws-port-- | - | +| 8020 | JSON-RPC
(for managing deployments) | / | admin-port-- | - | +| 8030 | Subgraph indexing status API | /graphql | index-node-port-- | - | +| 8040 | Prometheus metrics | /metrics | metrics-port-- | - | + +> **Important**: Be careful about exposing ports publicly - **administration ports** should be kept locked down. This includes the the Graph Node JSON-RPC endpoint. + +# Advanced Graph Node configuration + +At its simplest, Graph Node can be operated with a single instance of Graph Node, a single PostgreSQL database, an IPFS node, and the network clients as required by the subgraphs to be indexed. + +This setup can be scaled horizontally, by adding multiple Graph Nodes, and multiple databases to support those Graph Nodes. Advanced users may want to take advantage of some of the horizontal scaling capabilities of Graph Node, as well as some of the more advanced configuration options, via the `config.toml` file and Graph Node's environment variables. + +## config.toml + +A [TOML](https://toml.io/en/) configuration file can be used to set more complex configurations than those exposed in the CLI. The location of the file is passed with the --config command line switch. + +> When using a configuration file, it is not possible to use the options --postgres-url, --postgres-secondary-hosts, and --postgres-host-weights. + +A minimal `config.toml` file can be provided; the following file is equivalent to using the --postgres-url command line option: + +```toml +[store] +[store.primary] +connection="<.. postgres-url argument ..>" +[deployment] +[[deployment.rule]] +indexers = [ "<.. list of all indexing nodes ..>" ] +``` + +Full documentation of `config.toml` can be found in the [Graph Node docs](https://github.com/graphprotocol/graph-node/blob/master/docs/config.md). + +### Multiple Graph Nodes + +Graph Node indexing can scale horizontally, running multiple instances of Graph Node to split indexing and querying across different nodes. This can be done simply by running Graph Nodes configured with a different `node_id` on startup (e.g. in the Docker Compose file), which can then be used in the `config.toml` file to specify [dedicated query nodes](#dedicated-query-nodes), [block ingestors](#dedicated-block-ingestor), and splitting subgraphs across nodes with [deployment rules](#deployment-rules). + +> Note that multiple Graph Nodes can all be configured to use the same database, which itself can be horizontally scaled via sharding. + +### Deployment rules + +Given multiple Graph Nodes, it is necessary to manage deployment of new subgraphs so that the same subgraph isn't being indexed by two different nodes, which would lead to collisions. This can be done by using deployment rules, which can also specify which `shard` a subgraph's data should be stored in, if database sharding is being used. Deployment rules can match on the subgraph name and the network that the deployment is indexing in order to make a decision. + +Example deployment rule configuration: + +```toml +[deployment] +[[deployment.rule]] +match = { name = "(vip|important)/.*" } +shard = "vip" +indexers = [ "index_node_vip_0", "index_node_vip_1" ] +[[deployment.rule]] +match = { network = "kovan" } +# No shard, so we use the default shard called 'primary' +indexers = [ "index_node_kovan_0" ] +[[deployment.rule]] +match = { network = [ "xdai", "poa-core" ] } +indexers = [ "index_node_other_0" ] +[[deployment.rule]] +# There's no 'match', so any subgraph matches +shards = [ "sharda", "shardb" ] +indexers = [ + "index_node_community_0", + "index_node_community_1", + "index_node_community_2", + "index_node_community_3", + "index_node_community_4", + "index_node_community_5" + ] +``` + +Read more about deployment rules [here](https://github.com/graphprotocol/graph-node/blob/master/docs/config.md#controlling-deployment). + +### Dedicated query nodes + +Nodes can be configured to explicitly be query nodes by including the following in the configuration file: + +```toml +[general] +query = "" +``` + +Any node whose --node-id matches the regular expression will be set up to only respond to queries. + +### Database scaling via sharding + +For most use cases, a single Postgres database is sufficient to support a graph-node instance. When a graph-node instance outgrows a single Postgres database, it is possible to split the storage of graph-node's data across multiple Postgres databases. All databases together form the store of the graph-node instance. Each individual database is called a shard. + +Shards can be used to split subgraph deployments across multiple databases, and can also be used to use replicas to spread query load across databases. This includes configuring the number of available database connections each `graph-node` should keep in its connection pool for each database, which becomes increasingly important as more subgraphs are being indexed. + +Sharding becomes useful when your existing database can't keep up with the load that Graph Node puts on it, and when it's not possible to increase the database size anymore. + +> It is generally better make a single database as big as possible, before starting with shards. One exception is where query traffic is split very unevenly between subgraphs; in those situations it can help dramatically if the high-volume subgraphs are kept in one shard and everything else in another because that setup makes it more likely that the data for the high-volume subgraphs stays in the db-internal cache and doesn't get replaced by data that's not needed as much from low-volume subgraphs. + +In terms of configuring connections, start with max_connections in postgresql.conf set to 400 (or maybe even 200) and look at the store_connection_wait_time_ms and store_connection_checkout_count Prometheus metrics. Noticeable wait times (anything above 5ms) is an indication that there are too few connections available; high wait times there will also be caused by the database being very busy (like high CPU load). However if the database seems otherwise stable, high wait times indicate a need to increase the number of connections. In the configuration, how many connections each graph-node instance can use is an upper limit, and Graph Node will not keep connections open if it doesn't need them. + +Read more about store configuration [here](https://github.com/graphprotocol/graph-node/blob/master/docs/config.md#configuring-multiple-databases). + +### Dedicated block ingestion + +If there are multiple nodes configured, it will be necessary to specify one node which is responsible for ingestion of new blocks, so that all configured index nodes aren't polling the chain head. This is done as part of the `chains` namespace, specifying the `node_id` to be used for block ingestion: + +```toml +[chains] +ingestor = "block_ingestor_node" +``` + +### Supporting multiple networks + +The Graph Protocol is increasing the number of networks supported for indexing rewards, and there exist many subgraphs indexing unsupported networks which an indexer would like to process. The `config.toml` file allows for expressive and flexible configuration of: + +- Multiple networks +- Multiple providers per network (this can allow splitting of load across providers, and can also allow for configuration of full nodes as well as archive nodes, with Graph Node preferring cheaper providers if a given workload allows). +- Additional provider details, such as features, authentication and the type of provider (for experimental Firehose support) + +The `[chains]` section controls the ethereum providers that graph-node connects to, and where blocks and other metadata for each chain are stored. The following example configures two chains, mainnet and kovan, where blocks for mainnet are stored in the vip shard and blocks for kovan are stored in the primary shard. The mainnet chain can use two different providers, whereas kovan only has one provider. + +```toml +[chains] +ingestor = "block_ingestor_node" +[chains.mainnet] +shard = "vip" +provider = [ + { label = "mainnet1", url = "http://..", features = [], headers = { Authorization = "Bearer foo" } }, + { label = "mainnet2", url = "http://..", features = [ "archive", "traces" ] } +] +[chains.kovan] +shard = "primary" +provider = [ { label = "kovan", url = "http://..", features = [] } ] +``` + +Read more about provider configuration [here](https://github.com/graphprotocol/graph-node/blob/master/docs/config.md#configuring-ethereum-providers). + +## Environment variables + +Graph Node supports a range of environment variables which can enable features, or change Graph Node behaviour. These are documented [here](https://github.com/graphprotocol/graph-node/blob/master/docs/environment-variables.md). + +## Continuous deployment + +Users who are operating a scaled indexing setup with advanced configuration may benefit from managing their Graph Nodes with Kubernetes. + +- The indexer repository has an [example Kubernetes reference](https://github.com/graphprotocol/indexer/tree/main/k8s) +- [Launchpad](https://docs.graphops.xyz/launchpad/intro) is a toolkit for running a Graph Protocol Indexer on Kubernetes maintained by GraphOps. It provides a set of Helm charts and a CLI to manage a Graph Node deployment. + +## Managing Graph Node + +Given a running Graph Node (or Graph Nodes!), the challenge is then to manage deployed subgraphs across those nodes. Graph Node surfaces a range of tools to help with managing subgraphs. + +### Logging + +Graph Node's logs can provide useful information for debugging and optimisation of Graph Node and specific subgraphs. Graph Node supports different log levels via the `GRAPH_LOG` environment variable, with the following levels: error, warn, info, debug or trace. + +In addition setting `GRAPH_LOG_QUERY_TIMING` to `gql` provides more details about how GraphQL queries are running (though this will generate a large volume of logs). + +### Monitoring & alerting + +Graph Node provides the metrics via Prometheus endpoint on 8040 port by default. Grafana can then be used to visualise these metrics. + +The indexer repository provides an [example Grafana configuration](https://github.com/graphprotocol/indexer/blob/main/k8s/base/grafana.yaml). + +### Graphman + +`graphman` is a maintenance tool for Graph Node, helping with diagnosis and resolution of different day-to-day and exceptional tasks. + +The graphman command is included in the official containers, and you can docker exec into your graph-node container to run it. It requires a `config.toml` file. + +Full documentation of `graphman` commands is available in the Graph Node repository. See \[/docs/graphman.md\] (https://github.com/graphprotocol/graph-node/blob/master/docs/graphman.md) in the Graph Node `/docs` + +## Working with subgraphs + +### Indexing status API + +Available on port 8030/graphql by default, the indexing status API exposes a range of methods for checking indexing status for different subgraphs, checking proofs of indexing, inspecting subgraph features and more. + +The full schema is available [here](https://github.com/graphprotocol/graph-node/blob/master/server/index-node/src/schema.graphql). + +### Indexing performance + +There are three separate parts of the indexing process: + +- Fetching events of interest from the provider +- Processing events in order with the appropriate handlers (this can involve calling the chain for state, and fetching data from the store) +- Writing the resulting data to the store + +These stages are pipelined (i.e. they can be executed in parallel), but they are dependent on one another. Where subgraphs are slow to index, the underlying cause will depend on the specific subgraph. + +Common causes of indexing slowness: + +- Time taken to find relevant events from the chain (call handlers in particular can be slow, given the reliance on `trace_filter`) +- Making large numbers of `eth_calls` as part of handlers +- A large amount of store interaction during execution +- A large amount of data to save to the store +- A large number of events to process +- Slow database connection time, for crowded nodes +- The provider itself falling behind the chain head +- Slowness in fetching new receipts at the chain head from the provider + +Subgraph indexing metrics can help diagnose the root cause of indexing slowness. In some cases, the problem lies with the subgraph itself, but in others, improved network providers, reduced database contention and other configuration improvements can markedly improve indexing performance. + +### Failed subgraphs + +During indexing subgraphs might fail, if they encounter data that is unexpected, some component not working as expected, or if there is some bug in the event handlers or configuration. There are two general types of failure: + +- Deterministic failures: these are failures which will not be resolved with retries +- Non-deterministic failures: these might be down to issues with the provider, or some unexpected Graph Node error. When a non-deterministic failure occurs, Graph Node will retry the failing handlers, backing off over time. + +In some cases a failure might be resolvable by the indexer (for example if the error is a result of not having the right kind of provider, adding the required provider will allow indexing to continue). However in others, a change in the subgraph code is required. + +> Deterministic failures are considered "final", with a Proof of Indexing generated for the failing block, while non-determinstic failures are not, as the subgraph may manage to "unfail" and continue indexing. In some cases, the non-deterministic label is incorrect, and the subgraph will never overcome the error; such failures should be reported as issues on the Graph Node repository. + +### Block and call cache + +Graph Node caches certain data in the store in order to save refetching from the provider. Blocks are cached, as are the results of `eth_calls` (the latter being cached as of a specific block). This caching can dramatically increase indexing speed during "resyncing" of a slightly altered subgraph. + +However in some instances, if an Ethereum node has provided incorrect data for some period, that can make its way into the cache, leading to incorrect data or failed subgraphs. In this case indexers can use `graphman` to clear the poisoned cache, and then rewind the affected subgraphs, which will then fetch fresh data from the (hopefully) healthy provider. + +If a block cache inconsistency is suspected, such as a tx receipt missing event: + +1. `graphman chain list` to find the chain name. +2. `graphman chain check-blocks by-number ` will check if the cached block matches the provider, and deletes the block from the cache if it doesn’t. + 1. If there is a difference, it may be safer to truncate the whole cache with `graphman chain truncate `. + 2. If the block matches the provider, then the issue can be debugged directly against the provider. + +### Querying issues and errors + +Once a subgraph has been indexed, indexers can expect to serve queries via the subgraph's dedicated query endpoint. If the indexer is hoping to serve significant query volume, a dedicated query node is recommended, and in case of very high query volumes, indexers may want to configure replica shards so that queries don't impact the indexing process. + +However even with a dedicated query node and replicas, certain queries can take a long time to execute, and in some cases increase memory usage and negatively impact the query time for other users. + +There is not one "silver bullet", but a range of tools for preventing, diagnosing and dealing with slow queries. + +#### Query caching + +Graph Node caches GraphQL queries by default, which can significantly reduce database load. This can be further configured with the `GRAPH_QUERY_CACHE_BLOCKS` and `GRAPH_QUERY_CACHE_MAX_MEM` settings - read more [here](https://github.com/graphprotocol/graph-node/blob/master/docs/environment-variables.md#graphql-caching). + +#### Analysing queries + +Problematic queries most often surface in one of two ways. In some cases, users themselves report that a given query is slow. In that case the challenge is to diagnose the reason for the slowness - whether it is a general issue, or specific to that subgraph or query. And then of course to resolve it, if possible. + +In other cases, the trigger might be high memory usage on a query node, in which case the challenge is first to identify the query causing the issue. + +Indexers can use [qlog](https://github.com/graphprotocol/qlog/) to process and summarize Graph Node's query logs. `GRAPH_LOG_QUERY_TIMING` can also be enabled to help identify and debug slow queries. + +Given a slow query, indexers have a few options. Of course they can alter their cost model, to significantly increase the cost of sending the problematic query. This may result in a reduction in the frequency of that query. However this often doesn't resolve the root cause of the issue. + +#### Account-like optimisation + +Database tables that store entities seem to generally come in two varieties: 'transaction-like', where entities, once created, are never updated, i.e., they store something akin to a list of financial transactions, and 'account-like' where entities are updated very often, i.e., they store something like financial accounts that get modified every time a transaction is recorded. Account-like tables are characterized by the fact that they contain a large number of entity versions, but relatively few distinct entities. Often, in such tables the number of distinct entities is 1% of the total number of rows (entity versions) + +For account-like tables, `graph-node` can generate queries that take advantage of details of how Postgres ends up storing data with such a high rate of change, namely that all of the versions for recent blocks are in a small subsection of the overall storage for such a table. + +The command `graphman stats show shows, for each entity type/table in a deployment, how many distinct entities, and how many entity versions each table contains. That data is based on Postgres-internal estimates, and is therefore necessarily imprecise, and can be off by an order of magnitude. A `-1` in the `entities` column means that Postgres believes that all rows contain a distinct entity. + +In general, tables where the number of distinct entities are less than 1% of the total number of rows/entity versions are good candidates for the account-like optimization. When the output of `graphman stats show` indicates that a table might benefit from this optimization, running `graphman stats show ` will perform a full count of the table - that can be slow, but gives a precise measure of the ratio of distinct entities to overall entity versions. + +Once a table has been determined to be account-like, running `graphman stats account-like .
` will turn on the account-like optimization for queries against that table. The optimization can be turned off again with `graphman stats account-like --clear .
` It takes up to 5 minutes for query nodes to notice that the optimization has been turned on or off. After turning the optimization on, it is necessary to verify that the change does not in fact make queries slower for that table. If you have configured Grafana to monitor Postgres, slow queries would show up in `pg_stat_activity`in large numbers, taking several seconds. In that case, the optimization needs to be turned off again. + +For Uniswap-like subgraphs, the `pair` and `token` tables are prime candidates for this optimization, and can have a dramatic effect on database load. + +### Removing subgraphs + +> This is new functionality, which will be available in Graph Node 0.29.x + +At some point an indexer might want to remove a given subgraph. This can be easily done via `graphman drop`, which deletes a deployment and all it's indexed data. The deployment can be specified as either a subgraph name, an IPFS hash `Qm..`, or the database namespace `sgdNNN`. Further documentation is available [here](https://github.com/graphprotocol/graph-node/blob/master/docs/graphman.md#-drop). diff --git a/website/pages/ar/publishing/publishing-a-subgraph.mdx b/website/pages/ar/publishing/publishing-a-subgraph.mdx index 0207c3172a02..fb705c249d33 100644 --- a/website/pages/ar/publishing/publishing-a-subgraph.mdx +++ b/website/pages/ar/publishing/publishing-a-subgraph.mdx @@ -1,27 +1,33 @@ --- -title: نشر Subgraph للشبكة اللامركزية +title: Publishing a Subgraph to the Decentralized Network --- -بمجرد أن الـ subgraph الخاص بك [قد تم نشره لـ Subgraph Studio](/deploying/deploying-a-subgraph-to-studio) ، وقمت باختباره ، وأصبحت جاهزا لوضعه في الإنتاج ، يمكنك بعد ذلك نشره للشبكة اللامركزية. +Once your subgraph has been [deployed to the Subgraph Studio](/deploying/deploying-a-subgraph-to-studio), you have tested it out, and are ready to put it into production, you can then publish it to the decentralized network. -يؤدي نشر Subgraph على الشبكة اللامركزية إلى الإتاحة [ للمنسقين ](/network/curating) لبدء التنسيق، و [ للمفهرسين](/network/indexing) لبدء الفهرسة. +Publishing a Subgraph to the decentralized network makes it available for [Curators](/network/curating) to begin curating on it, and [Indexers](/network/indexing) to begin indexing it. للحصول على إرشادات حول كيفية نشر subgraph على الشبكة اللامركزية ، راجع [ هذا الفيديو ](https://youtu.be/HfDgC2oNnwo؟t=580). -### الشبكات - -تدعم الشبكة اللامركزية حاليا كلا من Rinkeby و Ethereum Mainnet. +You can find the list of the supported networks [Here](/developing/supported-networks). ### نشر subgraph -يمكن نشر الـ Subgraphs على الشبكة اللامركزية مباشرة من Subgraph Studio dashboard بالنقر فوق الزر ** Publish **. بمجرد نشر الـ subgraph ، فإنه سيكون متاحا للعرض في [ Graph Explorer ](https://thegraph.com/explorer/). +يمكن نشر الـ Subgraphs على الشبكة اللامركزية مباشرة من Subgraph Studio dashboard بالنقر فوق الزر ** ينشر **. بمجرد نشر الـ subgraph ، فإنه سيكون متاحا للعرض في [ Graph Explorer ](https://thegraph.com/explorer/). -- يمكن لـ Subgraphs المنشور على Rinkeby فهرسة البيانات والاستعلام عنها من شبكة Rinkeby أو Ethereum Mainnet. +- Subgraphs can be published to Goerli, Arbitrum goerli, Arbitrum One, or Ethereum mainnet. -- يمكن لـ Subgraphs المنشور على Ethereum Mainnet فقط فهرسة البيانات والاستعلام عنها من Ethereum Mainnet ، مما يعني أنه لا يمكنك نشر الـ subgraphs على الشبكة اللامركزية الرئيسية التي تقوم بفهرسة بيانات testnet والاستعلام عنها. +- Regardless of the network the subgraph was published on, it can index data on any of the [supported networks](/developing/supported-networks). - عند نشر نسخة جديدة لـ subgraph حالي ، تنطبق عليه نفس القواعد أعلاه. +### Curating your subgraph + +> It is recommended that you curate your own subgraph with 10,000 GRT to ensure that it is indexed and available for querying as soon as possible. + +Subgraph Studio enables you to be the first to curate your subgraph by adding GRT to your subgraph's curation pool in the same transaction. When publishing your subgraph, make sure to check the button that says, "Be the first to signal on this subgraph." + +![Curation Pool](/img/curate-own-subgraph-tx.png) + ### تحديث بيانات الـ subgraph المنشور -بمجرد نشر الـ subgraph الخاص بك على الشبكة اللامركزية ، يمكنك تعديل البيانات الوصفية في أي وقت عن طريق إجراء التحديث في Subgraph Studio dashboard لـ subgraph. بعد حفظ التغييرات ونشر تحديثاتك على الشبكة ، ستنعكس في the Graph Explorer. لن يؤدي هذا إلى إنشاء إصدار جديد ، لأن النشر الخاص بك لم يتغير. +Once your subgraph has been published to the decentralized network, you can modify the metadata at any time by making the update in the Subgraph Studio dashboard of the subgraph. After saving the changes and publishing your updates to the network, they will be reflected in The Graph Explorer. This won’t create a new version, as your deployment hasn’t changed. diff --git a/website/pages/ar/querying/graphql-api.mdx b/website/pages/ar/querying/graphql-api.mdx index 87e64dc3603d..5eccf16101ee 100644 --- a/website/pages/ar/querying/graphql-api.mdx +++ b/website/pages/ar/querying/graphql-api.mdx @@ -49,6 +49,25 @@ title: GraphQL API } ``` +#### Example for nested entity sorting + +As of Graph Node [`v0.30.0`](https://github.com/graphprotocol/graph-node/releases/tag/v0.30.0) entities can be sorted on the basis of nested entities. + +In the following example, we sort the tokens by the name of their owner: + +```graphql +{ + tokens(orderBy: owner__name, orderDirection: asc) { + id + owner { + name + } + } +} +``` + +> Currently you can sort by one-level deep `String` or `ID` types on `@entity` and `@derivedFrom` fields. Unfortunately, [sorting by interfaces on one level-deep entities](https://github.com/graphprotocol/graph-node/pull/4058), sorting by fields which are arrays and nested entities is not yet supported. + ### ترقيم الصفحات عند الاستعلام عن مجموعة ، يمكن استخدام البارامتر `first` لترقيم الصفحات من بداية المجموعة. من الجدير بالذكر أن ترتيب الفرز الافتراضي يكون حسب الـ ID بترتيب رقمي تصاعدي ، وليس حسب وقت الإنشاء. @@ -57,7 +76,7 @@ title: GraphQL API الاستعلامات يجب أن تتجنب استخدام قيم `skip` كبيرة جدا نظرا لأنها تؤدي بشكل عام أداء ضعيفا. لجلب عدد كبير من العناصر ، من الأفضل تصفح الكيانات بناء على صفة كما هو موضح في المثال الأخير. -#### مثال +#### Example using `first` استعلم عن أول 10 توكن: @@ -72,7 +91,7 @@ title: GraphQL API للاستعلام عن مجموعات الكيانات في منتصف المجموعة ، يمكن استخدام البارامتر `skip` بالاصافة لبارامتر `first` لتخطي عدد محدد من الكيانات بدءا من بداية المجموعة. -#### مثال +#### Example using `first` and `skip` الاستعلام عن 10 كيانات `Token` ،بإزاحة 10 أماكن من بداية المجموعة: @@ -85,7 +104,7 @@ title: GraphQL API } ``` -#### مثال +#### Example using `first` and `id_ge` إذا احتاج العميل إلى جلب عدد كبير من الكيانات ، فمن الأفضل أن تستند الاستعلامات إلى إحدى الصفات والفلترة حسب تلك الصفة. على سبيل المثال ، قد يجلب العميل عددا كبيرا من التوكن باستخدام هذا الاستعلام: @@ -104,7 +123,7 @@ query manyTokens($lastID: String) { يمكنك استخدام البارامتر `where` في الاستعلام لتصفية الخصائص المختلفة. يمكنك الفلترة على قيم متعددة ضمن البارامتر `where`. -#### مثال +#### Example using `where` تحديات الاستعلام مع نتيجة `failed`: @@ -122,7 +141,7 @@ query manyTokens($lastID: String) { يمكنك استخدام لواحق مثل `gt` ، `_lte_` لمقارنة القيم: -#### مثال +#### Example for range filtering ```graphql { @@ -134,33 +153,134 @@ query manyTokens($lastID: String) { } ``` -القائمة الكاملة للواحق البارامترات: +#### Example for block filtering + +You can also filter entities by the `_change_block(number_gte: Int)` - this filters entities which were updated in or after the specified block. + +This can be useful if you are looking to fetch only entities which have changed, for example since the last time you polled. Or alternatively it can be useful to investigate or debug how entities are changing in your subgraph (if combined with a block filter, you can isolate only entities that changed in a specific block). + +```graphql +{ + applications(where: { _change_block: { number_gte: 100 } }) { + id + whitelisted + deposit + } +} +``` + +#### Example for nested entity filtering + +Filtering on the basis of nested entities is possible in the fields with the `_` suffix. + +This can be useful if you are looking to fetch only entities whose child-level entities meet the provided conditions. + +```graphql +{ + challenges(where: { application_: { id: 1 } }) { + challenger + outcome + application { + id + } + } +} +``` + +#### Logical operators + +As of Graph Node [`v0.30.0`](https://github.com/graphprotocol/graph-node/releases/tag/v0.30.0) you can group multiple parameters in the same `where` argument using the `and` or the `or` operators to filter results based on more than one criteria. + +##### `AND` Operator + +In the following example, we are filtering for challenges with `outcome` `succeeded` and `number` greater than or equal to `100`. + +```graphql +{ + challenges(where: { and: [{ number_gte: 100 }, { outcome: "succeeded" }] }) { + challenger + outcome + application { + id + } + } +} +``` + +> **Syntactic sugar:** You can simplify the above query by removing the `and` operator by passing a sub-expression separated by commas. +> +> ```graphql +> { +> challenges(where: { number_gte: 100, outcome: "succeeded" }) { +> challenger +> outcome +> application { +> id +> } +> } +> } +> ``` + +##### `OR` Operator + +In the following example, we are filtering for challenges with `outcome` `succeeded` or `number` greater than or equal to `100`. ```graphql -not_ -gt_ -lt_ -gte_ -lte_ -in_ -not_in_ -contains_ -not_contains_ -starts_with_ -ends_with_ -not_starts_with_ -not_ends_with_ +{ + challenges(where: { or: [{ number_gte: 100 }, { outcome: "succeeded" }] }) { + challenger + outcome + application { + id + } + } +} ``` -يرجى ملاحظة أن بعض اللواحق مدعومة فقط لأنواع معينة. على سبيل المثال ، `Boolean` يدعم فقط `not_` و `_in` و `not_in_`. +> **Note**: When constructing queries, it is important to consider the performance impact of using the `or` operator. While `or` can be a useful tool for broadening search results, it can also have significant costs. One of the main issues with `or` is that it can cause queries to slow down. This is because `or` requires the database to scan through multiple indexes, which can be a time-consuming process. To avoid these issues, it is recommended that developers use and operators instead of or whenever possible. This allows for more precise filtering and can lead to faster, more accurate queries. + +#### All Filters + +Full list of parameter suffixes: + +``` +_ +_not +_gt +_lt +_gte +_lte +_in +_not_in +_contains +_contains_nocase +_not_contains +_not_contains_nocase +_starts_with +_starts_with_nocase +_ends_with +_ends_with_nocase +_not_starts_with +_not_starts_with_nocase +_not_ends_with +_not_ends_with_nocase +``` + +> Please note that some suffixes are only supported for specific types. For example, `Boolean` only supports `_not`, `_in`, and `_not_in`, but `_` is available only for object and interface types. + +In addition, the following global filters are available as part of `where` argument: + +```gr +_change_block(number_gte: Int) +``` ### الاستعلامات المنتقلة زمنيا -يمكنك الاستعلام عن حالة الكيانات الخاصة بك ليس فقط للكتلة الأخيرة ، والتي هي افتراضيا ، ولكن أيضا لكتلة في الماضي. يمكن تحديد الكتلة التي يجب أن يحدث فيها الاستعلام إما عن طريق رقم الكتلة أو hash الكتلة الخاص بها عن طريق تضمين وسيطة `block` في حقول المستوى الأعلى للاستعلامات. +You can query the state of your entities not just for the latest block, which is the default, but also for an arbitrary block in the past. The block at which a query should happen can be specified either by its block number or its block hash by including a `block` argument in the toplevel fields of queries. -لن تتغير نتيجة مثل هذا الاستعلام بمرور الوقت ، أي أن الاستعلام في كتلة سابقة معينة سيعيد نفس النتيجة بغض النظر عن وقت تنفيذها ، باستثناء أنه إذا قمت بالاستعلام في كتلة قريبة جدا من رأس سلسلة Ethereum ، قد تتغير النتيجة إذا تبين أن هذه الكتلة ليست في السلسلة الرئيسية وتمت إعادة تنظيم السلسلة. بمجرد اعتبار الكتلة نهائية ، لن تتغير نتيجة الاستعلام. +The result of such a query will not change over time, i.e., querying at a certain past block will return the same result no matter when it is executed, with the exception that if you query at a block very close to the head of the chain, the result might change if that block turns out to not be on the main chain and the chain gets reorganized. Once a block can be considered final, the result of the query will not change. -لاحظ أن التنفيذ الحالي لا يزال يخضع لقيود معينة قد تنتهك هذه الضمانات. لا يمكن للتنفيذ دائما أن يخبرنا أن hash كتلة معينة ليست في السلسلة الرئيسية ، أو أن نتيجة استعلام لكتلة عن طريق hash الكتلة لا يمكن اعتبارها نهائية ومع ذلك قد تتأثر بإعادة تنظيم الكتلة التي تعمل بشكل متزامن مع الاستعلام. لا تؤثر نتائج الاستعلامات عن طريق hash الكتلة عندما تكون الكتلة نهائية ومعروفة بأنها موجودة في السلسلة الرئيسية. [ تشرح هذه المشكلة ](https://github.com/graphprotocol/graph-node/issues/1405) ماهية هذه القيود بالتفصيل. +Note that the current implementation is still subject to certain limitations that might violate these gurantees. The implementation can not always tell that a given block hash is not on the main chain at all, or that the result of a query by block hash for a block that can not be considered final yet might be influenced by a block reorganization running concurrently with the query. They do not affect the results of queries by block hash when the block is final and known to be on the main chain. [This issue](https://github.com/graphprotocol/graph-node/issues/1405) explains what these limitations are in detail. #### مثال @@ -176,7 +296,7 @@ not_ends_with_ } ``` -سيعود هذا الاستعلام بكيانات `Challenge` وكيانات `Application` المرتبطة بها ، كما كانت موجودة مباشرة بعد معالجة رقم الكتلة 8،000،000. +This query will return `Challenge` entities, and their associated `Application` entities, as they existed directly after processing block number 8,000,000. #### مثال @@ -192,26 +312,26 @@ not_ends_with_ } ``` -سيعود هذا الاستعلام بكيانات `Challenge` وكيانات `Application` المرتبطة بها ، كما كانت موجودة مباشرة بعد معالجة الكتلة باستخدام hash المحددة. +This query will return `Challenge` entities, and their associated `Application` entities, as they existed directly after processing the block with the given hash. -### استعلامات بحث النص الكامل(Fulltext Search) +### استعلامات بحث النص الكامل -حقول استعلام البحث عن نص كامل توفر API للبحث عن نص تعبيري يمكن إضافتها إلى مخطط الـ subgraph وتخصيصها. راجع [ تعريف حقول بحث النص الكامل ](/developing/creating-a-subgraph#defining-fulltext-search-fields) لإضافة بحث نص كامل إلى الـ subgraph الخاص بك. +Fulltext search query fields provide an expressive text search API that can be added to the subgraph schema and customized. Refer to [Defining Fulltext Search Fields](/developing/creating-a-subgraph#defining-fulltext-search-fields) to add fulltext search to your subgraph. -استعلامات البحث عن النص الكامل لها حقل واحد مطلوب ، وهو `text` ، لتوفير عبارة البحث. تتوفر العديد من عوامل النص الكامل الخاصة لاستخدامها في حقل البحث `text`. +Fulltext search queries have one required field, `text`, for supplying search terms. Several special fulltext operators are available to be used in this `text` search field. -عوامل تشغيل البحث عن النص الكامل: +Fulltext search operators: | رمز | عامل التشغيل | الوصف | | --- | --- | --- | | `&` | `And` | لدمج عبارات بحث متعددة في فلتر للكيانات التي تتضمن جميع العبارات المتوفرة | -| | | `Or` | الاستعلامات التي تحتوي على عبارات بحث متعددة مفصولة بواسطة عامل التشغيل or ستعيد جميع الكيانات المتطابقة من أي عبارة متوفرة | +| | | `أو` | الاستعلامات التي تحتوي على عبارات بحث متعددة مفصولة بواسطة عامل التشغيل or ستعيد جميع الكيانات المتطابقة من أي عبارة متوفرة | | `<->` | `Follow by` | يحدد المسافة بين كلمتين. | -| `*:` | `Prefix` | يستخدم عبارة البحث prefix للعثور على الكلمات التي تتطابق بادئتها (مطلوب حرفان.) | +| `:*` | `Prefix` | يستخدم عبارة البحث prefix للعثور على الكلمات التي تتطابق بادئتها (مطلوب حرفان.) | #### أمثلة -باستخدام العامل `or` ، سيقوم الاستعلام هذا بتصفية blog الكيانات التي تحتوي على أشكال مختلفة من "anarchism" أو "crumpet" في حقول النص الكامل الخاصة بها. +Using the `or` operator, this query will filter to blog entities with variations of either "anarchism" or "crumpet" in their fulltext fields. ```graphql { @@ -224,7 +344,7 @@ not_ends_with_ } ``` -العامل `follow by` يحدد الكلمات بمسافة محددة عن بعضها في مستندات النص-الكامل. الاستعلام التالي سيعيد جميع الـ blogs التي تحتوي على أشكال مختلفة من "decentralize" متبوعة بكلمة "philosophy" +The `follow by` operator specifies a words a specific distance apart in the fulltext documents. The following query will return all blogs with variations of "decentralize" followed by "philosophy" ```graphql { @@ -237,7 +357,7 @@ not_ends_with_ } ``` -اجمع بين عوامل تشغيل النص-الكامل لعمل فلترة أكثر تعقيدا. فمثلا باستخدام عامل تشغيل البحث pretext مع follow by ،سيتم مطابقة هذا الاستعلام بجميع كيانات الـ blog بالكلمات التي تبدأ بـ "lou" متبوعة بـ "music". +Combine fulltext operators to make more complex filters. With a pretext search operator combined with a follow by this example query will match all blog entities with words that start with "lou" followed by "music". ```graphql { @@ -252,18 +372,48 @@ not_ends_with_ ### الكيانات -يتم تعريف مخطط مصدر البيانات الخاص بك - كأنواع الكيانات والقيم والعلاقات المتاحة للاستعلام - من خلال [GraphQL Interface Definition Langauge (IDL)](https://facebook.github.io/graphql/draft/#sec-Type-System). +Graph Node implements [specification-based](https://spec.graphql.org/October2021/#sec-Validation) validation of the GraphQL queries it receives using [graphql-tools-rs](https://github.com/dotansimha/graphql-tools-rs#validation-rules), which is based on the [graphql-js reference implementation](https://github.com/graphql/graphql-js/tree/main/src/validation). Queries which fail a validation rule do so with a standard error - visit the [GraphQL spec](https://spec.graphql.org/October2021/#sec-Validation) to learn more. ## المخطط -مخططات GraphQL تحدد عموما أنواع الجذر(root) لـ `queries`, و `subscriptions` و`mutations`. يدعم The Graph فقط الـ `queries`. يتم إنشاء نوع الجذر `Query` لـ subgraph تلقائيا من مخطط GraphQL المضمن في subgraph manifest الخاص بك. +The schema of your data source--that is, the entity types, values, and relationships that are available to query--are defined through the [GraphQL Interface Definition Langauge (IDL)](https://facebook.github.io/graphql/draft/#sec-Type-System). -سيتم التعامل مع جميع أنواع GraphQL التي تحتوي على توجيهات `entity@` في مخططك على أنها كيانات ويجب أن تحتوي على حقل `ID`. +GraphQL schemas generally define root types for `queries`, `subscriptions` and `mutations`. The Graph only supports `queries`. The root `Query` type for your subgraph is automatically generated from the GraphQL schema that's included in your subgraph manifest. -> ** ملاحظة: ** الـ API الخاصة بنا لا تعرض الـ mutations لأنه يُتوقع من المطورين إصدار إجراءات مباشرة لـblockchain الأساسي من تطبيقاتهم. +> **Note:** Our API does not expose mutations because developers are expected to issue transactions directly against the underlying blockchain from their applications. ### الكيانات (Entities) -سيتم التعامل مع جميع أنواع GraphQL التي تحتوي على توجيهات `entity@` في مخططك على أنها كيانات ويجب أن تحتوي على حقل `ID`. +All GraphQL types with `@entity` directives in your schema will be treated as entities and must have an `ID` field. + +> **Note:** Currently, all types in your schema must have an `@entity` directive. In the future, we will treat types without an `@entity` directive as value objects, but this is not yet supported. + +### Subgraph Metadata + +All subgraphs have an auto-generated `_Meta_` object, which provides access to subgraph metadata. This can be queried as follows: + +```graphQL +{ + _meta(block: { number: 123987 }) { + block { + number + hash + timestamp + } + deployment + hasIndexingErrors + } +} +``` + +If a block is provided, the metadata is as of that block, if not the latest indexed block is used. If provided, the block must be after the subgraph's start block, and less than or equal to the most recently indexed block. + +`deployment` is a unique ID, corresponding to the IPFS CID of the `subgraph.yaml` file. + +`block` provides information about the latest block (taking into account any block constraints passed to \_meta): + +- hash: the hash of the block +- number: the block number +- timestamp: the timestamp of the block, if available (this is currently only available for subgraphs indexing EVM networks) -> ** ملاحظة: ** في الوقت الحالي ، يجب أن تحتوي جميع الأنواع في مخططك على توجيه `entity@`. في المستقبل ، سنتعامل مع الأنواع التي لا تحتوي على التوجيه `entity@` ككائنات، لكن هذا غير مدعوم حتى الآن. +`hasIndexingErrors` is a boolean identifying whether the subgraph encountered indexing errors at some past block diff --git a/website/pages/ar/querying/managing-api-keys.mdx b/website/pages/ar/querying/managing-api-keys.mdx index e3ab07db3693..f7de990fdf47 100644 --- a/website/pages/ar/querying/managing-api-keys.mdx +++ b/website/pages/ar/querying/managing-api-keys.mdx @@ -4,30 +4,23 @@ title: Managing your API keys Regardless of whether you’re a dapp developer or a subgraph developer, you’ll need to manage your API keys. This is important for you to be able to query subgraphs because API keys make sure the connections between application services are valid and authorized. This includes authenticating the end user and the device using the application. -The Studio will list out existing API keys, which will give you the ability to manage or delete them. - -1. The **Overview** section will allow you to: - -- Edit your key name -- Regenerate API keys -- View the current usage of the API key with stats: -- Number of queries -- Amount of GRT spent - +سيقوم Studio بسرد مفاتيح API الموجودة ، والتي ستمنحك القدرة على إدارتها أو حذفها. + +1. سيسمح لك قسم **ملخص** بما يلي: + - تعديل اسم المفتاح الخاص بك + - إعادة إنشاء مفاتيح API + - عرض الاستخدام الحالي لمفتاح API مع الإحصائيات: + - عدد الاستعلامات + - كمية GRT التي تم صرفها 2. Under **Security**, you’ll be able to opt into security settings depending on the level of control you’d like to have over your API keys. In this section, you can: - -- View and manage the domain names authorized to use your API key -- Assign subgraphs that can be queried with your API key - + - عرض وإدارة أسماء النطاقات المصرح لها باستخدام مفتاح API الخاص بك + - تعيين الـ subgraphs التي يمكن الاستعلام عنها باستخدام مفتاح API الخاص بك 3. Under **Indexer Preference**, you’ll be able to set different preferences for Indexers who are indexing subgraphs that your API key is used for. You can assign up to 5 points for each of these: - -- **Fastest Speed**: Time between the query and the response from an indexer. If you mark this as important we will optimize for fast indexers. -- **Lowest Price**: The amount paid per query. If you mark this as important we will optimize for the less expensive indexers. -- **Data Freshness**: How recent the latest block an indexer has processed for the subgraph you are querying. If you mark this as important we will optimize to find the indexers with the freshest data. -- **Economic Security**: The amount of GRT an indexer can lose if they respond incorrectly to your query. If you mark this as important we will optimize for indexers with a large stake. - + - **Fastest Speed**: Time between the query and the response from an indexer. If you mark this as important we will optimize for fast indexers. + - **Lowest Price**: The amount paid per query. If you mark this as important we will optimize for the less expensive indexers. + - **Data Freshness**: How recent the latest block an indexer has processed for the subgraph you are querying. If you mark this as important we will optimize to find the indexers with the freshest data. + - **Economic Security**: The amount of GRT an indexer can lose if they respond incorrectly to your query. If you mark this as important we will optimize for indexers with a large stake. 4. Under **Budget**, you’ll be able to update the maximum price per query. Note that we have a dynamic setting for that that's based on a volume discounting algorithm. **We strongly recommend using the default settings unless you are experiencing a specific problem.** Otherwise, you can update it under "Set a custom maximum budget". On this page you can also view different KPIs (in GRT and USD): - -- Average cost per query -- Failed queries over max price -- Most expensive query + - Average cost per query + - Failed queries over max price + - Most expensive query diff --git a/website/pages/ar/querying/querying-best-practices.mdx b/website/pages/ar/querying/querying-best-practices.mdx index 237316ef494f..ce2b7b2114f6 100644 --- a/website/pages/ar/querying/querying-best-practices.mdx +++ b/website/pages/ar/querying/querying-best-practices.mdx @@ -71,9 +71,22 @@ For a complete list of rules with code examples, please look at our GraphQL Vali GraphQL is a language and set of conventions that transport over HTTP. -It means that you can query a GraphQL API using standard `fetch` (natively or via `cross-undici-fetch` or `isomorphic-fetch`) as follows: +It means that you can query a GraphQL API using standard `fetch` (natively or via `@whatwg-node/fetch` or `isomorphic-fetch`). + +However, as stated in ["Querying from an Application"](/querying/querying-from-an-application), we recommend you to use our `graph-client` that supports unique features such as: + +- Cross-chain Subgraph Handling: Querying from multiple subgraphs in a single query +- [Automatic Block Tracking](https://github.com/graphprotocol/graph-client/blob/main/packages/block-tracking/README.md) +- [Automatic Pagination](https://github.com/graphprotocol/graph-client/blob/main/packages/auto-pagination/README.md) +- Fully typed result + +
+ +Here's how to query The Graph with `graph-client`: ```tsx +import { execute } from '../.graphclient' + const query = ` query GetToken($id: ID!) { token(id: $id) { @@ -84,55 +97,16 @@ query GetToken($id: ID!) { ` const variables = { id: '1' } -const fetchResult = await fetch('http://example.com/graphql', { - method: 'POST', - headers: { 'Content-Type': 'application/json' }, - body: JSON.stringify({ query, variables }), -}) -const result = await fetchResult.json() -``` - -Another lightweight alternative, best for back-end use-cases, is the famous [`graphql-request` library](https://github.com/prisma-labs/graphql-request). - -This lightweight GraphQL client comes with the essential features to query a GraphQL API: - -- Mutations validation -- Support for file upload -- Batching -- Promise-based API -- TypeScript support - -
- -A complete GraphQL client is [URQL](https://formidable.com/open-source/urql/) which is available within Node.js, React/Preact, Vue, Svelte environments, with more advanced features: - -- Flexible cache system -- Extensible design (easing adding new capabilities on top of it) -- Lightweight bundle (~5x lighter than Apollo Client) -- Support for file uploads and offline mode - -
- -In the React ecosystem, [React Query](https://react-query.tanstack.com/graphql) brings a lightweight and agnostic solution for GraphQL. - -React Query is a great candidate if you are looking for an easy-to-use and lightweight multipurpose client (GraphQL-capable) that provides essential features such as: - -- Powerful cache (background refresh, window-focus refreshing) -- Advanced querying pattern (parallel queries, dependent queries, prefetching) -- UX patterns: optimistic updates, scroll restoration -- Great dev tools - -
- -Finally, Apollo Client is the ubiquitous GraphQL client on the front-end ecosystem. +async function main() { + const result = await execute(query, variables) + // `result` is fully typed! + console.log(result) +} -Available for React, Angular, Vue, Ember, iOS, and Android, Apollo Client, although the heaviest clients, brings many features to build advanced UI on-top of GraphQL: +main() +``` -- advanced error handling -- pagination -- data prefetching -- optimistic UI -- local state management +More GraphQL client alternatives are covered in ["Querying from an Application"](/querying/querying-from-an-application).
@@ -503,69 +477,3 @@ The [JS GraphQL plugin](https://plugins.jetbrains.com/plugin/8097-graphql/) will - snippets More information on this [WebStorm article](https://blog.jetbrains.com/webstorm/2019/04/featured-plugin-js-graphql/) that showcases all the plugin's main features. - -
- -### TypeScript types generation - -Finally, the best GraphQL experience is reached when the TypeScript data types are generated from the defined GraphQL queries, as follows: - -```tsx -import { execute } from 'your-favorite-graphql-client' -import { GetTokenQuery } from './generated.' - -const id = params.id -const query = ` -query GetToken($id: ID!) { - token(id: $id) { - id - owner - } -} -` - -const result: GetTokenQuery = await execute(query, { - variables: { - id, - }, -}) - -// `result` is typed! -``` - -Such a setup can be easily achieved by installing and configuring [GraphQL Code Generator](https://www.graphql-code-generator.com/docs/getting-started) as follows: - -```bash -yarn add graphql @graphql-codegen/cli @graphql-codegen/typescript @graphql-codegen/typescript-operations -``` - -Then update your `package.json` (or similar script configuration setup) as follows: - -```tsx -{ - // ... - "scripts": { - // ... - "generate": "graphql-codegen", - // ... - } - // ... -} -``` - -Add the following configuration file to your project: - -```tsx -schema: "" -documents: './src/**/*.ts' -generates: - ./generated.ts: - plugins: - - typescript - - typescript-operations -``` - -Finally, by simply running the configured script (`yarn generate`), GraphQL Code Generator will generate the proper TypeScript types in the `generated.ts` file: - -- Each query will get a corresponding `[QueryName]Query` type (ex: `GetToken` → `GetTokenQuery` type -- Each fragment will get a corresponding `[FragmentName]Fragment` type (ex: `DelegateItem` → `DelegateItemFragment` type diff --git a/website/pages/ar/querying/querying-from-an-application.mdx b/website/pages/ar/querying/querying-from-an-application.mdx index 5082bfae455c..f4024adccf39 100644 --- a/website/pages/ar/querying/querying-from-an-application.mdx +++ b/website/pages/ar/querying/querying-from-an-application.mdx @@ -2,7 +2,7 @@ title: الاستعلام من التطبيق --- -بمجرد نشر ال Subgraph في Subgraph Studio أو في Graph Explorer ، سيتم إعطاؤك endpoint ل GraphQL API الخاصة بك والتي يجب أن تبدو كما يلي: +Once a subgraph is deployed to the Subgraph Studio or to The Graph Explorer, you will be given the endpoint for your GraphQL API that should look something like this: **Subgraph Studio (اختبار endpoint)** @@ -22,11 +22,147 @@ https://gateway.thegraph.com/api//subgraphs/id/ في ما يلي بعض عملاء GraphQL الأكثر شيوعا في النظام البيئي وكيفية استخدامها: +## GraphQL clients + +### Graph client + +The Graph is providing it own GraphQL client, `graph-client` that supports unique features such as: + +- Cross-chain Subgraph Handling: Querying from multiple subgraphs in a single query +- [Automatic Block Tracking](https://github.com/graphprotocol/graph-client/blob/main/packages/block-tracking/README.md) +- [Automatic Pagination](https://github.com/graphprotocol/graph-client/blob/main/packages/auto-pagination/README.md) +- Fully typed result + +
+ +Also integrated with popular GraphQL clients such as Apollo and URQL and compatible with all environments (React, Angular, Node.js, React Native), using `graph-client` will give you the best experience for interacting with The Graph. + +
+ +Let's look at how to fetch data from a subgraph with `graphql-client`. + +To get started, make sure to install The Graph Client CLI in your project: + +```sh +yarn add -D @graphprotocol/client-cli +# or, with NPM: +npm install --save-dev @graphprotocol/client-cli +``` + +Define your query in a `.graphql` file (or inlined in your `.js` or `.ts` file): + +```graphql +query ExampleQuery { + # this one is coming from compound-v2 + markets(first: 7) { + borrowRate + cash + collateralFactor + } + # this one is coming from uniswap-v2 + pair(id: "0x00004ee988665cdda9a1080d5792cecd16dc1220") { + id + token0 { + id + symbol + name + } + token1 { + id + symbol + name + } + } +} +``` + +Then, create a configuration file (called `.graphclientrc.yml`) and point to your GraphQL endpoints provided by The Graph, for example: + +```yaml +# .graphclientrc.yml +sources: + - name: uniswapv2 + handler: + graphql: + endpoint: https://api.thegraph.com/subgraphs/name/uniswap/uniswap-v2 + - name: compoundv2 + handler: + graphql: + endpoint: https://api.thegraph.com/subgraphs/name/graphprotocol/compound-v2 + +documents: + - ./src/example-query.graphql +``` + +Running the following The Graph Client CLI command will generate typed and ready to use JavaScript code: + +```sh +graphclient build +``` + +Finally, update your `.ts` file to use the generated typed GraphQL documents: + +```tsx +import React, { useEffect } from 'react' +// ... +// we import types and typed-graphql document from the generated code (`..graphclient/`) +import { ExampleQueryDocument, ExampleQueryQuery, execute } from '../.graphclient' + +function App() { + const [data, setData] = React.useState() + + useEffect(() => { + execute(ExampleQueryDocument, {}).then((result) => { + setData(result?.data) + }) + }, [setData]) + return ( +
+
+ logo +

Graph Client Example

+
+ {data && ( +
+ +
+