نمایه سازی

ایندکسرها به منظور ارائه خدمات نمایه سازی و پردازش پرس و جو ، اپراتورهای گره ای در شبکه گرافیکی هستند که به نشانه های نمودار (GRT) می پردازند. ایندکسرها برای خدمات خود هزینه های پرس و جو و پاداش های نمایه سازی را کسب می کنند. آنها همچنین پس از عملکرد تخفیف Cobb-Douglas ، از یک استخر تخفیف که با همه مشارکت کنندگان شبکه متناسب با کار خود به اشتراک گذاشته می شود ، درآمد کسب می کنند.

GRT که در پروتکل قرار دارد ، منوط به یک دوره ذوب می شود و در صورتی که شاخص ها مخرب باشند و داده های نادرست را برای برنامه ها یا اگر نادرست فهرست بندی می کنند ، می توان کاهش یافت. ایندکسرها همچنین برای مشارکت در شبکه ، برای مشارکت در شبکه ، جوایزی کسب می کنند.

ایندکسرها زیرگرافهایی را برای فهرست بندی ها بر اساس سیگنال احتمالی زیرگراف انتخاب می کنند ، جایی که متصدیان به منظور نشان دادن کدام زیرگراف ها با کیفیت بالا و باید در اولویت قرار بگیرند. مصرف کنندگان (به عنوان مثال برنامه های کاربردی) همچنین می توانند پارامترهایی را تعیین کنند که شاخص ها برای زیرگرافهای خود پرس و جوهای پردازش را پردازش کرده و ترجیحات مربوط به قیمت گذاری پرس و جو را تعیین می کنند.

سطح فنی مورد نیاز است

متداول # پیوند به این بخش

حداقل سهام مورد نیاز برای شاخص بودن در شبکه چقدر است؟# پیوند به این بخش

حداقل سهام برای یک ایندکسر در حال حاضر روی 100K GRT تنظیم شده است.

جریان های درآمد برای یک فهرست گر چیست؟# پیوند به این بخش

تخفیف هزینه های پرس و جو - پرداخت برای ارائه خدمات به نمایش داده ها در شبکه. این پرداخت ها از طریق کانال های ایالتی بین یک شاخص و یک دروازه واسطه می شوند. هر درخواست پرس و جو از یک دروازه حاوی پرداخت و پاسخ مربوطه اثبات اعتبار نتیجه پرس و جو است.

پاداش های نمایه سازی - که از طریق 3 ٪ تورم گسترده پروتکل سالانه تولید می شود ، پاداش های نمایه سازی به فهرسترهایی که در حال نمایش استقرار زیرگراف برای شبکه هستند توزیع می شود.

چگونه جوایز نمایه سازی توزیع می شود؟# پیوند به این بخش

پاداش های نمایه سازی از تورم پروتکل که 3 ٪ صدور سالانه تعیین شده است. آنها بر اساس نسبت کلیه سیگنال های درمانی در هر یک از زیرگرافها توزیع می شوند ، سپس بر اساس سهم اختصاص یافته آنها در آن زیرگراف به طور متناسب به ایندکسرها توزیع می شوند. تخصیص باید با اثبات معتبر نمایه سازی (POI) که مطابق با استانداردهای تعیین شده توسط منشور داوری است ، بسته شود تا واجد شرایط دریافت پاداش باشد.

ابزارهای متعددی توسط جامعه برای محاسبه پاداش ایجاد شده است. مجموعه ای از آنها را خواهید یافت که در مجموعه راهنمای انجمن سازماندهی شده اند. همچنین می توانید فهرستی به روز از ابزارها را در کانال های #Delegators و #Indexers در سرور Discord پیدا کنید. در اینجا ما یک بهینه ساز تخصیص پیشنهادی را که با پشته نرم افزار نمایه ساز یکپارچه شده است پیوند می دهیم.

اثبات نمایه سازی (POI) چیست؟# پیوند به این بخش

از POI ها در شبکه برای تأیید اینکه یک Indexer زیرگراف هایی را که به آنها اختصاص داده اند ایندکس می کند استفاده می شود. یک POI برای اولین بلوک دوره کنونی باید هنگام بستن یک تخصیص ارائه شود تا آن تخصیص واجد شرایط برای نمایه سازی پاداش باشد. یک POI برای یک بلوک خلاصه ای برای تمام تراکنش های فروشگاه موجودیت برای استقرار زیرگراف خاص تا و شامل آن بلوک است.

