diff --git a/pages/ar/developer/assemblyscript-migration-guide.mdx b/pages/ar/developer/assemblyscript-migration-guide.mdx index 67578c39a65e..d20ebc9559fd 100644 --- a/pages/ar/developer/assemblyscript-migration-guide.mdx +++ b/pages/ar/developer/assemblyscript-migration-guide.mdx @@ -180,7 +180,8 @@ let c: usize = a + (b as usize) // upcasting on class inheritance class Bytes extends Uint8Array {} -let bytes = new Bytes(2) < Uint8Array > bytes // same as: bytes as Uint8Array +let bytes = new Bytes(2) +// bytes // same as: bytes as Uint8Array ``` هناك سيناريوهين قد ترغب في ال cast ، ولكن استخدام `as`/`var` ** ليس آمنا **: @@ -192,7 +193,8 @@ let bytes = new Bytes(2) < Uint8Array > bytes // same as: bytes as Uint8Array // downcasting on class inheritance class Bytes extends Uint8Array {} -let uint8Array = new Uint8Array(2) < Bytes > uint8Array // breaks in runtime :( +let uint8Array = new Uint8Array(2) +// uint8Array // breaks in runtime :( ``` ```typescript @@ -200,7 +202,8 @@ let uint8Array = new Uint8Array(2) < Bytes > uint8Array // breaks in runtime :( class Bytes extends Uint8Array {} class ByteArray extends Uint8Array {} -let bytes = new Bytes(2) < ByteArray > bytes // breaks in runtime :( +let bytes = new Bytes(2) +// bytes // breaks in runtime :( ``` في هذه الحالة يمكنك إستخدام دالة `changetype`: diff --git a/pages/ar/developer/subgraph-debug-forking.mdx b/pages/ar/developer/subgraph-debug-forking.mdx index 0b97a4c37735..b57926914ed5 100644 --- a/pages/ar/developer/subgraph-debug-forking.mdx +++ b/pages/ar/developer/subgraph-debug-forking.mdx @@ -1,28 +1,28 @@ --- -title: Quick and easy subgraph debugging using forks +title: تصحيح أخطاء الـ subgraph بسرعة وسهولة باستخدام التفرعات (forks) --- -> Note: this is only available from this `graph-node` [commit](https://github.com/graphprotocol/graph-node/commit/f4e6992d7949b18f990045c8babdcd205a060ef6) or this [docker tag](https://hub.docker.com/layers/graphprotocol/graph-node/f4e6992/images/sha256-51ad494a2ecc387bef2359d863b596ad5bd44436808964cf221e60365a7c00c8?context=explore) onwards, it hasn't been yet released in a minor release (eg: 0.26.0) +> ملاحظة: هذا متاح فقط من هذا `graph-node` [commit](https://github.com/graphprotocol/graph-node/commit/f4e6992d7949b18f990045c8babdcd205a060ef6) أو هذا [docker tag](https://hub.docker.com/layers/graphprotocol/graph-node/f4e6992/images/sha256-51ad494a2ecc387bef2359d863b596ad5bd44436808964cf221e60365a7c00c8?context=explore) وصاعدا ولم يتم إصدارها بعد في إصدار ثانوي (على سبيل المثال: 0.26.0) -As with many systems processing large amounts of data, The Graph's Indexers (Graph nodes) may take quite some time to sync-up your subgraph with the target blockchain. The discrepancy between quick changes with the purpose of debugging and long wait times needed for indexing is extremely counterproductive and we are well aware of that. This is why we are introducing **subgraph forking**, developed by [LimeChain](https://limechain.tech/), and in this article I will show you how this feature can be used to substantially speed-up subgraph debugging! +كما هو الحال مع العديد من الأنظمة التي تعالج كميات كبيرة من البيانات ، قد يستغرق مفهرسو The Graph أو (Graph nodes) بعض الوقت لمزامنة الـ subgraph الخاص بك مع blockchain المستهدف. التناقض بين التغييرات السريعة بغرض تصحيح الأخطاء وأوقات الانتظار الطويلة اللازمة للفهرسة يؤدي إلى نتائج عكسية للغاية ونحن ندرك ذلك جيدًا. ولهذا السبب نقدم **subgraph forking ** ، الذي تم تطويره بواسطة [ LimeChain ](https://limechain.tech/) ، وفي هذه المقالة سنوضح لكم كيف يمكن استخدام هذه الميزة لتسريع تصحيح أخطاء الـ subgraph بشكل كبير! -## Ok, what is it? +## حسنا، ما هو؟ -**Subgraph forking** is the process of lazily fetching entities from _another_ subgraph's store (usually a remote one). +**Subgraph forking** هي عملية جلب الكيانات بشكل lazily من مخزن subgraph _آخر_ (عادةً ما يكون بعيدًا). -In the context of debugging, **subgraph forking** allows you to debug your failed subgraph at block _X_ without needing to wait to sync-up to block _X_. +يسمح لك **subgraph forking** بتصحيح أخطاء الـ subgraph الفاشل في الكتلة(block) _ X _ دون الحاجة للانتظار للمزامنة للكتلة _ X _. -## What?! How? +## ماذا؟! كيف؟ -When you deploy a subgraph to a remote Graph node for indexing and it fails at block _X_, the good news is that the Graph node will still serve GraphQL queries using its store, which is synced-up to block _X_. That's great! This means we can take advantage of this "up-to-date" store to fix the bugs arising when indexing block _X_. +عندما تنشر subgraph إلى Graph node بعيدة للقيام بالفهرسة ويفشل عند الكتلة _ X _ ، فإن الخبر الجيد هو أن Graph node ستظل تقدم استعلامات GraphQL باستخدام مخزنها(store)، والذي تمت مزامنته للكتلة(block) _ X _. هذا عظيم! هذا يعني أنه يمكننا الاستفادة من هذا المخزن "المحدث" لإصلاح الأخطاء التي تظهر عند فهرسة الكتلة _ X _. -In a nutshell, we are going to _fork the failing subgraph_ from a remote Graph node that is guaranteed to have the subgraph indexed up to block _X_ in order to provide the locally deployed subgraph being debugged at block _X_ an up-to-date view of the indexing state. +باختصار ، سنقوم _ بتفريع (fork) الـ subgraph الفاشل _ من Graph node بعيدة والتي تضمن فهرسة الـ subgraph للكتلة _ X _ وذلك من أجل توفير الـ subgraph المنشور محليًا والذي يتم تصحيحه عندالكتلة*X* مع عرض محدث لحالة الفهرسة. -## Please, show me some code! +## من فضلك ، أرني بعض الأكواد! -To stay focused on subgraph debugging, let's keep things simple and run along with the [example-subgraph](https://github.com/graphprotocol/example-subgraph) indexing the Ethereum Gravity smart contract. +للاستمرار في التركيز على تصحيح أخطاء الـ subgraph ، دعنا نجعل الأمور بسيطة ونعمل مع [example-subgraph](https://github.com/graphprotocol/example-subgraph) الذي يفهرس عقد Ethereum Gravity الذكي. -Here are the handlers defined for indexing `Gravatar`s, with no bugs whatsoever: +فيما يلي المعالجات (handlers) المعرفة لفهرسة `Gravatar` ، بدون أخطاء على الإطلاق: ```tsx export function handleNewGravatar(event: NewGravatar): void { @@ -46,43 +46,43 @@ export function handleUpdatedGravatar(event: UpdatedGravatar): void { } ``` -Oops, how unfortunate, when I deploy my perfect looking subgraph to the [HostedService](https://thegraph.com/hosted-service/) it fails with the _"Gravatar not found!"_ error. +للأسف ، يفشل نشر هذا الـ subgraph ذو المظهر المثالي على [ HostedService ](https://thegraph.com/hosted-service/)مع ظهور الخطأ _"Gravatar not found!"_. -The usual way to attempt a fix is: +الطريقة المعتادة لمحاولة الإصلاح هي: -1. Make a change in the mappings source, which you believe will solve the issue (while I know it won't). -2. Re-deploy the subgraph to the [HostedService](https://thegraph.com/hosted-service/) (or another remote Graph node). -3. Wait for it to sync-up. -4. If it breaks again go back to 1, otherwise: Hooray! +1. إجراء تغيير في مصدر الـ mappings ، والذي تعتقد أنه سيحل المشكلة (وأنا أعلم أنه لن يحلها). +2. إعادة نشر الـ subgraph على [ HostedService ](https://thegraph.com/hosted-service/) (أو Graph node أخرى بعيدة). +3. الانتظار حتى تتم المزامنة. +4. إذا حدثت المشكلة مرة أخرى ، فارجع إلى 1! -It is indeed pretty familiar to an ordinary debug process, but there is one step that horribly slows down the process: _3. Wait for it to sync-up._ +كما ترى ، فهده الطريقة تشبه عملية تصحيح الأخطاء العادية ، ولكن هناك خطوة واحدة تؤدي إلى إبطاء العملية بشكل رهيب: _ 3. الانتظار حتى تتم المزامنة. _ -Using **subgraph forking** we can essentially eliminate this step. Here is how it looks: +باستخدام **subgraph forking** يمكننا التخلص من تلك الخطوة. إليك كيف يبدو: -0. Spin-up a local Graph node with the **_appropriate fork-base_** set. -1. Make a change in the mappings source, which you believe will solve the issue. -2. Deploy to the local Graph node, **_forking the failing subgraph_** and **_starting from the problematic block_**. -3. If it breaks again, go back to 1, otherwise: Hooray! +0. قم بتجهيز Graph node محلية بمجموعة **_fork-base_** مناسبة. +1. قم بإجراء تغيير في مصدر الـ mappings ، والذي تعتقد أنه سيحل المشكلة. +2. قم بالنشر إلى Graph node محلية ، **_وقم بتفريع الـ subgraph الفاشل_**و**_ البدء من الكتلة التي بها المشكلة_**. +3. إذا حدثت المشكلة مرة أخرى ، فارجع إلى 1! -Now, you may have 2 questions: +الآن ، قد يكون لديك سؤالان: -1. fork-base what??? 2) Forking who?! -2. Forking who?! +1. ماهو fork-base؟؟؟ +2. ما الذي نقوم بتفريعه (Forking)؟! -And I answer: +وأنا أجيب: -1. `fork-base` is the "base" URL, such that when the _subgraph id_ is appended the resulting URL (`/`) is a valid GraphQL endpoint for the subgraph's store. 2) Forking is easy, no need to sweat: -2. Forking is easy, no need to sweat: +1. `fork-base` هو عنوان URL "الأساسي" ،فمثلا عند إلحاق _subgraph id_ ، يكون عنوان URL الناتج (`/`) هو GraphQL endpoint صالح لمخزن الـ subgraph. +2. الـتفريع سهل ، فلا داعي للقلق: ```bash $ graph deploy --debug-fork --ipfs http://localhost:5001 --node http://localhost:8020 ``` -Also, don't forget to set the `dataSources.source.startBlock` field in the subgraph manifest to the number of the problematic block, so you can skip indexing unnecessary blocks and take advantage of the fork! +أيضًا ، لا تنس تعيين حقل `dataSources.source.startBlock` في subgraph manifest لرقم الكتلة(block) التي بها المشكلة، حتى تتمكن من تخطي فهرسة الكتل الغير ضرورية والاستفادة من التفريع! -So, here is what I do: +لذلك ، هذا ما أفعله: -0. I spin-up a local graph node ([here is how to do it](https://github.com/graphprotocol/graph-node#running-a-local-graph-node)) with the `fork-base` option set to: `https://api.thegraph.com/subgraphs/id/`, since I will fork a subgraph, the buggy one I deployed earlier, from the [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/` ، نظرا لأنني سأقوم بتفريع(fork) الـ subgraph الذي به أخطاء والذي نشرته سابقا من الـ [HostedService](https://thegraph.com/hosted-service/). ``` $ cargo run -p graph-node --release -- \ @@ -92,13 +92,13 @@ $ cargo run -p graph-node --release -- \ --fork-base https://api.thegraph.com/subgraphs/id/ ``` -1. After careful inspection I notice that there is a mismatch in the `id` representations used when indexing `Gravatar`s in my two handlers. While `handleNewGravatar` converts it to a hex (`event.params.id.toHex()`), `handleUpdatedGravatar` uses an int32 (`event.params.id.toI32()`) which causes the `handleUpdatedGravatar` to panic with "Gravatar not found!". I make them both convert the `id` to a hex. -2. After I made the changes I deploy my subgraph to the local Graph node, **_forking the failing subgraph_** and setting `dataSources.source.startBlock` to `6190343` in `subgraph.yaml`: +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`: ```bash $ graph deploy gravity --debug-fork QmNp169tKvomnH3cPXTfGg4ZEhAHA6kEq5oy1XDqAxqHmW --ipfs http://localhost:5001 --node http://localhost:8020 ``` -3. I inspect the logs produced by the local Graph node and, Hooray!, everything seems to be working. -4. I deploy my now bug-free subgraph to a remote Graph node and live happily ever after! (no potatoes tho) -5. The end... +3. لقد قمت بفحص السجلات التي تنتجها Graph node المحلية ، ويبدو أن كل شيء يعمل بشكل جيد. +4. أقوم بنشر الـ subgraph الخاص بي الخالي من الأخطاء لـ Graph node بعيدة وأعيش في سعادة دائمة +5. النهاية... diff --git a/pages/ar/hosted-service/migrating-subgraph.mdx b/pages/ar/hosted-service/migrating-subgraph.mdx index 3e82d0a376e4..ef5910a281be 100644 --- a/pages/ar/hosted-service/migrating-subgraph.mdx +++ b/pages/ar/hosted-service/migrating-subgraph.mdx @@ -137,7 +137,7 @@ _بينما تتم هذه الآلية حاليا على الشبكة ، ينا على الرغم من أن هذه ليست ميزة موجودة في واجهة مستخدم المنتج ، إلا أنه يمكنك تعيين الحد الأقصى لميزانيتك لكل استعلام وذلك عن طريق أخذ المبلغ الذي ترغب في دفعه شهريًا وتقسيمه على حجم الاستعلام المتوقع. -While you get to decide on your query budget, there is no guarantee that an Indexer will be willing to serve queries at that price. If a Gateway can match you to an Indexer willing to serve a query at, or lower than, the price you are willing to pay, you will pay the delta/difference of your budget **and** their price. As a consequence, a lower query price reduces the pool of Indexers available to you, which may affect the quality of service you receive. It's beneficial to have high query fees, as that may attract curation and big-name Indexers to your subgraph. +أثناء اتخاذ قرار بشأن ميزانية الاستعلام الخاصة بك ، ليس هناك ما يضمن أن المفهرس سيكون على استعداد لتقديم الاستعلامات بهذا السعر. إذا تمكن الـ Gateway من مطابقتك مع مفهرس يرغب في تقديم استعلام بالسعر الذي ترغب في دفعه أو أقل ، فستدفع الفرق بين ميزانيتك **و** سعرهم. ونتيجة لذلك ، فإن سعر الاستعلام المنخفض يقلل من عدد المفهرسين المتاحين لك ، مما قد يؤثر على جودة الخدمة التي تتلقاها. من المفيد أن يكون لديك رسوم استعلام مرتفع ، لأن ذلك قد يجذب التنسيق وأسماء كبيرة من المفهرسين إلى الـ subgraph الخاص بك. تذكر أنه سوق ديناميكي ومتنامي ، ولكن كيفية تفاعلك معه هو تحت سيطرتك. لا يوجد حد أقصى أو أدنى للسعر في البروتوكول أو البوابات(Gateways). على سبيل المثال ، يمكنك إلقاء نظرة أدناه على السعر الذي دفعه عدد قليل من الـ dapps على الشبكة (على أساس أسبوعي). انظر للعمود الأخير ، والذي يعرض رسوم الاستعلام كـ GRT. على سبيل المثال ، [Pickle Finance](https://www.pickle.finance/) لديه 8 طلبات في الثانية ودفع 2.4 GRT لأسبوع واحد. diff --git a/pages/ar/studio/subgraph-studio.mdx b/pages/ar/studio/subgraph-studio.mdx index 5b4947e89d8c..6b3dbcebfbc4 100644 --- a/pages/ar/studio/subgraph-studio.mdx +++ b/pages/ar/studio/subgraph-studio.mdx @@ -12,12 +12,12 @@ title: كيفية استخدام Subgraph Studio - نشر subgraph باستخدام CLI - نشر subgraph باستخدام Studio UI - اختبار الـ subgraph في playground -- Integrate it in staging using the query URL +- دمجه في المنصة باستخدام عنوان URL الاستعلام - إنشاء وإدارة مفاتيح API الخاصة بك لـ subgraphs محددة -هنا في Subgraph Studio ، لديك سيطرة كاملة على الـ subgraphs الخاصة بك. حيث لا يمكنك فقط اختبار الـ subgraphs الخاصة بك قبل نشرها ، ولكن يمكنك أيضا تقييد مفاتيح API الخاصة بك على نطاقات محددة والسماح فقط لمفهرسين معينين بالاستعلام من مفاتيح API الخاصة بهم. +هنا في Subgraph Studio ، لديك سيطرة كاملة على الـ subgraphs الخاصة بك. حيث لا يمكنك اختبار الـ subgraphs الخاصة بك قبل نشرها فحسب، ولكن يمكنك أيضا تقييد مفاتيح API الخاصة بك على نطاقات محددة والسماح فقط لمفهرسين معينين بالاستعلام من مفاتيح API الخاصة بهم. -يولد الاستعلام عن الـ subgraphs رسوم استعلام ، وتُستخدم لمكافأة [المفهرسين](/indexing) على شبكة Graph. إذا كنت مطورا لـ dapp أو لـ subgraph ، فسيمكنك Studio من بناء subgraphs أفضل لدعم استعلاماتك أو استعلام مجتمعك. يتكون Studio من 5 أجزاء رئيسية: +يولد الاستعلام عن الـ subgraphs رسوم استعلام ، وتُستخدم لمكافأة [المفهرسين](/indexing) على شبكة Graph. إذا كنت مطورا لـ dapp أو لـ subgraph ، فيمكنك من خلال Studio بناء subgraphs أفضل لدعم استعلاماتك أو استعلام مجتمعك. يتكون Studio من 5 أجزاء رئيسية: - التحكم في حساب المستخدم الخاص بك - قائمة من الـ subgraphs التي قمت بإنشائها @@ -58,7 +58,7 @@ title: كيفية استخدام Subgraph Studio بعد إنشاء الـ subgraph الخاص بك، ستتمكن من نشره باستخدام [ CLI ](https://github.com/graphprotocol/graph-cli) أو واجهة سطر الأوامر. سيؤدي نشر subgraph باستخدام CLI إلى دفع الـ subgraph إلى Studio حيث ستتمكن من اختبار الـ subgraphs باستخدام playground. سيسمح لك هذا في النهاية بالنشر على شبكة Graph. لمزيد من المعلومات حول إعداد CLI ، [ راجع هذا](/developer/define-subgraph-hosted#install-the-graph-cli) (pst ، تأكد من توفر مفتاح النشر لديك). تذكر أن النشر(deploying)**يختلف عن** النشر(publishing). عندما تنشر (deploying) الـ subgraph، فأنت تدفعه إلى Studio حيث يمكنك اختباره. وفي المقابل ، عندما تنشر(publishing) الـ subgraph ، فإنك تنشره على السلسلة (on-chain). -## اختبار الـ Subgraph بك في Subgraph Studio +## اختبار الـ Subgraph الخاص بك في Subgraph Studio إذا كنت ترغب في اختبار الـ subgraph قبل نشره على الشبكة ، فيمكنك القيام بذلك في Subgraph **Playground** أو إلقاء نظرة على سجلاتك. ستخبرك سجلات الـ Subgraph ** أين ** يفشل الـ subgraph في حالة حدوث ذلك. @@ -80,7 +80,7 @@ title: كيفية استخدام Subgraph Studio ستتمكن فقط من فهرسة البيانات من mainnet (حتى إذا تم نشر الـ subgraph الخاص بك على testnet) لأنه لا يمكن نشر سوى الـ subgraphs التي تقوم بفهرسة بيانات mainnet. وذلك لأن المفهرسين يحتاجون إلى تقديم إثبات إلزامي لسجلات الفهرسة بدءا من block hash معين. نظرًا لأن نشر subgraph هو إجراء على-سلسلة (on-chain) ، فالإجراء يمكن أن يستغرق بضع دقائق. أي عنوان تستخدمه لنشر العقد سيكون هو الوحيد القادر على نشر الإصدارات المستقبلية. لذا اختر بحكمة! -الـ Subgraphs التي لها إشارة تنسيق يتم عرضها للمفهرسين بحيث يمكن فهرستها على الشبكة اللامركزية. يمكنك نشر الـ subgraphs والإشارة إليها في إجراء واحدة ، مما يتيح لك صك أول إشارة تنسيق على الـ subgraph وتوفير تكاليف الغاز. من خلال إضافة إشارتك إلى الإشارة التي قدمها المنسقون لاحقًا ، سيكون للـ subgraph الخاص بك فرصة أكبر لتقديم الاستعلامات في النهاية. +الـ Subgraphs التي لها إشارة تنسيق يتم عرضها للمفهرسين بحيث يمكن فهرستها على الشبكة اللامركزية. يمكنك نشر الـ subgraphs والإشارة إليها في إجراء واحد ، مما يتيح لك صك أول إشارة تنسيق على الـ subgraph وتوفير تكاليف الغاز. ومن خلال إضافة إشارتك إلى الإشارة التي قدمها المنسقون لاحقًا ، سيكون للـ subgraph الخاص بك فرصة أكبر لتقديم الاستعلامات في النهاية. ** الآن بعد أن نشرت الـ subgraph الخاص بك ، دعنا ندخل في كيفية إدارتهم على أساس منتظم. ** لاحظ أنه لا يمكنك نشر الـ subgraph على الشبكة إذا قد فشلت المزامنة. يحدث هذا عادةً بسبب وجود أخطاء في الـ subgraph - ستخبرك السجلات بمكان وجود هذه المشكلات! @@ -100,7 +100,7 @@ title: كيفية استخدام Subgraph Studio ## إدارة مفاتيح API الخاصة بك -بغض النظر عما إذا كنت مطور dapp أو مطور subgraph ، فستحتاج إلى إدارة مفاتيح API الخاصة بك. وهذا مهم بالنسبة لك لتكون قادرا على الاستعلام عن الـ subgraphs لأن مفاتيح API تضمن أن الربط بين خدمات التطبيق صحيحة ومرخصة. يتضمن ذلك مصادقة المستخدم والجهاز باستخدام التطبيق. +بغض النظر عما إذا كنت مطور dapp أو مطور subgraph ، فستحتاج إلى إدارة مفاتيح API الخاصة بك. وهذا مهم بالنسبة لك لتكون قادرا على الاستعلام عن الـ subgraphs لأن مفاتيح API تضمن أن الربط بين خدمات التطبيق صحيحة ومرخصة. يتضمن ذلك مصادقة المستخدم والجهاز المستخدم للتطبيق. سيقوم Studio بسرد مفاتيح API الموجودة ، والتي ستمنحك القدرة على إدارتها أو حذفها. @@ -116,7 +116,7 @@ title: كيفية استخدام Subgraph Studio ## كيفية إدارة الـ Subgraph الخاص بك -سيكون لديك العديد من الأدوات تحت تصرفك لإدارة الـ subgraphs. ويمكنك تنظيم الـ subgraphs الخاصة بك حسب **الحالة(status)** و**الصنف(category)**. +سيكون لديك العديد من الأدوات تحت تصرفك لإدارة الـ subgraphs. ويمكنك تنظيم الـ subgraphs الخاصة بك حسب **الحالة(status)** و**الفئة(category)**. - تتيح لك علامة **Status** الاختيار من بين مجموعة متنوعة من العلامات(tags) بما في ذلك ``, ``, ``, ``, الخ. - وفي الوقت نفسه ، يسمح لك **Category** بتعيين الفئة التي يقع فيها الـ subgraph الخاص بك. وتشمل الخيارات ``, ``, ``, الخ. diff --git a/pages/ar/supported-networks/near.mdx b/pages/ar/supported-networks/near.mdx index d2b4820a84ec..0f7bf71e1632 100644 --- a/pages/ar/supported-networks/near.mdx +++ b/pages/ar/supported-networks/near.mdx @@ -29,15 +29,15 @@ title: بناء Subgraphs على NEAR `graphprotocol/graph-ts@` هي مكتبة لأنواع خاصة بـ subgraph. -تطوير NEAR subgraph يتطلب `graph-cli` إصدارا أعلى من `0.23.0` و `graph-ts` إصدارا أعلى من `0.23.0`. +تطوير NEAR subgraph يتطلب `graph-cli` بإصدار أعلى من `0.23.0` و `graph-ts` بإصدار أعلى من `0.23.0`. > بناء NEAR subgraph يشبه إلى حد كبير بناء subgraph يقوم بفهرسة الـ Ethereum. هناك ثلاثة جوانب لتعريف الـ subgraph: -**subgraph.yaml:** الـ subgraph manifest ، وتحديد مصادر البيانات ذات الأهمية ، وكيف يجب أن تتم معالجتها. NEAR هو `نوع` جديد لمصدر البيانات. +**subgraph.yaml:** الـ subgraph manifest ، وتحديد مصادر البيانات ذات الأهمية ، وكيف يجب أن تتم معالجتها.علما أن NEAR هو `نوع` جديد لمصدر البيانات. -**schema.graphql:** ملف مخطط يقوم بتعريف البيانات المخزنة لـ subgraph الخاص بك ، وكيفية الاستعلام عنها عبر GraphQL. تتم تغطية متطلبات NEAR subgraphs بواسطة [ الوثائق الحالية ](/developer/create-subgraph-hosted#the-graphql-schema). +**schema.graphql:** مخطط يقوم بتعريف البيانات المخزنة لـ subgraph الخاص بك ، وكيفية الاستعلام عنها عبر GraphQL. وتتم تغطية متطلبات NEAR subgraphs بواسطة [ الوثائق الحالية ](/developer/create-subgraph-hosted#the-graphql-schema). **AssemblyScript Mappings:** هو [AssemblyScript كود ](/developer/assemblyscript-api) والذي يترجم من بيانات الحدث إلى الكيانات المعرفة في مخططك. دعم NEAR يقدم أنواع بيانات خاصة بـ NEAR ووظيفة تحليل JSON جديدة. @@ -73,21 +73,21 @@ dataSources: ``` - NEAR subgraphs يقدم `نوعا ` جديدا من مصدر بيانات (`near`) -- The `network` should correspond to a network on the hosting Graph Node. On the Hosted Service, NEAR's mainnet is `near-mainnet`, and NEAR's testnet is `near-testnet` -- مصادر بيانات NEAR تقدم حقلًا اختياريًا `source.account` ، وهو ID يمكن قراءته و منسجما مع [ حساب NEAR ](https://docs.near.org/docs/concepts/account). يمكن أن يكون هذا حسابًا أو حسابًا فرعيًا. +- يجب أن يتوافق الـ `network` مع شبكة على Graph Node المضيفة. في الخدمة المستضافة ، الشبكة الرئيسية لـ NEAR هي `near-mainnet` ، وشبكة NEAR's testnet هي `near-testnet` +- مصادر بيانات NEAR تقدم حقلًا اختياريًا `source.account` ، وهو ID يمكن قراءته و يتوافق مع [ حساب NEAR ](https://docs.near.org/docs/concepts/account). ويمكن أن يكون ذلك حسابًا أو حسابًا فرعيًا. مصادر بيانات NEAR تدعم نوعين من المعالجات: - `blockHandlers`: يتم تشغيلها على كل كتلة NEAR جديدة. لا يتطلب `source.account`. - `receiptHandlers`: يتم تشغيلها في كل استلام حيث يكون مصدر البيانات`source.account` هو المستلم. لاحظ أنه تتم معالجة المطابقات التامة فقط (يجب إضافة حسابات فرعية [subaccounts](https://docs.near.org/docs/concepts/account#subaccounts) كمصادر بيانات مستقلة). -### تعريف المخطط +### تعريف المخطط(Schema Definition) -Schema definition describes the structure of the resulting subgraph database, and the relationships between entities. This is agnostic of the original data source. There are more details on subgraph schema definition [here](/developer/create-subgraph-hosted#the-graphql-schema). +تعريف المخطط يقوم بوصف هيكل قاعدة بيانات الـ subgraph الناتجة والعلاقات بين الكيانات. وهذا مستقل عن مصدر البيانات الأصلية. لمزيد من التفاصيل حول تعريف مخطط الـ subgraph [ هنا ](/developer/create-subgraph-hosted#the-graphql-schema). ### AssemblyScript Mappings -تمت كتابة المعالجات الخاصة بمعالجة الأحداث بـ[ AssemblyScript ](https://www.assemblyscript.org/). +تمت كتابة المعالجات(handlers) الخاصة بمعالجة الأحداث بـ[ AssemblyScript ](https://www.assemblyscript.org/). فهرسة NEAR تقدم أنواع بيانات خاصة بـ NEAR إلى [AssemblyScript API](/developer/assemblyscript-api). @@ -153,18 +153,18 @@ class ReceiptWithOutcome { يتم تمرير هذه الأنواع لمعالجات الكتلة(block) & الاستلام(receipt): -- معالجات الكتلة ستستلم `Block` -- ستستلم معالجات الاستلام `ReceiptWithOutcome` +- معالجات الكتلة ستتلقى`Block` +- معالجات الاستلام ستتلقى`ReceiptWithOutcome` -وبخلاف ذلك ، بقية [ AssemblyScript API ](/developer/assemblyscript-api) تكون متاحة لمطوري NEAR subgraph أثناء تنفيذ الـ mapping. +وبخلاف ذلك ، فإن بقية [ AssemblyScript API ](/developer/assemblyscript-api) تكون متاحة لمطوري NEAR subgraph أثناء تنفيذ الـ mapping. هذا يتضمن دالة تحليل JSON جديدة - يتم إرسال السجلات الموجودة على NEAR بشكل متكرر على هيئة JSONs. تتوفر دالة `(...)json.fromString` جديدة كجزء من [JSON API](/developer/assemblyscript-api#json-api) للسماح للمطورين لمعالجة هذه السجلات بسهولة. ## نشر NEAR Subgraph -بمجرد امتلاكك لـ subgraph، فقد حان الوقت لنشره في Graph Node للفهرسة. يمكن نشر NEAR subgraphs في أي Graph Node `>=v0.26.x` (لم يتم وضع علامة(tag) على هذا الإصدار ولم يتم إصداره بعد). +بمجرد امتلاكك لـ subgraph، فقد حان الوقت لنشره في Graph Node للفهرسة. يمكن نشر NEAR subgraphs في اصدارات Graph Node `>=v0.26.x` (لم يتم وضع علامة(tag) على هذا الإصدار ولم يتم إصداره بعد). -تدعم Graph's Hosted Service حاليًا فهرسة NEAR mainnet و testnet في مرحلة beta، باستخدام أسماء الشبكات التالية: +تدعم Graph's Hosted Service حاليًا فهرسة NEAR mainnet و testnet في مرحلة beta، وذلك باستخدام أسماء الشبكات التالية: - `near-mainnet` - `near-testnet` @@ -208,7 +208,7 @@ graph deploy --node http://localhost:8020/ --ipfs http://localhost:5001 تشغيل Graph Node التي تقوم بفهرسة NEAR لها المتطلبات التشغيلية التالية: -- NEAR Indexer Framework with Firehose instrumentation +- NEAR Indexer Framework مع أجهزة Firehose - مكونات NEAR Firehose - تكوين Graph Node مع Firehose endpoint @@ -216,7 +216,7 @@ graph deploy --node http://localhost:8020/ --ipfs http://localhost:5001 ## الاستعلام عن NEAR Subgraph -يتم تحديد GraphQL endpoint لـ NEAR subgraphs من خلال تعريف المخطط ، بواجهة API الحالية. يرجى زيارة [ وثائق GraphQL API ](/developer/graphql-api) لمزيد من المعلومات. +يتم تحديد GraphQL endpoint لـ NEAR subgraphs من خلال تعريف المخطط ، باستخدام واجهة API الحالية. يرجى زيارة [ وثائق GraphQL API ](/developer/graphql-api) لمزيد من المعلومات. ## أمثلة على الـ Subgraphs @@ -230,7 +230,7 @@ graph deploy --node http://localhost:8020/ --ipfs http://localhost:5001 ### كيف يعمل beta ؟ -دعم NEAR في beta ، مما يعني أنه قد تكون هناك تغييرات في الـ API بينما نواصل العمل على تحسين التكامل. يرجى إرسال بريد إلكتروني إلى near@thegraph.com حتى نتمكن من دعمك في بناء NEAR subgraphs ، وإطلاعك على آخر التطورات! +يتوفر دعم NEAR في beta ، مما يعني أنه قد تكون هناك تغييرات في الـ API بينما نواصل العمل على تحسين التكامل. يرجى إرسال بريد إلكتروني إلى near@thegraph.com حتى نتمكن من دعمك في بناء NEAR subgraphs ، وإطلاعك على آخر التطورات! ### هل يمكن لـ subgraph فهرسة كلاً من سلاسل NEAR و EVM؟ @@ -240,19 +240,19 @@ graph deploy --node http://localhost:8020/ --ipfs http://localhost:5001 حاليًا ، يتم دعم مشغلات الكتلة(Block) والاستلام(Receipt). نحن نبحث في مشغلات استدعاءات الدوال لحساب محدد. نحن مهتمون أيضًا بدعم مشغلات الأحداث ، بمجرد حصول NEAR على دعم محلي للأحداث. -### هل سيتم تشغيل معالجات الاستلام للحسابات وحساباتها الفرعية؟ +### هل سيتم تشغيل(trigger) معالجات الاستلام للحسابات وحساباتها الفرعية؟ سيتم تشغيل معالجات الاستلام فقط للتطابق التام للحساب المحدد. يمكن إضافة المزيد من المرونة في المستقبل. -### Can NEAR subgraphs make view calls to NEAR accounts during mappings? +### هل يستطيع NEAR subgraphs أن يقوم بعرض استدعاءات لحسابات NEAR أثناء الـ mappings؟ -هذا غير مدعوم. نقوم بتقييم ما إذا كانت هذه الوظيفة مطلوبة للفهرسة. +هذا غير مدعوم. نحن بصدد تقييم ما إذا كانت هذه الميزة مطلوبة للفهرسة. -### هل يمكنني استخدام قوالب مصدر البيانات في NEAR subgraph الخاص بي؟ +### هل يمكنني استخدام قوالب لمصدر البيانات في NEAR subgraph الخاص بي؟ -هذا غير مدعوم حاليا. نقوم بتقييم ما إذا كانت هذه الوظيفة مطلوبة للفهرسة. +هذا غير مدعوم حاليا. نحن بصدد تقييم ما إذا كانت هذه الميزة مطلوبة للفهرسة. -### يدعم Ethereum subgraphs الإصدارات "المعلقة" و "الحالية" ، كيف يمكنني نشر إصدار "معلق" من NEAR subgraph؟ +### يدعم Ethereum subgraphs الإصدارات المعلقة "pending" و "الحالية" ، كيف يمكنني نشر إصدار "معلق" من NEAR subgraph؟ الوظيفة المعلقة ليست مدعومة لـ NEAR subgraphs. وفي غضون ذلك ، يمكنك نشر إصدار جديد على subgraph مختلف "مسمى" ، وبعد ذلك عندما تتم مزامنته مع رأس السلسلة ، يمكنك إعادة النشر إلى الـ subgraph الأساسي "المسمى" ، والذي سيستخدم نفس ID النشر الأساسي ، لذلك ستتم مزامنة الـ subgraph الرئيسي على الفور. diff --git a/pages/es/developer/assemblyscript-migration-guide.mdx b/pages/es/developer/assemblyscript-migration-guide.mdx index 05c245bae275..3385a907586b 100644 --- a/pages/es/developer/assemblyscript-migration-guide.mdx +++ b/pages/es/developer/assemblyscript-migration-guide.mdx @@ -180,7 +180,8 @@ let c: usize = a + (b as usize) // upcasting on class inheritance class Bytes extends Uint8Array {} -let bytes = new Bytes(2) < Uint8Array > bytes // same as: bytes as Uint8Array +let bytes = new Bytes(2) +// bytes // same as: bytes as Uint8Array ``` Hay dos escenarios en los que puede querer cast, pero usando `as`/`var` **no es seguro**: @@ -192,7 +193,8 @@ Hay dos escenarios en los que puede querer cast, pero usando `as`/`var` **no // downcasting on class inheritance class Bytes extends Uint8Array {} -let uint8Array = new Uint8Array(2) < Bytes > uint8Array // breaks in runtime :( +let uint8Array = new Uint8Array(2) +// uint8Array // breaks in runtime :( ``` ```typescript @@ -200,7 +202,8 @@ let uint8Array = new Uint8Array(2) < Bytes > uint8Array // breaks in runtime :( class Bytes extends Uint8Array {} class ByteArray extends Uint8Array {} -let bytes = new Bytes(2) < ByteArray > bytes // breaks in runtime :( +let bytes = new Bytes(2) +// bytes // breaks in runtime :( ``` Para esos casos, puedes usar la función `changetype`: diff --git a/pages/es/developer/subgraph-debug-forking.mdx b/pages/es/developer/subgraph-debug-forking.mdx index 03e711bc6ee9..955aed14b521 100644 --- a/pages/es/developer/subgraph-debug-forking.mdx +++ b/pages/es/developer/subgraph-debug-forking.mdx @@ -2,7 +2,7 @@ title: Depuración rápida y sencilla de subgrafos mediante forks --- -> Note: this is only available from this `graph-node` [commit](https://github.com/graphprotocol/graph-node/commit/f4e6992d7949b18f990045c8babdcd205a060ef6) or this [docker tag](https://hub.docker.com/layers/graphprotocol/graph-node/f4e6992/images/sha256-51ad494a2ecc387bef2359d863b596ad5bd44436808964cf221e60365a7c00c8?context=explore) onwards, it hasn't been yet released in a minor release (eg: 0.26.0) +> Nota: este es solo disponible desde este `graph-node` [commit](https://github.com/graphprotocol/graph-node/commit/f4e6992d7949b18f990045c8babdcd205a060ef6) o este [docker tag](https://hub.docker.com/layers/graphprotocol/graph-node/f4e6992/images/sha256-51ad494a2ecc387bef2359d863b596ad5bd44436808964cf221e60365a7c00c8?context=explore) en adelante, todavía no se ha publicado en una versión menor (por ejemplo: 0.26.0) Al igual que con muchos sistemas que procesan grandes cantidades de datos, los indexadores de The Graph (Graph Nodes) pueden tardar bastante en sincronizar su subgrafo con la blockchain de destino. La discrepancia entre los cambios rápidos con fines de depuración y los largos tiempos de espera necesarios para la indexación es extremadamente contraproducente y somos muy conscientes de ello. Por eso introducimos **subgraph forking**, desarrollados por [LimeChain](https://limechain.tech/), y en este artículo te mostramos cómo se puede utilizar esta función para acelerar sustancialmente la depuración del subgrafo! diff --git a/pages/es/hosted-service/migrating-subgraph.mdx b/pages/es/hosted-service/migrating-subgraph.mdx index fb1617b67ea1..94cccd8a7c1e 100644 --- a/pages/es/hosted-service/migrating-subgraph.mdx +++ b/pages/es/hosted-service/migrating-subgraph.mdx @@ -13,7 +13,7 @@ The process of migration is quick and your subgraphs will forever benefit from t If your subgraph is: - Indexing [IPFS](https://ipfs.io/). -- Using [full-text search fields](https://thegraph.com/docs/en/developer/create-subgraph-hosted/#defining-fulltext-search-fields). +- Using [full-text search fields](/developer/create-subgraph-hosted/#defining-fulltext-search-fields). - Indexing chains other than Ethereum mainnet. ### Migrating an Existing Subgraph to The Graph Network diff --git a/pages/es/studio/billing.mdx b/pages/es/studio/billing.mdx index fec638ae5c9f..60c6dd0390ae 100644 --- a/pages/es/studio/billing.mdx +++ b/pages/es/studio/billing.mdx @@ -1,43 +1,43 @@ --- -title: Billing on the Subgraph Studio +title: Facturación en Subgraph Studio --- ### Descripción -Invoices are statements of payment amounts owed by a customer and are typically generated on a weekly basis in the system. You’ll be required to pay fees based on the query fees you generate using your API keys. The billing contract lives on the [Polygon](https://polygon.technology/) network. It’ll allow you to: +Las facturas son extractos de los importes de pago que debe un cliente y suelen generarse semanalmente en el sistema. Se te pedirá que pagues tarifas basadas en las tarifas de consulta que generes utilizando tus claves API. El contrato de facturación vive en la red [Polygon](https://polygon.technology/). Te permitirá: -- Add and remove GRT -- Keep track of your balances based on how much GRT you have added to your account, how much you have removed, and your invoices -- Automatically clear payments based on query fees generated +- Añadir y eliminar GRT +- Controla tus saldos en función de la cantidad de GRT que agregaste a tu cuenta, la cantidad que retiraste y tus facturas +- Compensar automáticamente los pagos en función de las tarifas de consulta generadas -In order to add GRT to your account, you will need to go through the following steps: +Para añadir GRT a tu cuenta, deberás seguir los siguientes pasos: -1. Purchase GRT and ETH on an exchange of your choice -2. Send the GRT and ETH to your wallet -3. Bridge GRT to Polygon using the UI +1. Compra GRT y ETH en un exchange de tu elección +2. Envía GRT y ETH a tu wallet +3. Puente de GRT a Polygon usando la UI - a) You will receive 0.001 Matic in a few minutes after you send any amount of GRT to the Polygon bridge. You can track the transaction on [Polygonscan](https://polygonscan.com/) by inputting your address into the search bar. + a) Recibirás 0,001 Matic en unos minutos después de enviar cualquier cantidad de GRT al puente del Polygon. Puedes seguir la transacción en [Polygonscan](https://polygonscan.com/) introduciendo tu dirección en la barra de búsqueda. -4. Add bridged GRT to the billing contract on Polygon. The billing contract address is: [0x10829DB618E6F520Fa3A01c75bC6dDf8722fA9fE](https://polygonscan.com/address/0x10829DB618E6F520Fa3A01c75bC6dDf8722fA9fE). +4. Añade GRT puenteado al contrato de facturación en Polygon. La dirección del contrato de facturación es: [0x10829DB618E6F520Fa3A01c75bC6dDf8722fA9fE](https://polygonscan.com/address/0x10829DB618E6F520Fa3A01c75bC6dDf8722fA9fE). - a) In order to complete step #4, you'll need to switch your network in your wallet to Polygon. You can add Polygon's network by connecting your wallet and clicking on "Choose Matic (Polygon) Mainnet" [here.](https://chainlist.org/) Once you've added the network, switch it over in your wallet by navigating to the network pill on the top right hand side corner. In Metamask, the network is called **Matic Mainnnet.** + a) Para completar el paso #4, tendrás que cambiar la red de tu wallet a Polygon. Puedes agregar la red de Polygo conectando tu wallet y haciendo clic en "Choose Matic (Polygon) Mainnet" [here.](https://chainlist.org/) Una vez que hayas añadido la red, cámbiala en tu wallet navegando hasta la pastilla de la red en la esquina superior derecha. En Metamask, la red se llama **Matic Mainnnet.** -At the end of each week, if you used your API keys, you will receive an invoice based on the query fees you have generated during this period. This invoice will be paid using GRT available in your balance. Query volume is evaluated by the API keys you own. Your balance will be updated after fees are withdrawn. +Al final de cada semana, si has utilizado tus claves API, recibirás una factura basada en las tasas de consulta que hayas generado durante este periodo. Esta factura se pagará con GRT disponible en tu saldo. El volumen de consultas se evalúa en función de las claves API que poseas. Tu saldo se actualizará una vez retiradas las tarifas. -#### Here’s how you go through the invoicing process: +#### Así es como se realiza el proceso de facturación: -There are 4 states your invoice can be in: +Hay 4 estados en los que puede estar tu factura: -1. Created - your invoice has just been created and not been paid yet -2. Paid - your invoice has been successfully paid -3. Unpaid - there is not enough GRT in your balance on the billing contract -4. Error - there is an error processing the payment +1. Creada: tu factura acaba de ser creada y aún no ha sido pagada +2. Pagada - Tu factura ha sido pagada con éxito +3. Impaga: no hay suficiente GRT en tu saldo en el contrato de facturación +4. Error - hay un error al procesar el pago -**See the diagram below for more information:** +**Consulta el siguiente diagrama para obtener más información:** -![Billing Flow](/img/billing-flow.png) +![Flujo de Facturación](/img/billing-flow.png) -For a quick demo of how billing works on the Subgraph Studio, check out the video below: +Si quieres ver una demostración rápida de cómo funciona la facturación en Subgraph Studio, mira el siguiente video:
-### Multisig Users +### Usuarios Multisig -Multisigs are smart-contracts that can exist only on the network they have been created, so if you created one on Ethereum Mainnet - it will only exist on Mainnet. Since our billing uses Polygon, if you were to bridge GRT to the multisig address on Polygon the funds would be lost. +Los multisigs son contratos inteligentes que sólo pueden existir en la red en la que han sido creados, por lo que si creaste uno en Ethereum Mainnet - sólo existirá en Mainnet. Dado que nuestra facturación utiliza Polygon, si haces un puente entre GRT y la dirección de la multisig en Polygon, los fondos se perderían. -To overcome this issue, we created [a dedicated tool](https://multisig-billing.thegraph.com/) that will help you deposit GRT on our billing contract (on behalf of the multisig) with a standard wallet / EOA (an account controlled by a private key). +Para superar este problema, hemos creado [una herramienta dedicada](https://multisig-billing.thegraph.com/) que te ayudará a depositar GRT en nuestro contrato de facturación (en nombre del multisig) con una wallet estándar / EOA (una cuenta controlada por una clave privada). -You can access our Multisig Billing Tool here: https://multisig-billing.thegraph.com/ +Puedes acceder a nuestra herramienta de facturación Multisig aquí: https://multisig-billing.thegraph.com/ -This tool will guide you to go through the following steps: +Esta herramienta te guiará para realizar los siguientes pasos: -1. Connect your standard wallet / EOA (this wallet needs to own some ETH as well as the GRT you want to deposit) -2. Bridge GRT to Polygon. You will have to wait 7-8 minutes after the transaction is complete for the bridge transfer to be finalized. -3. Once your GRT is available on your Polygon balance you can deposit them to the billing contract while specifying the multisig address you are funding in the `Multisig Address` field. +1. Conecta tu wallet estándar / EOA (esta wallet necesita poseer algo de ETH así como GRT que quieres depositar) +2. Transfiere a traves del puente GRT a Polygon. Tendrás que esperar entre 7 y 8 minutos después de que se complete la transacción para que finalice la transferencia del puente. +3. Una vez que tus GRT estén disponible en tu saldo de Polygon, puedes depositarlos en el contrato de facturación mientras especificas la dirección multisig que estás financiando en el campo `Multisig Address`. -Once the deposit transaction has been confirmed you can go back to [Subgraph Studio](https://thegraph.com/studio/) and connect with your Gnosis Safe Multisig to create API keys and use them to generate queries. +Una vez confirmada la transacción de depósito, puedes volver a [Subgraph Studio](https://thegraph.com/studio/) y conectarte con tu Gnosis Safe Multisig para crear claves API y utilizarlas para generar consultas. -Those queries will generate invoices that will be paid automatically using the multisig’s billing balance. +Esas consultas generarán facturas que se pagarán automáticamente con el saldo de facturación de la multisig. diff --git a/pages/es/studio/studio-faq.mdx b/pages/es/studio/studio-faq.mdx index e228ed8b1543..56308696424f 100644 --- a/pages/es/studio/studio-faq.mdx +++ b/pages/es/studio/studio-faq.mdx @@ -14,14 +14,14 @@ R: ¡Sí! Puedes crear varias claves API para utilizarlas en diferentes proyecto Después de crear una Clave de API, en la sección Seguridad puedes definir los dominios que pueden consultar una Clave de API específica. -### 4. ¿Cómo puedo encontrar las URL de consulta de los subgrafos si no soy el desarrollador del subgrafo que quiero utilizar? +### 4. ¿Puedo transferir mi subgrafo a otro titular? -Puedes encontrar la URL de consulta de cada subgrafo en la sección Detalles del Subgrafo de the Graph Explorer. Al hacer clic en el botón "Query", se te dirigirá a un panel en el que podrás ver la URL de consulta del subgrafo te interesa. A continuación, puedes sustituir el marcador de posición `` por la clave de la API que deseas aprovechar en el Subgraph Studio. +Sí, los subgrafos que han sido publicados en Mainnet pueden ser transferidos a una nueva wallet o a una Multisig. Puedes hacerlo haciendo clic en los tres puntos junto al botón "Publicar" en la página de detalles del subgrafo y seleccionando "Transferir propiedad". -Recuerda que puedes crear una clave API y consultar cualquier subgrafo publicado en la red, incluso si tú mismo construyes un subgrafo. Estas consultas a través de la nueva clave API, son consultas pagas como cualquier otra en la red. +Ten en cuenta que ya no podrás ver o editar el subgrafo en Studio una vez que haya sido transferido. -### 5. How do I find query URLs for subgraphs if I’m not the developer of the subgraph I want to use? +### 5. ¿Cómo puedo encontrar las URL de consulta de los subgrafos si no soy el desarrollador del subgrafo que quiero utilizar? -You can find the query URL of each subgraph in the Subgraph Details section of The Graph Explorer. When you click on the “Query” button, you will be directed to a pane wherein you can view the query URL of the subgraph you’re interested in. You can then replace the `` placeholder with the API key you wish to leverage in the Subgraph Studio. +Puedes encontrar la consulta URL de cada subgrafo en la sección Detalles del Subgrafo de The Graph Explorer. Cuando haces clic en el botón de "Query" (Consulta), serás dirigido a un panel en el que puedes ver la URL de consulta del subgrafo que te interesa. A continuación, puedes sustituir el marcador de posición `` por la clave API que deseas aprovechar en Subgraph Studio. -Remember that you can create an API key and query any subgraph published to the network, even if you build a subgraph yourself. These queries via the new API key, are paid queries as any other on the network. +Recuerda que puedes crear una clave API y consultar cualquier subgrafo publicado en la red, incluso si tú mismo construyes un subgrafo. Estas consultas a través de la nueva clave API, son consultas pagadas como cualquier otra en la red. diff --git a/pages/ja/delegating.mdx b/pages/ja/delegating.mdx index 8cf7e8749dfb..0db2a637cd9e 100644 --- a/pages/ja/delegating.mdx +++ b/pages/ja/delegating.mdx @@ -53,7 +53,7 @@ title: デリゲーティング ### デリゲーターの期待リターンを計算 -A Delegator has to consider a lot of factors when determining the return. These include: +デリゲーターはリターンを決定する際に多くの要素を考慮する必要があります。 これらは以下の通りです： - デリゲーターは、インデクサーが利用可能なデリゲートトークンを使用する能力にも目を向けることができます。 もしインデクサーが利用可能なトークンをすべて割り当てていなければ、彼らは自分自身やデリゲーターのために得られる最大の利益を得られないことになります。 - 現在のネットワークでは、インデクサーは 1 日から 28 日の間であればいつでも割り当てを終了して報酬を受け取ることができます。 そのため、インデクサーがまだ回収していない報酬をたくさん抱えている可能性があり、その結果、報酬の総額が少なくなっています。 これは初期の段階で考慮しておく必要があります。 @@ -68,7 +68,7 @@ A Delegator has to consider a lot of factors when determining the return. These したがって、デリゲーターは計算して、デリゲーターに 20％を提供しているインデクサーの方が、より良いリターンを提供していると判断することができます。 -![Share formula](/img/Share-Forumla.png) +![シェアの計算式](/img/Share-Forumla.png) もうひとつ考慮しなければならないのが、デリゲーション能力です。 現在、デリゲーションレシオは 16 に設定されています。 これは、インデクサーが 1,000,000GRT をステークしている場合、そのデリゲーション容量はプロトコルで使用できる 16,000,000GRT のデリゲーショントークンであることを意味します。 この量を超えるデリゲートされたトークンは、全てのデリゲーター報酬を薄めてしまいます。 @@ -80,11 +80,11 @@ A Delegator has to consider a lot of factors when determining the return. These この式を使うと、デリゲーターに 20％しか提供していないインデクサーが、デリゲーターに 90％を提供しているインデクサーよりも、デリゲーターにさらに良い報酬を与えている可能性があることがわかります。 -Therefore a Delegator should always consider the Delegation Capacity of an Indexer, and factor it into their decision making. +したがって、デリゲーターはインデクサーのデリゲーション・キャパシティを常に考慮し、意思決定に反映させる必要があります。 ## ネットワーク UI のビデオガイド -This guide provides a full review of this document, and how to consider everything in this document while interacting with the UI. +この式を使うと、デリゲーターに 20％しか提供していないインデクサーが、デリゲーターに 90％を提供しているインデクサーよりも、デリゲーターにさらに良い報酬を与えている可能性があることがわかります。
-- [The Graph Network Contracts](https://github.com/graphprotocol/contracts) -- [Curation Contract](https://github.com/graphprotocol/contracts/blob/dev/contracts/curation/Curation.sol) - the underlying contract that the GNS wraps around - - Address - `0x8fe00a685bcb3b2cc296ff6ffeab10aca4ce1538` -- [Subgraph Studio documentation](/studio/subgraph-studio) +- [The Graph Network のコントラクト](https://github.com/graphprotocol/contracts) +- [キュレーションコントラクト](https://github.com/graphprotocol/contracts/blob/dev/contracts/curation/Curation.sol) - GNS が包括する基本的なコントラクト + - アドレス - `0x8fe00a685bcb3b2cc296ff6ffeab10aca4ce1538` +- [Subgraph Studio ドキュメント](/studio/subgraph-studio) diff --git a/pages/ja/studio/studio-faq.mdx b/pages/ja/studio/studio-faq.mdx index e8fa300eb771..7612dddff07b 100644 --- a/pages/ja/studio/studio-faq.mdx +++ b/pages/ja/studio/studio-faq.mdx @@ -20,8 +20,8 @@ API キーを作成後、「セキュリティ」セクションで、特定の API キーを作成すると、自分でサブグラフを構築した場合でも、ネットワークに公開されているすべてのサブグラフにクエリを実行できることを覚えておいてください。新しい API キーを介したこれらのクエリは、ネットワーク上の他のクエリと同様に支払われます。 -### 5. How do I find query URLs for subgraphs if I’m not the developer of the subgraph I want to use? +### 5. 使用したいサブグラフのクエリ URL を見つける方法は？ -You can find the query URL of each subgraph in the Subgraph Details section of The Graph Explorer. When you click on the “Query” button, you will be directed to a pane wherein you can view the query URL of the subgraph you’re interested in. You can then replace the `` placeholder with the API key you wish to leverage in the Subgraph Studio. +各サブグラフのクエリ URL は、Graph Explorer の「Subgraph Details」で確認できます。「Query」をクリックすると、興味のあるサブグラフのクエリ URL が表示されます。ここで``というプレースホルダーを、Subgraph Studio で利用したい API キーに置き換えることができます。 -Remember that you can create an API key and query any subgraph published to the network, even if you build a subgraph yourself. These queries via the new API key, are paid queries as any other on the network. +API キーを作成すると、自分でサブグラフを構築した場合でも、ネットワークに公開されているすべてのサブグラフにクエリを実行できることを覚えておいてください。新しい API キーを介したこれらのクエリは、ネットワーク上の他のクエリと同様に支払われます。 diff --git a/pages/ko/developer/assemblyscript-migration-guide.mdx b/pages/ko/developer/assemblyscript-migration-guide.mdx index ffddd65d68ed..ad2fb218a699 100644 --- a/pages/ko/developer/assemblyscript-migration-guide.mdx +++ b/pages/ko/developer/assemblyscript-migration-guide.mdx @@ -180,7 +180,8 @@ let c: usize = a + (b as usize) // upcasting on class inheritance class Bytes extends Uint8Array {} -let bytes = new Bytes(2) < Uint8Array > bytes // same as: bytes as Uint8Array +let bytes = new Bytes(2) +// bytes // same as: bytes as Uint8Array ``` 어느 부분에선 캐스트하고 싶지만, `as`/`var`를 사용하는 것은 **안전하지 않은** 두 가지 시나리오가 존재합니다. @@ -192,7 +193,8 @@ let bytes = new Bytes(2) < Uint8Array > bytes // same as: bytes as Uint8Array // downcasting on class inheritance class Bytes extends Uint8Array {} -let uint8Array = new Uint8Array(2) < Bytes > uint8Array // breaks in runtime :( +let uint8Array = new Uint8Array(2) +// uint8Array // breaks in runtime :( ``` ```typescript @@ -200,7 +202,8 @@ let uint8Array = new Uint8Array(2) < Bytes > uint8Array // breaks in runtime :( class Bytes extends Uint8Array {} class ByteArray extends Uint8Array {} -let bytes = new Bytes(2) < ByteArray > bytes // breaks in runtime :( +let bytes = new Bytes(2) +// bytes // breaks in runtime :( ``` 이러한 경우들에는 `changetype` 기능을 사용할 수 있습니다: diff --git a/pages/vi/developer/assemblyscript-migration-guide.mdx b/pages/vi/developer/assemblyscript-migration-guide.mdx index 7b27cddb3c25..7af2e4782a29 100644 --- a/pages/vi/developer/assemblyscript-migration-guide.mdx +++ b/pages/vi/developer/assemblyscript-migration-guide.mdx @@ -177,10 +177,11 @@ let c: usize = a + (b as usize) ``` ```typescript -// upcasting về kế thừa lớp +// upcasting on class inheritance class Bytes extends Uint8Array {} -let bytes = new Bytes(2) < Uint8Array > bytes // same as: bytes as Uint8Array +let bytes = new Bytes(2) +// bytes // same as: bytes as Uint8Array ``` Có hai trường hợp mà bạn có thể muốn ép kiểu, nhưng việc sử dụng `as`/`var` **không an toàn**: @@ -189,18 +190,20 @@ Có hai trường hợp mà bạn có thể muốn ép kiểu, nhưng việc s - Giữa hai loại chia sẻ lớp cha ```typescript -// dự báo về kế thừa lớp +// downcasting on class inheritance class Bytes extends Uint8Array {} -let uint8Array = new Uint8Array(2) < Bytes > uint8Array // breaks in runtime :( +let uint8Array = new Uint8Array(2) +// uint8Array // breaks in runtime :( ``` ```typescript -// giữa hai loại chia sẻ lớp cha +// between two types that share a superclass class Bytes extends Uint8Array {} class ByteArray extends Uint8Array {} -let bytes = new Bytes(2) < ByteArray > bytes // ngắt trong thời gian chạy :( +let bytes = new Bytes(2) +// bytes // breaks in runtime :( ``` Đối với những trường hợp đó, bạn có thể sử dụng hàm `changetype`: diff --git a/pages/vi/hosted-service/migrating-subgraph.mdx b/pages/vi/hosted-service/migrating-subgraph.mdx index 9c2fc216a650..1bcde4a57054 100644 --- a/pages/vi/hosted-service/migrating-subgraph.mdx +++ b/pages/vi/hosted-service/migrating-subgraph.mdx @@ -13,7 +13,7 @@ The process of migration is quick and your subgraphs will forever benefit from t If your subgraph is: - Indexing [IPFS](https://ipfs.io/). -- Using [full-text search fields](https://thegraph.com/docs/en/developer/create-subgraph-hosted/#defining-fulltext-search-fields). +- Using [full-text search fields](/developer/create-subgraph-hosted/#defining-fulltext-search-fields). - Indexing chains other than Ethereum mainnet. ### Migrating an Existing Subgraph to The Graph Network diff --git a/pages/zh/about/introduction.mdx b/pages/zh/about/introduction.mdx index e26f12cd8076..0135265f0930 100644 --- a/pages/zh/about/introduction.mdx +++ b/pages/zh/about/introduction.mdx @@ -32,7 +32,7 @@ Graph 根据子图描述（称为子图清单）来学习什么以及如何为 ![](/img/graph-dataflow.png) -The flow follows these steps: +流程遵循这些步骤： 1. 一个去中心化的应用程序通过智能合约上的交易向以太坊添加数据。 2. 智能合约在处理交易时，会发出一个或多个事件。 diff --git a/pages/zh/delegating.mdx b/pages/zh/delegating.mdx index d63360b6a0ed..016ee2b659eb 100644 --- a/pages/zh/delegating.mdx +++ b/pages/zh/delegating.mdx @@ -1,5 +1,5 @@ --- -title: 委托 +title: 委托人 --- 委托人不能因为不良行为而被取消，但对委托有存款税，以抑制可能损害网络完整性的不良决策。 @@ -50,7 +50,7 @@ title: 委托 ### 计算委托人的预期收益 -A Delegator has to consider a lot of factors when determining the return. These include: +委托人在确定收益时必须考虑很多因素。 这些因素解释如下 ： - 有技术的委托人还可以查看索引人使用他们可用的委托代币的能力。 如果索引人没有分配所有可用的代币，他们就不会为自己或他们的委托人赚取最大利润。 - 现在在网络中，索引人可以选择关闭分配并在 1 到 28 天之间的任何时间收集奖励。 因此，索引人可能有很多尚未收集的奖励，因此他们的总奖励很低。 早期应该考虑到这一点。 @@ -77,11 +77,11 @@ A Delegator has to consider a lot of factors when determining the return. These 使用这个公式，我们可以看到实际上只向委托人提供 20％的索引人比给索引人提供 90％的索引人实际上给予委托人更好的奖励。 -Therefore a Delegator should always consider the Delegation Capacity of an Indexer, and factor it into their decision making. +因此，委托人应始终考虑索引人的接受委托数量的容量，并将其纳入决策。 ## 网络界面视频指南 -This guide provides a full review of this document, and how to consider everything in this document while interacting with the UI. +本指南提供了对本文档的完整检阅，以及如何在与 UI 交互时考虑本文档中的所有内容。
-- [The Graph Network Contracts](https://github.com/graphprotocol/contracts) -- [Curation Contract](https://github.com/graphprotocol/contracts/blob/dev/contracts/curation/Curation.sol) - the underlying contract that the GNS wraps around - - Address - `0x8fe00a685bcb3b2cc296ff6ffeab10aca4ce1538` -- [Subgraph Studio documentation](/studio/subgraph-studio) +- [The Graph 网络合约](https://github.com/graphprotocol/contracts) +- [Curation Contract](https://github.com/graphprotocol/contracts/blob/dev/contracts/curation/Curation.sol) - GNS 包裹的底层合约 + - 地址 - `0x8fe00a685bcb3b2cc296ff6ffeab10aca4ce1538` +- [子图工作室文档](/studio/subgraph-studio) diff --git a/pages/zh/hosted-service/what-is-hosted-service.mdx b/pages/zh/hosted-service/what-is-hosted-service.mdx index d07bcc04c1c9..2d17f123d992 100644 --- a/pages/zh/hosted-service/what-is-hosted-service.mdx +++ b/pages/zh/hosted-service/what-is-hosted-service.mdx @@ -4,17 +4,17 @@ title: 什么是托管服务？ 本节将引导您将子图部署到 [托管服务](https://thegraph.com/hosted-service/) 提醒一下，托管服务不会很快关闭。 一旦去中心化网络达到托管服务相当的功能，我们将逐步取消托管服务。 您在托管服务上部署的子图在[此处](https://thegraph.com/hosted-service/)仍然可用。 -If you don't have an account on the Hosted Service, you can signup with your Github account. Once you authenticate, you can start creating subgraphs through the UI and deploying them from your terminal. Graph Node supports a number of Ethereum testnets (Rinkeby, Ropsten, Kovan) in addition to mainnet. +如果您没有托管服务帐户，您可以使用您的 Github 帐户注册。 进行身份验证后，您可以开始通过 UI 创建子图并从终端部署它们。 除了主网之外，Graph Node 还支持许多以太坊测试网（Rinkeby、Ropsten、Kovan）。 ## 创建子图 -First follow the instructions [here](/developer/define-subgraph-hosted) to install the Graph CLI. Create a subgraph by passing in `graph init --product hosted service` +首先按照[此处](/developer/define-subgraph-hosted)的说明安装 Graph CLI。 通过传入 `graph init --product hosting service` 创建子图 -### From an Existing Contract +### 基于现有合约 -If you already have a smart contract deployed to Ethereum mainnet or one of the testnets, bootstrapping a new subgraph from this contract can be a good way to get started on the Hosted Service. +如果您已经将智能合约部署到以太坊主网或其中一个测试网，那么从该合约中引导一个新的子图可能是开始使用托管服务的好方法。 -You can use this command to create a subgraph that indexes all events from an existing contract. This will attempt to fetch the contract ABI from [Etherscan](https://etherscan.io/). +您可以使用此命令创建一个子图，为现有合约中的所有事件编制索引。 这将尝试从 [Etherscan](https://etherscan.io/) 获取合约 ABI。 ```sh graph init \ @@ -23,16 +23,16 @@ graph init \ / [] ``` -Additionally, you can use the following optional arguments. If the ABI cannot be fetched from Etherscan, it falls back to requesting a local file path. If any optional arguments are missing from the command, it takes you through an interactive form. +此外，您可以使用以下可选参数。 如果无法从 Etherscan 获取 ABI，它会退回到请求本地文件路径。 如果命令中缺少任何可选参数，它会带您进入交互式表单。 ```sh --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 Ethereum network that the contract lives on. `` is a local path to a contract ABI file. **Both --network and --abi are optional.** +`` 在这种情况下是您的 github 用户或组织名称, ``是您的子图的名称，并且`` Graph 初始化将放置示例子图清单的目录的可选名称。 ``是您现有合约的地址。 `` 是合约所在的以太坊网络的名称。``是合约 ABI 文件的本地路径。**Both --network 和 --abi 都是可选的。** -### From an Example Subgraph +### 基于子图示例 `graph init` 支持的第二种模式是从示例子图创建一个新项目。 以下命令执行此操作： @@ -40,7 +40,7 @@ The `` in this case is your github user or organization name, `/ [] ``` -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](/developer/create-subgraph-hosted#the-subgraph-manifest) to better understand which events from your smart contracts to pay attention to, mappings, and more. +示例子图基于 Dani Grant 的 Gravity 合约，该合约管理用户头像并在创建或更新头像时发出 `NewGravatar` 或 `UpdateGravatar` 事件。 子图通过将 `Gravatar` 实体写入 Graph 节点存储并确保根据事件更新这些事件来处理这些事件。 继续查看[子图清单](/developer/create-subgraph-hosted#the-subgraph-manifest)，以更好地了解您的智能合约中需要关注的事件、映射等。 ## 托管服务支持的网络 diff --git a/pages/zh/studio/multisig.mdx b/pages/zh/studio/multisig.mdx index 41aba4457698..59d19d092813 100644 --- a/pages/zh/studio/multisig.mdx +++ b/pages/zh/studio/multisig.mdx @@ -1,82 +1,82 @@ --- -title: Using a Multisig Wallet +title: 使用多重签名钱包 --- -Subgraph Studio currently doesn't support signing with multisig wallets. Until then, you can follow this guide on how to publish your subgraph by invoking the [GNS contract](https://github.com/graphprotocol/contracts/blob/dev/contracts/discovery/GNS.sol) functions. +Subgraph Studio 目前不支持使用多重签名钱包进行签名。 在此之前，您可以按照本指南了解如何通过调用 [GNS 合约](https://github.com/graphprotocol/contracts/blob/dev/contracts/discovery/GNS.sol)函数来发布您的子图。 ### 创建子图 -Similary to using a regular wallet, you can create a subgraph by connecting your non-multisig wallet in Subgraph Studio. Once you connect the wallet, simply create a new subgraph. Make sure you fill out all the details, such as subgraph name, description, image, website, and source code url if applicable. +与使用普通钱包类似，您可以通过在 Subgraph Studio 中连接您的非多重签名钱包来创建子图。 连接钱包后，只需创建一个新的子图。 确保填写所有详细信息，例如子图名称、描述、图像、网站和源代码 Url（如果适用）。 -For initializing a starter subgraph, you can follow the commands shown in the UI, or simply run +要初始化起始子图，您可以按照 UI 中显示的命令进行操作，或者直接运行 ``` graph init --studio ``` -`SUBGRAPH_SLUG` is the name of your subgraph that you can copy from the UI, or from the URL in the browser. This command should create a folder in your file system with all the necessary files to start developing a subgraph. +`SUBGRAPH_SLUG` 是您可以从 UI 或浏览器中的 URL 复制的子图的名称。 此命令应在文件系统中创建一个文件夹，其中包含开始开发子图所需的所有文件。 -### Deploy a Subgraph +### 部署一个子图 -Once your subgraph is ready to be deployed to the graph node, simply follow the commands shown in the UI, or run the following command: +一旦您的子图准备好部署到图节点，只需按照 UI 中显示的命令，或运行以下命令： ``` graph deploy --studio ``` -**Note**: Make sure that you are inside of the subgraph folder before running the command. +**注意**：在运行命令之前，请确保您位于 subgraph 文件夹中。 -### Publish a Subgraph or a Version +### 发布子图或版本 -You can either publish a new subgraph to the decentralized network or publish a new version of the previously published subgraph. +您可以将新的子图发布到去中心化网络，也可以发布先前发布的子图的新版本。 -#### Publish a New Subgraph +#### 发布新子图 -There are a couple of ways to publish a subgraph using multisig wallets. Here we'll describe invoking the [`publishNewSubgraph`](https://github.com/graphprotocol/contracts/blob/dev/contracts/discovery/GNS.sol#L231) function in the [GNS contract](https://etherscan.io/address/0xaDcA0dd4729c8BA3aCf3E99F3A9f471EF37b6825) using Etherscan. +有几种方法可以使用多重签名钱包发布子图。 在这里，我们将描述使用 Etherscan 在 [GNS 合约](https://etherscan.io/address/0xaDcA0dd4729c8BA3aCf3E99F3A9f471EF37b6825)中调用[ publishNewSubgraph 函数](https://github.com/graphprotocol/contracts/blob/dev/contracts/discovery/GNS.sol#L231)。 -Before we use that function, we need to generate input arguments for it. Access [this page](https://thegraph.com/studio/multisig) in Subgraph Studio and provide the following: +在我们使用该函数之前，我们需要为其生成输入参数。 在 Subgraph Studio 中访问此[页面](https://thegraph.com/studio/multisig)并提供以下内容： -- Ethereum address of your multisig wallet -- Subgraph that you want to publish -- Version that you want to publish +- 你的多重签名钱包的以太坊地址 +- 您要发布的子图 +- 您要发布的版本 -After clicking on "Get Arguments", we'll generate all the contract arguments for you! +点击“获取参数”后，我们将为您生成所有合约参数！ -There should be 4 arguments: +应该有 4 个参数： -- `graphAccount`: which is your multisig account address -- `subgraphDeploymentID`: the hex hash of the deployment ID for that subgraph -- `versionMetadata`: version metadata (label and description) that gets uploaded to IPFS. The hex hash value for that JSON file will be provided. -- `subgraphMetadata`: simlar to version metadata, subgraph metadata (name, image, description, website and source code url) gets uploaded to IPFS, and we provide the hex hash value for that JSON file +- `graphAccount`：这是您的多重签名帐户地址 +- `subgraphDeploymentID`：该子图的部署 ID 的十六进制哈希 +- `versionMetadata`：上传到 IPFS 的版本元数据（标签和描述）。 将提供该 JSON 文件的十六进制哈希值。 +- `subgraphMetadata`：类似于版本元数据，子图元数据（名称、图像、描述、网站和源代码 url）被上传到 IPFS，我们为该 JSON 文件提供十六进制哈希值 -With those 4 arguments, you should be able to: +使用这 4 个参数，您应该能够： -- Visit [our GraphProxy](https://etherscan.io/address/0xaDcA0dd4729c8BA3aCf3E99F3A9f471EF37b6825#writeProxyContract) contract on Etherscan -- Connect to Etherscan using WalletConnect via the WalletConnect Safe app of your multisig -- Call the `publishNewSubgraph` method with the paramaters that were generated by our tool +- 在 Etherscan 上访问 [我们的 GraphProxy](https://etherscan.io/address/0xaDcA0dd4729c8BA3aCf3E99F3A9f471EF37b6825#writeProxyContract) 合约 +- 通过您的多重签名的 WalletConnect Safe 应用程序使用 WalletConnect 连接到 Etherscan +- 使用我们的工具生成的参数调用 `publishNewS subgraph` 方法 -#### Publish a New Version +#### 发布新版本 -To publish a new version of an existing subgraph we first need to generate input arguments for it. Access [this page](https://thegraph.com/studio/multisig) in Subgraph Studio and provide: +要发布现有子图的新版本，我们首先需要为其生成输入参数。 在 Subgraph Studio 中访问 [此页面](https://thegraph.com/studio/multisig) 并提供： -- Ethereum address of your multisig wallet -- Subgraph that you want to publish -- Version that you want to publish -- The ID of the subgraph you want to update in Graph Explorer +- 你的多重签名钱包的以太坊地址 +- 您要发布的子图 +- 您要发布的版本 +- 您要在 Graph Explorer 中更新的子图的 ID -After clicking on "Get Arguments" we'll generate all the contract arguments for you! +单击“获取参数”后，我们将为您生成所有合同参数！ -On the right side of the UI under the `Publish New Version` title, there should be 4 arguments: +在 UI 右侧的 `Publish New Version` 标题下，应该有 4 个参数： -- `graphAccount`: which is your Multisig account address -- `subgraphNumber`: is the number of your already published subgraph. It is a part of the subgraph id for a published subgraph queried through The Graph Network subgraph. -- `subgraphDeploymentID`: which is the hex hash of the deployment ID for that subgraph -- `versionMetadata`: version metadata (label and description) gets uploaded to IPFS, and we provide the hex hash value for that JSON file +- `graphAccount`：这是您的多重签名帐户地址 +- `subgraphNumber`：是您已经发布的子图的编号。 它是通过 The Graph Network 子图查询的已发布子图的子图 Id 的一部分。 +- `subgraphDeploymentID`：该子图的部署 ID 的十六进制哈希 +- `versionMetadata`：版本元数据（标签和描述）被上传到 IPFS，我们为该 JSON 文件提供十六进制哈希值 -Now that we generated all the arguments you are ready to proceed and call the `publishNewVersion` method. In order to do so, you should: +现在我们生成了所有参数，您可以继续并调用 `publishNewVersion` 方法。 为此，您应该： -- Visit [the GraphProxy](https://etherscan.io/address/0xaDcA0dd4729c8BA3aCf3E99F3A9f471EF37b6825#writeProxyContract) contract on Etherscan -- Connect to Etherscan using WalletConnect via the WalletConnect Safe app of your Multisig -- Call the `publishNewVersion` method with the paramaters that were generated by our tool +- 在 Etherscan 上访问 [我们的 GraphProxy](https://etherscan.io/address/0xaDcA0dd4729c8BA3aCf3E99F3A9f471EF37b6825#writeProxyContract) 合约 +- 通过您的多重签名的 WalletConnect Safe 应用程序使用 WalletConnect 连接到 Etherscan +- 使用我们的工具生成的参数调用 `publish Version` 方法 -Once the transaction is successful, your subgraph should have a new version of your subgraph in Graph Explorer which means that curators can start signaling on it and indexers can start indexing it. +事务成功后，您的子图应该在 Graph Explorer 中有一个新版本的子图，这意味着管理员可以开始对其发出信号，索引器可以开始对其进行索引。 diff --git a/pages/zh/studio/studio-faq.mdx b/pages/zh/studio/studio-faq.mdx index 5fe212921a21..7cb6a7065869 100644 --- a/pages/zh/studio/studio-faq.mdx +++ b/pages/zh/studio/studio-faq.mdx @@ -20,8 +20,8 @@ title: 子图工作室常见问题 请记住，你可以创建一个 API 密钥并查询发布到网络上的任何子图，即使你自己建立了一个子图。 这些通过新的 API 密钥进行的查询，与网络上的任何其他查询一样，都是付费查询。 -### 5. How do I find query URLs for subgraphs if I’m not the developer of the subgraph I want to use? +### 5. 如果我不是我想使用的子图的开发者，我怎样才能找到子图的查询 URL？ -You can find the query URL of each subgraph in the Subgraph Details section of The Graph Explorer. When you click on the “Query” button, you will be directed to a pane wherein you can view the query URL of the subgraph you’re interested in. You can then replace the `` placeholder with the API key you wish to leverage in the Subgraph Studio. +你可以在 The Graph Explorer 的 Subgraph Details 部分找到每个子图的查询 URL。 当你点击 "查询 "按钮时，你将被引导到一个窗格，在这里你可以查看你感兴趣的子图的查询 URL。 然后你可以把 `api_key` 占位符替换成你想在 Subgraph Studio 中利用的 API 密钥。 -Remember that you can create an API key and query any subgraph published to the network, even if you build a subgraph yourself. These queries via the new API key, are paid queries as any other on the network. +请记住，你可以创建一个 API 密钥并查询发布到网络上的任何子图，即使你自己建立了一个子图。 这些通过新的 API 密钥进行的查询，与网络上的任何其他查询一样，都是付费查询。 diff --git a/pages/zh/studio/subgraph-studio.mdx b/pages/zh/studio/subgraph-studio.mdx index bb722e2a07cf..d480d4e0f808 100644 --- a/pages/zh/studio/subgraph-studio.mdx +++ b/pages/zh/studio/subgraph-studio.mdx @@ -1,70 +1,70 @@ --- -title: How to Use the Subgraph Studio +title: 如何使用子图工作室 --- -Welcome to your new launchpad 👩🏽‍🚀 +欢迎使用您的新启动板 👩🏽‍🚀 -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](/explorer)). +Subgraph Studio 是您构建和创建子图、添加元数据并将其发布到新的分散式资源管理器的地方（更多关于[这里](/explorer)）。 -What you can do in the Subgraph Studio: +您可以在 Subgraph Studio 中执行的操作： -- Create a subgraph through the Studio UI -- Deploy a subgraph using the CLI -- Publish a subgraph with the Studio UI -- Test it in the playground -- Integrate it in staging using the query URL -- Create and manage your API keys for specific subgraphs +- 通过 Studio UI 创建子图 +- 使用 CLI 部署子图 +- 使用 Studio UI 发布子图 +- 在面板上测试子图 +- 使用查询 URL 将其集成到暂存中 +- 为特定子图创建和管理 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. +在 Subgraph Studio 中，您可以完全控制您的子图。 您不仅可以在发布子图之前对其进行测试，还可以将 API 密钥限制在特定域中，并且只允许某些索引器从其 API 密钥中进行查询。 -Querying subgraphs generates query fees, used to reward [indexers](/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: +查询子图会产生查询费，用于奖励 Graph 网络上的[索引人](/indexing)。 如果您是 dapp 开发人员或子图开发人员，Studio 将使您能够构建更好的子图来支持您或您的社区的查询。 Studio 由 5 个主要部分组成： -- Your user account controls -- A list of subgraphs that you’ve created -- A section to manage, view details, and visualize the status of a specific subgraph -- A section to manage your API keys that you will need to query a subgraph -- A section to manage your billing +- 您的用户帐户控制 +- 您创建的子图列表 +- 用于管理、查看详细信息和可视化特定子图状态的部分 +- 用于管理 API 密钥的部分，您需要查询子图 +- 管理帐单的部分 -## How to Create Your Account +## 如何创建您的帐户 -1. Sign in with your wallet - you can do this via MetaMask or WalletConnect -1. Once you sign in, you will see your unique deploy key in 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. +1. 使用您的钱包登录 - 您可以通过 MetaMask 或 WalletConnect 进行此操作 +1. 登录后，您将在帐户主页中看到您唯一的部署密钥。 这将允许您发布您的子图或管理您的 API 密钥 + 计费。 如果您认为它已被泄露，您将拥有一个可以重新生成的唯一部署密钥。 -## How to Create your Subgraph in Subgraph Studio +## 如何在 Subgraph Studio 中创建子图 -The best part! When you first create a subgraph, you’ll be directed to fill out: +最好的部分！ 当您第一次创建子图时，您将被指示填写： -- Your Subgraph Name -- Image +- 您的子图名称 +- 图片 - 描述 -- Categories -- Website +- 类别 +- 网站 -## Subgraph Compatibility with The Graph Network +## 子图与 The Graph 网络的兼容性 -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: +The Graph 网络还不能支持所有的数据源和 托管服务上可用的功能。 为了被网络上的索引器支持，子图必须： -- Index mainnet Ethereum -- Must not use any of the following features: +- 索引主网以太坊 +- 不得使用以下任何功能： - ipfs.cat & ipfs.map - - Non-fatal errors + - 非致命错误 - Grafting -More features & networks will be added to The Graph Network incrementally. +更多功能和 网络将逐渐添加到 The Graph Network。 -### Subgraph lifecycle flow +### 子图生命周期流程 -![Subgraph Lifecycle](/img/subgraph-lifecycle.png) +![子图生命周期](/img/subgraph-lifecycle.png) -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](/developer/define-subgraph-hosted#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. +创建子图后，您将能够使用 [CLI](https://github.com/graphprotocol/graph-cli) 或命令行界面来部署它。 使用 CLI 部署子图会将子图推送到 Studio，您可以在其中使用 Playground 测试子图。 这最终将允许您发布到 Graph Network。 有关 CLI 设置的更多信息，[检查一下](/developer/define-subgraph-hosted#install-the-graph-cli)（pst，确保您手头有部署密钥）. 请记住，部署是**与**发布不同。 当您部署一个子图时，您只需将其推送到您可以对其进行测试的 Studio。 相反，当你发布一个子图时，你是在链上发布它。 -## Testing your Subgraph in Subgraph Studio +## 在 Subgraph Studio 中测试您的子图 -If you’d like to test your subgraph before publishing it to the network, you can do this in the Subgraph **Playground** or look at your logs. The Subgraph logs will tell you **where** your subgraph fails in the case that it does. +如果您想在将子图发布到网络之前对其进行测试，您可以在子图 **Playground** 中执行此操作或查看您的日志。 子图日志将告诉您**在哪里**您的子图在失败的情况下失败。 -## Publish your Subgraph in Subgraph Studio +## 在 Subgraph Studio 中发布您的子图 -You’ve made it this far - congrats! Publishing your subgraph means that an IPFS hash was generated when you deployed the subgraph within the CLI and is stored in the network’s Ethereum smart contracts. 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). Check out the video overview below as well: +你已经做到了这一点 - 恭喜！ 发布子图意味着当您在 CLI 中部署子图时会生成 IPFS 哈希，并存储在网络的以太坊智能合约中。 为了成功发布您的子图，您需要完成此[博客](https://thegraph.com/blog/building-with-subgraph-studio)中列出的以下步骤. 还请查看下面的视频概述：
-Remember, while you’re going through your publishing flow, you’ll be able to push to either mainnet or Rinkeby, the testnet we support. If you’re a first time subgraph developer, we highly suggest you start with publishing to Rinkeby, 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. +请记住，在您完成发布流程时，您将能够推送到我们支持的测试网主网或 Rinkeby。 如果您是第一次开发子图，我们强烈建议您从发布到 Rinkeby 开始，这是免费的。 这将允许您查看子图在 The Graph Explorer 中的工作方式，并允许您测试管理元素。 -You’ll only be able to index data from mainnet (even if your subgraph was published to a testnet) because only subgraphs that are indexing mainnet data can be published to the network. This is because 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! +您只能从主网索引数据（即使您的子图已发布到测试网），因为只有索引主网数据的子图才能发布到网络。 这是因为索引人需要提交针对特定块哈希的强制性索引证明记录。 因为发布子图是在链上采取的行动，请记住，交易可能需要几分钟才能完成。 您用于发布合约的任何地址都将是唯一能够发布未来版本的地址。 做出明智的选择！ -Subgraphs with curation signal are shown to Indexers so that they can be indexed on the decentralized network. You can publish subgraphs and signal in one transaction, which allows you to mint the first curation signal on the subgraph and saves on gas costs. By adding your signal to the signal later provided by Curators, your subgraph will also have a higher chance of ultimately serving queries. +具有管理信号的子图显示给索引人，以便它们可以在去中心化网络上被索引。 您可以在一个事务中发布子图和信号，这允许您在子图上创建第一个管理信号并节省气体成本。 通过将您的信号添加到策展人稍后提供的信号中，您的子图也将有更高的机会最终提供查询。 -**Now that you’ve published your subgraph, let’s get into how you’ll manage them on a regular basis.** Note that you cannot publish your subgraph to the network if it has failed syncing. This is usually because the subgraph has bugs - the logs will tell you where those issues exist! +**现在您已经发布了您的子图，让我们来看看您将如何定期管理它们。**请注意，如果您的子图有 同步失败。 这通常是因为子图有错误 - 日志会告诉您这些问题存在于哪里！ -## Versioning your Subgraph with the CLI +## 使用 CLI 对子图进行版本控制 -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. +出于各种原因，开发人员可能想要更新他们的子图。 在这种情况下，您可以使用 CLI 将新版本的子图部署到 Studio（此时它只是私有的），如果您对它感到满意，您可以将此新部署发布到 Graph Explorer。 这将创建一个新版本的子图，策展人可以开始发出信号，索引人将能够索引这个新版本。 -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 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. +直到最近，开发人员还被迫将其子图的新版本部署并发布到 Explorer 以更新其子图的元数据。 现在，开发人员可以更新其子图的元数据**而无需发布新版本**。 开发人员可以通过选中图形资源管理器中名为 **Update Details** 的选项来更新 Studio 中的子图详细信息（在个人资料图片、名称、描述等下）。 如果选中此项，将生成一个链上事务，更新资源管理器中的子图详细信息，而无需发布具有新部署的新版本。 -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 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](/curating). +请注意，将新版本的子图发布到网络会产生成本。 除了交易费用外，开发人员还必须为自动迁移信号的一部分管理税提供资金。 如果策展人没有发出信号，您将无法发布子图的新版本。 有关策展风险的更多信息，请阅读更多[此处](/curating)。 -### Automatic Archiving of Subgraph Versions +### 子图版本的自动归档 -Whenever you deploy a new subgraph version in the Subgraph Studio, the previous version will be archived. Archived versions won't be indexed/synced and therefore cannot be queried. You can unarchive an archived version of your subgraph in the Studio UI. Please note that previous versions of non-published subgraphs deployed to the Studio will be automatically archived. +每当您在 Subgraph Studio 中部署新的子图版本时，都会归档以前的版本。 存档版本不会被索引/同步，因此无法查询。 您可以在 Studio UI 中取消存档子图的存档版本。 请注意，部署到 Studio 的以前版本的未发布子图将被自动存档。 -![Subgraph Studio - Unarchive](/img/Unarchive.png) +![Subgraph Studio - 取消归档](/img/Unarchive.png) -## Managing your API Keys +## 管理您的 API 密钥 -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. +无论您是 dapp 开发人员还是子图开发人员，您都需要管理您的 API 密钥。 这对于您能够查询子图很重要，因为 API 密钥确保应用程序服务之间的连接有效且经过授权。 这包括验证最终用户和使用应用程序的设备。 -The Studio will list out existing API keys, which will give you the ability to manage or delete them. +Studio 将列出现有的 API 密钥，这将使您能够管理或删除它们。 -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 -2. Under **Manage Security Settings**, 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 +1. **概述**部分将允许您： + - 编辑您的密钥名称 + - 重新生成 API 密钥 + - 使用统计信息查看 API 密钥的当前使用情况： + - 查询数 + - 花费的 GRT 金额 +2. 在**管理安全设置**下，您可以根据自己对 API 密钥的控制级别选择启用安全设置。 在本节中，您可以： + - 查看和管理授权使用您的 API 密钥的域名 + - 分配可以使用您的 API 密钥查询的子图 -## How to Manage your Subgraph +## 如何管理您的子图 -API keys aside, you’ll have many tools at your disposal to manage your subgraphs. You can organize your subgraphs by their **status** and **category**. +除了 API 密钥，您还可以使用许多工具来管理子图。 您可以按子图的**状态**和**类别**来组织子图。 -- 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. +- **Status** 标签允许您在各种标签之间进行选择，包括 ``、`` 、``、``等。 +- 同时，**Category** 允许您指定您的子图属于哪个类别。 选项包括``、``、``等。 diff --git a/pages/zh/supported-networks/near.mdx b/pages/zh/supported-networks/near.mdx index 352a54c0b3c4..719a2dab720b 100644 --- a/pages/zh/supported-networks/near.mdx +++ b/pages/zh/supported-networks/near.mdx @@ -72,24 +72,24 @@ dataSources: file: ./src/mapping.ts # link to the file with the Assemblyscript mappings ``` -- NEAR subgraphs introduce a new `kind` of data source (`near`) -- The `network` should correspond to a network on the hosting Graph Node. On the Hosted Service, NEAR's mainnet is `near-mainnet`, and NEAR's testnet is `near-testnet` -- 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 子图引入了一种新的 `kind` 数据源（`near`） +- `network` 应该对应于托管图形节点上的网络。 在 Hosted Service 上，NEAR 的主网是 `near-mainnet`，NEAR 的测试网是 `near-testnet` +- NEAR 数据源引入了一个可选的 `source.account` 字段，这是一个人类可读的 ID，对应于 [NEAR 帐户](https://docs.near.org/docs/concepts/account)。 这可以是一个帐户，也可以是一个子帐户。 -NEAR data sources support two types of handlers: +NEAR 数据源支持两种类型的处理程序： -- `blockHandlers`: run on every new NEAR block. No `source.account` is required. -- `receiptHandlers`: run on every receipt where the data source's `source.account` is the recipient. Note that only exact matches are processed ([subaccounts](https://docs.near.org/docs/concepts/account#subaccounts) must be added as independent data sources). +- `blockHandlers`：在每个新的 NEAR 块上运行。 不需要 `source.account`。 +- `receiptHandlers`：在数据源的 `source.account` 为接收者的每张收据上运行。 请注意，仅处理完全匹配（[子帐户](https://docs.near.org/docs/concepts/account#subaccounts)必须作为独立数据源添加）。 -### Schema Definition +### 模式定义 -Schema definition describes the structure of the resulting subgraph database, and the relationships between entities. This is agnostic of the original data source. There are more details on subgraph schema definition [here](/developer/create-subgraph-hosted#the-graphql-schema). +模式定义描述了生成的子图数据库的结构，以及实体之间的关系。 这与原始数据源无关。 [这里](/developer/create-subgraph-hosted#the-graphql-schema)有更多关于子图模式定义的细节。 -### AssemblyScript Mappings +### AssemblyScript 映射 -The handlers for processing events are written in [AssemblyScript](https://www.assemblyscript.org/). +处理事件的处理程序是用 [AssemblyScript](https://www.assemblyscript.org/) 编写的。 -NEAR indexing introduces NEAR-specific data types to the [AssemblyScript API](/developer/assemblyscript-api). +NEAR 索引将 NEAR 特定的数据类型引入 [AssemblyScript API](/developer/assemblyscript-api)。 ```typescript @@ -151,50 +151,50 @@ class ReceiptWithOutcome { } ``` -These types are passed to block & receipt handlers: +这些类型被传递给 block & 收据处理程序： -- Block handlers will receive a `Block` -- Receipt handlers will receive a `ReceiptWithOutcome` +- 块处理程序将收到一个 `Block` +- 收据处理程序将收到 `ReceiptWithOutcome` -Otherwise the rest of the [AssemblyScript API](/developer/assemblyscript-api) is available to NEAR subgraph developers during mapping execution. +否则，在映射执行期间 NEAR 子图开发人员可以使用 [AssemblyScript API](/developer/assemblyscript-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](/developer/assemblyscript-api#json-api) to allow developers to easily process these logs. +这包括一个新的 JSON 解析功能 - NEAR 上的日志经常作为字符串化 JSON 发出。 一个新的 `json.fromString(...)` 函数作为 [JSON API](/developer/assemblyscript-api#json-api) 的一部分提供给开发人员 轻松处理这些日志。 -## Deploying a NEAR Subgraph +## 部署 NEAR 子图 -Once you have a built subgraph, it is time to deploy it to Graph Node for indexing. NEAR subgraphs can be deployed to any Graph Node `>=v0.26.x` (this version has not yet been tagged & released). +构建子图后，就可以将其部署到 Graph Node 以进行索引了。 NEAR 子图可以部署到任何图节点 `>=v0.26.x`（此版本尚未标记和发布）。 -The Graph's Hosted Service currently supports indexing NEAR mainnet and testnet in beta, with the following network names: +Graph 的托管服务目前支持索引 NEAR 主网和 beta 测试网，具有以下网络名称： -- `near-mainnet` -- `near-testnet` +- `near主网` +- `near-测试网` -More information on creating and deploying subgraphs on the Hosted Service can be found [here](/hosted-service/deploy-subgraph-hosted). +有关在托管服务上创建和部署子图的更多信息，请参见[此处](/hosted-service/deploy-subgraph-hosted)。 -As a quick primer - the first step is to "create" your subgraph - this only needs to be done once. On the Hosted Service, this can be done from [your Dashboard](https://thegraph.com/hosted-service/dashboard): "Add Subgraph". +作为一个快速入门 - 第一步是“创建”你的子图 - 这只需要完成一次。 在托管服务上，这可以通过[您的仪表板](https://thegraph.com/hosted-service/dashboard)：“添加子图”来完成。 -Once your subgraph has been created, you can deploy your subgraph by using the `graph deploy` CLI command: +创建子图后，您可以使用 `graph deploy` CLI 命令部署子图： ``` $ graph create --node subgraph/name # creates a subgraph on a local Graph Node (on the Hosted Service, this is done via the UI) $ 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 ``` -The node configuration will depend where the subgraph is being deployed. +节点配置将取决于子图的部署位置。 -#### Hosted Service: +#### 托管服务: ``` graph deploy --node https://api.thegraph.com/deploy/ --ipfs https://api.thegraph.com/ipfs/ --access-token ``` -#### Local Graph Node (based on default configuration): +#### 本地 Graph 节点（基于默认配置）： ``` graph deploy --node http://localhost:8020/ --ipfs http://localhost:5001 ``` -Once your subgraph has been deployed, it will be indexed by Graph Node. You can check its progress by querying the subgraph itself: +部署子图后，它将由 Graph Node 索引。 您可以通过查询子图本身来检查其进度： ``` { @@ -204,62 +204,62 @@ Once your subgraph has been deployed, it will be indexed by Graph Node. You can } ``` -### Indexing NEAR with a Local Graph Node +### 使用本地 Graph 节点索引 NEAR -Running a Graph Node that indexes NEAR has the following operational requirements: +运行索引 NEAR 的 Graph Node 有以下操作要求： -- NEAR Indexer Framework with Firehose instrumentation -- NEAR Firehose Component(s) -- Graph Node with Firehose endpoint configured +- 带有 Firehose 工具的 NEAR 索引人框架 +- NEAR Firehose 组件 +- 配置了 Firehose 端点的 Graph 节点 -We will provide more information on running the above components soon. +我们将很快提供有关运行上述组件的更多信息。 -## Querying a NEAR Subgraph +## 查询 NEAR 子图 -The GraphQL endpoint for NEAR subgraphs is determined by the schema definition, with the existing API interface. Please visit the [GraphQL API documentation](/developer/graphql-api) for more information. +NEAR 子图的 GraphQL 端点由架构定义确定，具有现有的 API 接口。 请访问 [GraphQL API 文档](/developer/graphql-api) 了解更多信息。 -## Example Subgraphs +## 示例子图 -Here are some example subgraphs for reference: +以下是一些示例子图供参考： -[NEAR Blocks](https://github.com/graphprotocol/example-subgraph/tree/near-blocks-example) +[NEAR 块](https://github.com/graphprotocol/example-subgraph/tree/near-blocks-example) -[NEAR Receipts](https://github.com/graphprotocol/example-subgraph/tree/near-receipts-example) +[NEAR 收据](https://github.com/graphprotocol/example-subgraph/tree/near-receipts-example) ## 常见问题 -### How does the beta work? +### 测试版是如何工作的？ -NEAR support is in beta, which means that there may be changes to the API as we continue to work on improving the integration. Please email near@thegraph.com so that we can support you in building NEAR subgraphs, and keep you up to date on the latest developments! +NEAR 支持处于测试阶段，这意味着随着我们继续致力于改进集成，API 可能会发生变化。 请发送电子邮件至 near@thegraph.com，以便我们支持您构建 NEAR 子图，并让您了解最新进展！ -### Can a subgraph index both NEAR and EVM chains? +### 子图可以同时索引 NEAR 和 EVM 链吗？ -No, a subgraph can only support data sources from one chain / network. +不，一个子图只能支持来自一个链/网络的数据源。 -### Can subgraphs react to more specific triggers? +### 子图可以对更具体的触发器做出反应吗？ -Currently, only Block and Receipt triggers are supported. We are investigating triggers for function calls to a specified account. We are also interested in supporting event triggers, once NEAR has native event support. +目前，仅支持 Block 和 Receipt 触发器。 我们正在调查对指定帐户的函数调用的触发器。 一旦 NEAR 拥有原生事件支持，我们也对支持事件触发器感兴趣。 -### Will receipt handlers trigger for accounts and their sub accounts? +### 收据处理程序会触发帐户及其子帐户吗？ -Receipt handlers will only be triggered for the exact-match of the named account. More flexibility may be added in future. +收据处理程序只会在与指定帐户完全匹配的情况下触发。 未来可能会增加更多的灵活性。 -### Can NEAR subgraphs make view calls to NEAR accounts during mappings? +### NEAR 子图可以在映射期间对 NEAR 帐户进行视图调用吗？ -This is not supported. We are evaluating whether this functionality is required for indexing. +这是不支持的。 我们正在评估索引是否需要此功能。 -### Can I use data source templates in my NEAR subgraph? +### 我可以在 NEAR 子图中使用数据源模板吗？ -This is not currently supported. We are evaluating whether this functionality is required for indexing. +目前不支持此功能。 我们正在评估索引是否需要此功能。 -### Ethereum subgraphs support "pending" and "current" versions, how can I deploy a "pending" version of a NEAR subgraph? +### 以太坊子图支持“待定”和“当前”版本，如何部署 NEAR 子图的“待定”版本？ -Pending functionality is not yet supported for NEAR subgraphs. In the interim, you can deploy a new version to a different "named" subgraph, and then when that is synced with the chain head, you can redeploy to your primary "named" subgraph, which will use the same underlying deployment ID, so the main subgraph will be instantly synced. +NEAR 子图尚不支持挂起的功能。 在此期间，您可以将新版本部署到不同的“命名”子图，然后当它与链头同步时，您可以重新部署到您的主“命名”子图，它将使用相同的底层部署 ID，所以 主子图将立即同步。 -### My question hasn't been answered, where can I get more help building NEAR subgraphs? +### 我的问题尚未得到解答，在哪里可以获得更多构建 NEAR 子图的帮助？ -If it is a general question about subgraph development, there is a lot more information in the rest of the [Developer documentation](/developer/quick-start). Otherwise please join [The Graph Protocol Discord](https://discord.gg/vtvv7FP) and ask in the #near channel, or email near@thegraph.com. +如果是关于子图开发的一般性问题，[开发者文档](/developer/quick-start)的其余部分提供了更多信息。 否则，请加入 [The Graph Protocol Discord](https://discord.gg/vtvv7FP) 并在#near 频道中提问，或发送电子邮件至 near@thegraph.com。 -## References +## 参考 -- [NEAR developer documentation](https://docs.near.org/docs/develop/basics/getting-started) +- [NEAR 开发者文档](https://docs.near.org/docs/develop/basics/getting-started)