پاداش های نمایه سازی چه زمانی توزیع می شود؟# پیوند به این بخش

تخصیص ها در حالی که فعال هستند و در 28 دوره تخصیص داده می شوند، به طور مداوم پاداش دریافت می کنند. جوایز توسط Indexers جمع آوری می شود و هر زمان که تخصیص آنها بسته شود توزیع می شود. این اتفاق می افتد یا به صورت دستی، هر زمان که Indexer بخواهد آنها را به اجبار ببندد، یا بعد از 28 دوره، یک Delegator می تواند تخصیص را برای Indexer ببندد، اما این منجر به هیچ پاداشی نمی شود. 28 دوره حداکثر طول عمر تخصیص است (در حال حاضر، یک دوره به طول می انجامد~24 ساعت).

آیا می توان پاداش های فهرست بندی معلق را نظارت کرد؟# پیوند به این بخش

قرارداد RewardsManager دارای تابع getRewards فقط خواندنی است که می تواند برای بررسی پاداش های معلق برای یک تخصیص خاص استفاده شود.

بسیاری از داشبوردهای ساخته شده در جامعه دارای مقادیر پاداش در انتظار هستند و با دنبال کردن این مراحل به راحتی می توان آنها را به صورت دستی بررسی کرد:

1. برای دریافت شناسه های همه تخصیص های فعال، زیرگراف اصلی شبکه را جستجو کنید:

از Etherscan برای فراخوانی getRewards() استفاده کنید:

• برای قرارداد پاداش به رابط Etherscan بروید

• برای فراخوانی getRewards() :
  • فهرست کشویی 10. getRewards را گسترش دهید.
  • شناسه allocation را در ورودی وارد کنید.
  • روی دکمه Query کلیک کنید.

  اختلافات چیست و کجا می توانم آنها را ببینم؟# پیوند به این بخش

  نمایش داده ها و تخصیص Indexer هر دو را می توان در طول دوره اختلاف در نمودار مورد اختلاف قرار داد. بسته به نوع اختلاف ، دوره اختلاف متفاوت است. نمایش داده شد/تأییدیه ها دارای 7 پنجره اختلاف نظر هستند ، در حالی که تخصیص دارای 56 دوره است. پس از گذشت این دوره ها ، اختلافات علیه هر یک از تخصیص یا نمایش داده ها قابل باز نیست. هنگامی که یک مشاجره باز می شود ، صید حداقل 10،000 GRT توسط ماهیگیران مورد نیاز است که تا زمان نهایی شدن اختلاف قفل می شوند و وضوح داده می شود. ماهیگیر هر شرکت کننده شبکه ای است که اختلافات را باز می کند.

  اختلافات دارای سه نتیجه ممکن است ، بنابراین سپرده ماهیگیران نیز انجام می شود.

  • در صورت رد اختلاف ، GRT که توسط ماهیگیران سپرده می شود سوخته می شود و شاخص مشاجره شده بریده نمی شود.
  • اگر این اختلاف به عنوان قرعه کشی حل شود ، سپرده ماهیگیران بازگردانده می شوند و شاخص های مورد اختلاف کاهش نمی یابد.
  • در صورت پذیرش اختلاف ، GRT سپرده شده توسط ماهیگیران بازگردانده می شود ، شاخص مشاجره شده بریده می شود و ماهیگیران 50 ٪ از GRT خرد شده را بدست می آورند.

  اختلافات را می توان در UI در صفحه نمایه شاخص در زیر برگه اختلافات مشاهده کرد.

  تخفیف هزینه های پرس و جو چیست و چه زمانی توزیع می شود؟# پیوند به این بخش

  هزینه های پرس و جو توسط دروازه هر زمان که تخصیص بسته و در استخر تخفیف هزینه پرس و جو در زیرگراف جمع می شود ، جمع آوری می شود. استخر تخفیف به منظور ترغیب شاخص ها برای اختصاص سهم به نسبت تقریبی با میزان هزینه های پرس و جو که برای شبکه کسب می کند ، طراحی شده است. بخشی از هزینه های پرس و جو در استخر که به یک شاخص خاص اختصاص یافته است با استفاده از عملکرد تولید Cobb-Douglas محاسبه می شود. مبلغ توزیع شده برای هر شاخصی تابعی از مشارکت آنها در استخر و تخصیص سهام آنها در زیرگراف است.

  پس از بسته شدن تخصیص و دوره اختلاف ، تخفیف ها در دسترس هستند که توسط فهرست نویس ادعا می شوند. پس از ادعای ، تخفیف هزینه های پرس و جو بر اساس کاهش هزینه پرس و جو و نسبت استخر نمایندگی به فهرست نویس و نمایندگان آنها توزیع می شود.

  کاهش هزینه پرس و جو و کاهش پاداش فهرست بندی چیست؟# پیوند به این بخش

  مقادیر Queryfecead و IndexingRewardCut پارامترهای هیئت هستند که ممکن است ایندکسر به همراه Cooldownblocks برای کنترل توزیع GRT بین شاخص و نمایندگان آنها تنظیم شود. برای راهنمایی در مورد تنظیم پارامترهای هیئت ، آخرین مراحل در مورد استیک را در پروتکل مشاهده کنید.

  Queryfecet - ٪ تخفیف هزینه های پرس و جو در یک زیرگراف که به فهرست نویس توزیع می شود. اگر این امر به 95 ٪ تعیین شود ، ایندکسر هنگامی که یک تخصیص با 5 ٪ دیگر به نمایندگان می رود ، 95 ٪ از استخر تخفیف هزینه پرس و جو را دریافت می کند.

  IndexingRewardCut - ٪ از پاداش های نمایه سازی انباشته شده بر روی یک زیرگراف که به شاخص توزیع می شود. اگر این امر به 95 ٪ تنظیم شود ، در صورت بسته شدن تخصیص ، شاخص کننده 95 ٪ از استخر پاداش های نمایه سازی را دریافت می کند و نمایندگان 5 ٪ دیگر را تقسیم می کنند.

  چگونه شاخص ها می دانند کدام زیرگرافها را به فهرست می دهند؟# پیوند به این بخش

  شاخص ها ممکن است با استفاده از تکنیک های پیشرفته برای تصمیم گیری در مورد نمایه سازی زیرگراف ، خود را متمایز کنند اما برای ارائه ایده کلی ، ما در مورد چندین معیار کلیدی مورد استفاده برای ارزیابی زیرگراف های موجود در شبکه بحث خواهیم کرد:

  سیگنال CURATION - نسبت سیگنال درمان شبکه که به یک زیرگراف خاص اعمال می شود ، نشانگر خوبی از علاقه به آن زیرگراف است ، به خصوص در مرحله بوت استرپ هنگام افزایش حجم پرس و جو در حال افزایش است.

  هزینه های پرس و جو جمع آوری شده - داده های تاریخی برای حجم هزینه های پرس و جو جمع آوری شده برای یک زیرگراف خاص ، شاخص خوبی برای تقاضای آینده است.

  مقدار استیک - نظارت بر رفتار سایر شاخص ها یا نگاه کردن به نسبت های کل سهام اختصاص یافته به زیرگرافهای خاص می تواند به یک ایندکسر اجازه دهد تا طرف عرضه را برای پرس و جوهای زیرگراف کنترل کند تا زیرگارهایی را که شبکه اعتماد به نفس یا زیرگراف هایی را نشان می دهد که ممکن است نیاز به آنها نشان دهد ، شناسایی کند. عرضه بیشتر

  زیرگراف هایی که دارای پاداش نمایه سازی نیستند - برخی از زیرگراف ها به دلیل استفاده از ویژگی های پشتیبانی نشده مانند IPF یا به دلیل اینکه شبکه دیگری را در خارج از Maiet جستجو می کنند ، پاداش های نمایه سازی را تولید نمی کنند. در صورت عدم تولید جوایز نمایه سازی ، پیامی را در زیرگراف مشاهده خواهید کرد.

  الزامات سخت افزاری چیست؟# پیوند به این بخش

  • کوچک - به اندازه کافی برای شروع نمایه سازی چندین زیرگراف ، احتمالاً نیاز به گسترش دارد.
  • استاندارد - تنظیم پیش فرض ، این همان چیزی است که در مثال مانیفست استقرار K8S/Terraform استفاده می شود.
  • میانگین - شاخص تولیدی که از 100 زیرگراف و 200-500 درخواست در ثانیه پشتیبانی می کند.
  • بزرگ - آماده برای فهرست بندی کلیه زیرگرافهای مورد استفاده در حال حاضر و ارائه درخواست های مربوط به ترافیک مربوط.

  برپایی	Postgres (CPU)	Postgres (حافظه در GBS)	Postgres (دیسک در TBS)	VMS (CPU)	VMS (حافظه در GBS)
  کم اهمیت	4	8	1	4	16
  استاندارد	8	30	1	12	48
  متوسط	16	64	2	32	64
  بزرگ	72	468	3.5	48	184

  برخی از اقدامات احتیاطی اساسی امنیتی که باید یک ایندکسر انجام دهد چیست؟# پیوند به این بخش

  کیف پول اپراتور-تنظیم یک کیف پول اپراتور یک احتیاط مهم است زیرا به یک ایندکسر اجازه می دهد تا جدایی بین کلیدهای خود را کنترل کند که سهام خود را کنترل می کند و مواردی که کنترل عملیات روزانه را کنترل می کنند. برای دستورالعمل به سهام پروتکل مراجعه کنید.

  فایروال - فقط سرویس Indexer باید در معرض عموم قرار گیرد و باید توجه ویژه ای به قفل کردن درگاه های سرپرست و دسترسی به پایگاه داده باشد: گره نمودار JSO N-RPC نقطه پایانی (درگاه پیش فرض: 8030) ، نقطه پایانی مدیریت شاخص (پورت پیش فرض: 18000) ، و نقطه پایانی پایگاه داده Postgres (درگاه پیش فرض: 5432) نباید در معرض دید قرار گیرد.

  زیرساخت # پیوند به این بخش

  در مرکز زیرساخت های شاخص ، گره نمودار است که بر روی Ethereum مانیتور می شود ، داده ها را در هر تعریف زیرگراف بارها و بارها می کند و آن را به عنوان یک API GraphQL خدمت می کند. گره نمودار باید به نقاط پایانی گره Ethereum EVM و گره IPFS برای تهیه داده ها متصل شود. یک پایگاه داده PostgreSQL برای فروشگاه خود ؛و مؤلفه های ایندکسر که تعامل آن با شبکه را تسهیل می کند.

  پایگاه داده PostgreSQL - فروشگاه اصلی گره نمودار ، اینجاست که داده های زیرگراف ذخیره می شود. خدمات و نماینده Indexer همچنین از پایگاه داده برای ذخیره داده های کانال دولتی ، مدل های هزینه ، قوانین نمایه سازی و اقدامات تخصیص استفاده می کنند.

  Ethereum Endpoint - نقطه پایانی که یک API Ethereum JSO N-RPC را در معرض دید قرار می دهد. این ممکن است به شکل یک مشتری Ethereum واحد باشد یا می تواند یک مجموعه پیچیده تر باشد که در چندین مورد تعادل بارگذاری شده است. این مهم است که آگاه باشید که زیرگرافهای خاص به قابلیت های خاص مشتری Ethereum مانند حالت بایگانی و API ردیابی نیاز دارند.

  گره IPFS (نسخه کمتر از 5) - ابرداده استقرار زیرگراف در شبکه IPFS ذخیره می شود. گره نمودار در درجه اول به گره IPFS در طول استقرار زیرگراف برای واکشی مانیفست زیرگراف و تمام پرونده های مرتبط دسترسی پیدا می کند. شاخص های شبکه نیازی به میزبانی گره IPFS خود ندارند ، یک گره IPFS برای شبکه در https://ipfs.network. thegraph.com میزبانی می شود.

  Service Indexer - کلیه ارتباطات خارجی مورد نیاز را با شبکه کنترل می کند. سهام مدل ها و وضعیت های نمایه سازی ، درخواست های پرس و جو را از دروازه ها به یک گره نمودار منتقل می کند و پرداخت های پرس و جو را از طریق کانال های دولتی با دروازه مدیریت می کند.

  Agent Indexer - تعامل Indexers را در زنجیره ای از جمله ثبت نام در شبکه ، مدیریت استقرار زیرگراف به گره گرافیک/S و مدیریت تخصیص تسهیل می کند.

  سرور Prometheus Metrics - گره نمودار و اجزای شاخص معیارهای خود را به سرور Metrics وارد می کنند.

  توجه: برای پشتیبانی از مقیاس بندی چابک ، توصیه می شود که نگرانی های پرس و جو و نمایه سازی بین مجموعه های مختلف گره ها از هم جدا شوند: گره های پرس و جو و گره های فهرست.

  بررسی اجمالی پورت ها # پیوند به این بخش

  نکته مهم: در مورد افشای بنادر به طور عمومی مراقب باشید - بنادر دولت باید قفل شوند. این شامل گره نمودار JSON-RPC و نقاط پایانی مدیریت شاخص در زیر است.

  گره نمودار # پیوند به این بخش

  بندر	هدف	مسیر	بحث	متغیر محیطی
  8000	سرور GraphQL HTTP (برای نمایش داده های زیرگراف)	/زیرگرافها/شناسه/./زیرگرافها/نام/./	-HTTP-Port	-
  8001	Graphql WS (برای اشتراک های زیرگراف)	/زیرگرافها/شناسه/./زیرگرافها/نام/./	-پورت-پورت	-
  8020	JSON-RPC (برای مدیریت استقرار)	/	-پورت Admin	-
  8030	API وضعیت نمایه سازی زیرگراف	/graphql	-پورت node-Index	-
  8040	معیارهای پرومتئوس	/معیارهای	-پورت-پورت	-

  خدمات indexer # پیوند به این بخش

  بندر	هدف	مسیر	بحث	متغیر محیطی
  7600	سرور GraphQL HTTP (برای نمایش داده های زیرگراف پرداخت شده)	/زیرگرافها/شناسه/./وضعیت /کانال-پیام در صندوق	--بندر	indexer_service_port
  7300	معیارهای پرومتئوس	/معیارهای	-پورت-پورت	-

  نماینده indexer # پیوند به این بخش

  بندر	هدف	مسیر	بحث	متغیر محیطی
  8000	API مدیریت شاخص	/	-پورت مدیریت-نماینده	indexer_agent_indexer_management_port

  زیرساخت های سرور تنظیم با استفاده از Terraform در Google Cloud # پیوند به این بخش

  توجه: شاخص ها می توانند از AWS ، Microsoft Azure یا Alibaba استفاده کنند.

  پیش نیازهای # پیوند را به این بخش نصب کنید

  • Google Cloud SDK
  • ابزار خط فرمان Kubectl
  • شکل

  یک پروژه Google Cloud # پیوند به این بخش ایجاد کنید

  کلون یا حرکت به مخزن Indexer.

  به فهرست ./terraform بروید ، اینجاست که همه دستورات باید اجرا شوند.

  • با Google Cloud تأیید کنید و یک پروژه جدید ایجاد کنید.

  از صفحه صدور صورتحساب کنسول Google Cloud استفاده کنید تا صورتحساب برای پروژه جدید را فعال کنید.

  یک پیکربندی Google Cloud ایجاد کنید.

  • API های Google Cloud را فعال کنید.
  • ایجاد یک حساب خدمات.
  • بین پایگاه داده و خوشه Kubeetes که در مرحله بعدی ایجاد می شود ، فعال کنید.
  • حداقل پرونده پیکربندی Terraform را ایجاد کنید (در صورت لزوم به روز کنید).

  برای ایجاد زیرساخت # پیوند به این بخش از terraform استفاده کنید

  قبل از اجرای هرگونه دستورات ، از طریق متغیرها. tf بخوانید و یک پرونده terraform. tfvars را در این فهرست ایجاد کنید (یا آنچه را که در مرحله آخر ایجاد کرده ایم تغییر دهید). برای هر متغیر که می خواهید پیش فرض را نادیده بگیرید ، یا جایی که باید یک مقدار را تنظیم کنید ، یک تنظیم را در terraform. tfvars وارد کنید.

  • دستورات زیر را برای ایجاد زیرساخت ها اجرا کنید.

  اعتبارنامه را برای خوشه جدید بارگیری کنید~/. kube/config و آن را به عنوان زمینه پیش فرض خود تنظیم کنید.

  ایجاد اجزای Kubeetes برای پیوند # Indexer # به این بخش

  دایرکتوری K8S/Overlays را در یک فهرست جدید $ DIR کپی کنید و ورود پایه ها را در $ dir/kustomization. yaml تنظیم کنید تا به دایرکتوری K8S/Base اشاره کند.

  تمام پرونده ها را در $ dir بخوانید و هر مقداری را مطابق با نظرات تنظیم کنید.

  همه منابع را با Kubectl اعمال کنی د-k $ dir.

  گره نمودار # پیوند به این بخش

  Node Graph یک اجرای زنگ منبع باز است که این رویداد را برای به روزرسانی یک فروشگاه داده که می تواند از طریق نقطه پایانی GraphQL پرسیده شود ، به طور قطعی به روز می کند. توسعه دهندگان از زیرگراف هایی برای تعریف طرحواره خود استفاده می کنند ، و مجموعه ای از نقشه ها برای تبدیل داده های تهیه شده از زنجیره بلوک و دستگیره های گره نمودار همگام سازی کل زنجیره ، نظارت بر بلوک های جدید و ارائه آن از طریق نقطه پایانی GraphQL.

  شروع از منبع # پیوند به این بخش

  پیش نیازهای # پیوند را به این بخش نصب کنید

  زنگ

  پس از

  IPF

  الزامات اضافی برای کاربران اوبونتو - برای اجرای یک گره نمودار در اوبونتو ممکن است چند بسته اضافی مورد نیاز باشد.

  تنظیم # پیوند به این بخش

  1. یک سرور پایگاه داده PostgreSQL را شروع کنید

  Node Graph Clone Graph REPO و ساخت منبع را با اجرای Cargo Build

  اکنون که همه وابستگی ها تنظیم شده اند ، گره نمودار را شروع کنید:

  شروع به استفاده از Docker # Link به این بخش

  پیش نیازها # پیوند به این بخش

  • Node Ethereum - به طور پیش فرض ، تنظیمات آهنگسازی Docker از maiet استفاده می کند: http: //host. docker. inteal: 8545 برای اتصال به گره اتریوم در دستگاه میزبان شما. با به روزرسانی Docker-Compose. yAML می توانید این نام و URL را جایگزین کنید.

  تنظیم # پیوند به این بخش

  1. گره نمودار کلون و حرکت به فهرست داکر:
  1. فقط برای کاربران لینوکس - از آدرس IP میزبان به جای host. docker. inteal در docke r-compose. yaml با استفاده از اسکریپت موجود استفاده کنید:
  1. یک گره نمودار محلی را شروع کنید که به نقطه پایانی اتریوم شما وصل شود:

  مؤلفه های indexer # پیوند به این بخش

  برای شرکت موفقیت آمیز در شبکه نیاز به نظارت و تعامل تقریباً مداوم دارد ، بنابراین ما برای تسهیل مشارکت شبکه ایندکسرها مجموعه ای از برنامه های TypeScript را ایجاد کرده ایم. سه مؤلفه شاخص وجود دارد:

  نماینده شاخص - نماینده نظارت بر شبکه و زیرساخت های خود شاخص را کنترل می کند و مدیریت می کند که استقرار زیرگراف به آنها فهرست بندی می شود و به سمت زنجیره ای اختصاص می یابد و چقدر به هر یک اختصاص می یابد.

  Service Indexer - تنها مؤلفه ای که باید در خارج از کشور در معرض دید قرار گیرد ، این سرویس در نمایش داده های زیرگراف به گره نمودار منتقل می شود ، کانال های دولتی را برای پرداخت پرس و جو مدیریت می کند ، اطلاعات مهم تصمیم گیری را به مشتری هایی مانند دروازه ها می بخشد.

  Indexer CLI - رابط خط فرمان برای مدیریت نماینده شاخص. این اجازه می دهد تا شاخص ها مدل های هزینه ، تخصیص دستی ، صف اقدامات و قوانین نمایه سازی را مدیریت کنند.

  شروع # پیوند به این بخش

  نماینده شاخص و خدمات ایندکسر باید با زیرساخت گره نمودار شما هماهنگ شود. روش های زیادی برای تنظیم محیط های اجرای مجازی برای مؤلفه های فهرست بندی شما وجود دارد. در اینجا ما نحوه اجرای آنها را با استفاده از بسته های NPM یا منبع ، یا از طریق Kubeetes و Docker در موتور Google Cloud Kubeetes توضیح خواهیم داد. اگر این نمونه های تنظیم به خوبی به زیرساخت های شما ترجمه نشوند ، احتمالاً یک راهنمای جامعه برای مرجع وجود خواهد داشت ، بیایید در مورد اختلاف نظر سلام کنید! به یاد داشته باشید که قبل از شروع اجزای Indexer خود در پروتکل شرکت کنید!