الملخص

نرحب بكم في سلسلة مركز أبحاث GCC بعنوان "مأساة الموارد المشتركة في قطاع العملات الرقمية".

تسلط هذه السلسلة الضوء على السلع العامة الأساسية في عالم البلوك تشين، وهي العناصر المحورية في منظومة العملات الرقمية التي بدأت تنحرف عن جذورها اللامركزية. تلك السلع تمثل الدعامة الأساسية لـ Web3 لكنها غالبًا ما تعاني من اختلالات في الحوافز، وتحديات في الحوكمة، ومخاطر التمركز. في هذا السياق، تتفاقم الفجوة بين أهداف اللامركزية في القطاع الرقمي وضرورة التكرار البنيوي لضمان الاستقرار العملي.

يركز هذا الإصدار على أحد أبرز تطبيقات Ethereum: Polymarket وأدوات فهرسة البيانات المتعلقة به. منذ مطلع العام، جذبت Polymarket الانتباه نتيجة قضايا مثيرة للجدل امتدت من التلاعب في الأوركل المرتبط بفرص ترامب الانتخابية إلى الرهانات على العناصر النادرة في أوكرانيا، وصولًا إلى مراهنات سياسية حول لون بدلة زيلينسكي. حجم الأموال والتأثير المرافق لهذه الحالات يجعله من غير الممكن تجاهلها.

لكن يبقى السؤال الجوهري: هل حقق هذا السوق اللامركزي الرائد فعلاً اللامركزية في الطبقة الأكثر أهمية، أي طبقة فهرسة البيانات؟ وما سبب تعثر البنية التحتية اللامركزية مثل The Graph في تلبية التوقعات؟ وما ملامح الحل الأمثل لفهرسة البيانات العامة بحيث يكون قابلًا للاستخدام ومستدامًا؟

I. أثر الدومينو لانقطاع منصة بيانات مركزية

في يوليو 2024، تعرضت Goldsky، وهي منصة للبنية التحتية في البلوك تشين تقدم خدمات الفهرسة والمخططات الفرعية وتدفق البيانات لمطوري Web3، لانقطاع لمدة ست ساعات. أدى ذلك إلى تعطل جزء كبير من منظومة Ethereum: إذ توقفت واجهات DeFi الأمامية عن عرض المراكز والأرصدة، ولم تستطع أسواق التنبؤ مثل Polymarket إظهار بيانات صحيحة، وظهر العديد من واجهات المشاريع للمستخدمين وكأنها خارج الخدمة تمامًا.

يمثل ذلك الحالة التي يفترض أن تقي منها التطبيقات اللامركزية؛ فهدف تصميم البلوك تشين الأساسي هو التخلص من نقاط الفشل الفردية. أبرزت حادثة Goldsky حقيقة مقلقة: رغم تصميم البلوك تشين لتحقيق اللامركزية، تبقى معظم البنية التحتية الداعمة للتطبيقات قائمة على مركزية عالية.

المشكلة الجوهرية أن فهرسة البيانات واسترجاع البيانات من البلوك تشين تمثل سلعًا عامة رقمية غير قابلة للإقصاء أو التنافس، ويتوقع المستخدمون غالبًا أن تكون متاحة مجانًا أو بتكلفة رمزية. إلا أن تأمين هذه البنية التحتية يتطلب استثمارًا دائمًا في المعدات، والتخزين، وسرعة الاتصال، والهندسة التقنية. وفي غياب نموذج إيرادات مستدام، تتجه السوق نحو الاحتكار؛ فحالما يحقق أحد مقدمي الخدمة تفوقًا في السرعة أو رأس المال، تنتقل حركة الاستعلامات بالكامل إليه، مما يخلق نقطة تبعية مركزية جديدة. وقد أشار Gitcoin وغيره من المؤسسات غير الربحية مرارًا إلى أن "البنية التحتية مفتوحة المصدر توفر مليارات من القيمة، في حين أن مبتكريها غالبًا ما يعجزون عن دفع أقساط منازلهم."

الدروس واضحة: يحتاج قطاع اللامركزية إلى تدخلات عاجلة في التمويل، وإعادة توزيع الحوافز، ونماذج مجتمعية لتعزيز تنوع بنية Web3 والحد من أشكال المركزية الجديدة. ندعو مطوري التطبيقات اللامركزية لاتباع منهجيات "المحلية أولاً"، وعلى المجتمعات التقنية تصميم تطبيقات قادرة على التعامل مع إخفاق استرجاع البيانات، لضمان استمرار تفاعل المستخدم حتى عند توقف المفهرسين.

II. مصدر بيانات تطبيقك اللامركزي الحقيقي

لفهم انقطاعات مثل حادثة Goldsky، من الضروري التعمق في آلية عمل التطبيقات اللامركزية. يرى معظم المستخدمين عنصرين فقط: العقد الذكي على السلسلة والواجهة الأمامية للتطبيق. اعتادوا مراجعة حالة المعاملات عبر Etherscan، ومطالعة المعلومات في الواجهة، وتنفيذ التفاعلات عبر الواجهة الرسومية. ولكن، من أين تستمد الواجهة الأمامية بياناتها فعليًا؟

الدور الحاسم لخدمات استرجاع البيانات

لنفترض أنك تطوّر بروتوكول إقراض يعرض مراكز المستخدمين، والهامش، والديون. إذا استعلمت الواجهة الأمامية البيانات مباشرة من البلوك تشين، ستواجه مشكلة أن عقود البروتوكولات لا تتيح الاستعلام عن جميع المراكز حسب عنوان المستخدم، بل فقط حسب معرف كل مركز. لذا، لعرض بيانات المستخدم، يجب أولًا سحب جميع المراكز المفتوحة ثم تصفيتها يدويًا بحثًا عن مراكز المستخدم، أي البحث ضمن ملايين السجلات. الحل تقنيًا ممكن لكنه بالغ البطء وغير فعال؛ حتى على الخوادم الخلفية، قد يستغرق الأمر ساعات في مشاريع DeFi الكبيرة لاسترجاع هذه البيانات من العقدة المحلية.

وهنا تكون الحاجة للبنية التحتية المتخصصة لتسريع هذه العمليات. يقدم مزودون مثل Goldsky خدمات فهرسة بيانات ترفع سرعة الوصول بشكل كبير. يوضح الرسم أدناه أنواع البيانات التي تتيحها مثل هذه الخدمات للتطبيقات.

يطرح البعض سؤالًا: ألم يوفر The Graph آلية استرجاع بيانات لامركزية لإيثيريوم؟ كيف يقارن ب Goldsky؟ ولماذا تفضل معظم مشاريع DeFi استخدام Goldsky بدلًا من The Graph؟

العلاقة التقنية بين The Graph، Goldsky وSubGraph

للتوضيح، إليكم شرحًا للمفاهيم التقنية الأساسية:

• SubGraph هو إطار تطوير يتيح للفِرق كتابة شفرة تسحب وتجمع بيانات السلسلة من أجل العرض على الواجهة الأمامية.
• The Graph منصة رائدة لاسترجاع البيانات اللامركزية، طورت إطار SubGraph باستخدام AssemblyScript. يستخدم المطورون SubGraph لالتقاط أحداث العقود وكتابة البيانات في قاعدة تُستدعى عبر GraphQL أو SQL.
• مقدمو خدمة تشغيل SubGraph يُسمون مشغلي SubGraph. كل من The Graph وGoldsky يوفران استضافة لهذه المشاريع؛ فالشفرة تُشغّل في النهاية على خوادم. فيما يلي مقتطف من توثيق Goldsky:

لماذا يوجد أكثر من مشغّل لـ SubGraph؟

لأن الإطار يحدد كيفية استخراج البيانات وكتابتها فقط، ولا يحدد آلية تدفق البيانات أو إخراجها؛ لذا ينفذ كل مشغّل هذه الجوانب وفق رؤيته الخاصة.

قد يضيف المشغلون تعديلات خاصة على العقد وتحسينات في الأداء. يستخدم The Graph الآن Firehouse لفهرسة أسرع، فيما يبقى نظام تشغيل SubGraph في Goldsky مغلق المصدر.

The Graph يمثل محورًا لامركزيًا لمشغلي SubGraph. فمثلًا المخطط الفرعي Uniswap v3 مدعوم من عدة مشغلين، ما يجعل The Graph سوقًا جماعية يُشارك فيها المستخدمون شفرة SubGraph ويمكن لأكثر من مشغّل التعامل مع الاستعلامات.

نموذج تسعير Goldsky

Goldsky، كخدمة مركزية على نمط SaaS، تطبق نموذج دفع مقابل الموارد حسب الاستخدام. فيما يلي أداة حساب الأسعار الخاصة ب Goldsky:

نموذج التسعير لدى The Graph

يعتمد The Graph على نموذج فريد مدمج في نظام رموز GRT: رسوم الاستعلام والحوافز موزعة آليًا. فيما يلي ملخص:

• كل استعلام ضمن SubGraph تقسم منه الرسوم: 1% من GRT يُحرق، 10% يمنح للمشرفين (غالبًا المطورين)، ونحو 89% للمفهرسين والمفوضين حسب النظام.
• يتوجب على المفهرسين رهن ما لا يقل عن 100,000 GRT للمشاركة، وتفرض عليهم عقوبات عند تقديم نتائج خاطئة. يقوم المفوضون برهن GRT لديهم لمشاركة مكافآت المفهرسين.
• المشرفون (غالبًا المطورون) يراهنون GRT على منحنى رهن خاص بمخططاتهم الفرعية، لجذب موارد المفهرسين. من الشائع ضمن التوصيات المجتمعية رهن ما بين 5,000 و10,000 GRT لضمان الفهرسة الفعّالة.

رسوم الاستعلام:

للاستعلام عبر The Graph، يسجل المطور مفتاح API ويدفع مسبقًا GRT، وتحتسب التكلفة لكل طلب.

رسوم رهن الإشارة:

لكي تُفهرس المخططات الفرعية، يجب على المطورين رهن GRT للإشارة لقيمة المشروع وجذب المشغلين. ويبدأ المفهرسون بفهرسة المخطط بعد بلوغ حد كاف من الرهن (مثال: 10,000 GRT).

خلال مرحلة الاختبار، يمكن نشر المخططات الفرعية مجانًا على مشغل الاختبار لدى The Graph، لكن ذلك لا يصلح للإنتاج الفعلي. أما الإنتاج، فيتطلب نشر المخططات على الشبكة ليختار المفهرسون ما يفهرسونه حسب إشارات الرهن.

لماذا يعارض المطورون والمحاسبون التسعير القائم على الرموز الرقمية

آلية العمل في The Graph معقدة لكثير من المشاريع. حيث أن شراء GRT بسيط لفِرق Web3، لكن عملية الإشراف تستغرق وقتًا طويلًا وغير مؤكدة. أبرز المشاكل:

• عدم وضوح المتطلبات: يواجه المطورون صعوبة تحديد مقدار GRT المطلوب أو الوقت الذي يحتاجه المفهرسون لفهرسة المخططات.
• تعقيدات محاسبية: التسعير بآلية الرموز الرقمية يربك تتبع النفقات، ما يصعب على الشركات والمحاسبين تصنيف المصاريف.

"هل المركزية فعلاً أكثر سهولة؟"

بالنسبة لغالبية المطورين، يعتبر Goldsky الخيار الأكثر سهولة: نموذج تسعير واضح، خدمة فورية بعد الدفع، ودرجة منخفضة من عدم اليقين. أدى ذلك إلى اعتماد شديد على مزود فهرسة واحد في Web3.

ورغم أن نموذج GRT في The Graph ينطوي على نوايا حسنة، إلا أن تعقيده منفّر ويجب ألا يُحمّل المستخدم النهائي عبء الإشراف على الرهن؛ بل ينبغي إخفاء هذه التفاصيل خلف واجهة دفع مبسطة.

هذا الرأي مدعوم كذلك بانتقادات علنية: فقد انتقد Paul Razvan Berg، مهندس العقود الذكية البارز ومؤسس Sablier، تجربة نشر المخططات الفرعية والدفع بـGRT بشدة، واصفًا إياها بالرديئة للغاية.

III. حلول قائمة لانقطاع مفهرسي البيانات

كيف يجب أن تتعامل المنظومة التقنية مع نقاط الفشل الفردية في فهرسة البيانات؟ كما ذكرنا، يستطيع المطورون اللجوء إلى The Graph، مع ضرورة التعامل مع رهن وإشراف GRT لدفع رسوم واجهات API.

منظومة EVM غنية بالبدائل في مجال فهرسة البيانات. يمكن الرجوع إلى تقارير Dune The State of EVM Indexing، ودليل rindexer حول أدوات الفهرسة، وهذه السلسلة الحديثة.

لا تستعرض هذه المقالة السبب الفني لانقطاع Goldsky؛ وحسب تقرير الحادثة الخاص بهم، يشارك Goldsky التفاصيل فقط مع عملاء المؤسسات. ويشير التقرير إلى حدوث مشكلة عند كتابة البيانات المفهرسة إلى قاعدة البيانات، وقد تم استعادة الوصول نتيجة التعاون مع AWS.

إليكم حلولًا بديلة فعّالة:

• ponder أداة خفيفة وسهلة الاستخدام وذات مرونة في النشر الذاتي، تتيح للمطورين إدارة بياناتهم على البنية الخاصة بهم.
• local-first فلسفة تطوير تدعو لبقاء التطبيقات اللامركزية قابلة للاستخدام حتى دون الاتصال بالشبكة. في سياق البلوك تشين، يعني ذلك توفير تجربة جيدة للمستخدم ما دام متصلًا بالسلسلة، حتى مهما تعطلت المفهرسين.

Ponder: فهرسة البيانات ذاتيًا

ما مميزات ponder؟

• بدون ارتباط بمزود خدمة: تم تطويره بدايةً من مطور مستقل، ويحتاج فقط إلى نقطة اتصال Ethereum RPC وقاعدة بيانات Postgres، بلا خدمات مُدارة.
• تجربة تطوير سلسة: مكتوب بلغة TypeScript، ويستخدم مكتبة Viem، وهو سهل الاستخدام (المؤلف لديه تجربة مباشرة معه).
• أداء قوي وفعال.

لكن توجد بعض التحديات: فمع تطور ponder السريع قد تظهر تغييرات جذرية تؤثر على الإصدارات السابقة. للحصول على مزيد من التفاصيل التقنية وأفضل الممارسات، راجع الدليل الرسمي.

جدير بالذكر أن ponder بدأ مؤخرًا في طرح حلول تجارية، متوافقًا مع "نظرية الفصل" المشار إليها في مقال سابق.

باختصار: السلع العامة تخدم الجميع، لكن فرض رسوم يحد من الفائدة المجتمعية عبر إقصاء المستخدمين الهامشيين (أي غير فعّال من منظور باريتو). التسعير التفاضلي قد يرفع الفائض الكلي نظريًا، لكنه صعب التنفيذ. تدعو نظرية الفصل لعزل مجموعة متجانسة وفرض الرسوم عليها فقط، دون تأثير على الباقين.

كيف طبقت ponder ذلك؟

• النشر يتطلب خبرة تقنية؛ إذ يتعين على المطورين تثبيت متطلبات مثل Endpoint RPC وقاعدة البيانات.
• الصيانة المستمرة مطلوبة (مثل استخدام البروكسيات للموازنة وضمان استرجاع البيانات الفوري)، وهي مهمة قد تواجه بعض المطورين.
• حديثًا، وفرت ponder خدمة نشر آلية تجريبية عبر Marble، حيث يقدم المستخدم الشفرة للنشر بنقرة واحدة.

هذا النهج "يعزل" من يفضلون الحلول السهلة؛ يدفعون مقابل الخدمة المستضافة لدى Marble، فيما يبقى النشر الذاتي مجانيًا لمن يرغب.

Ponder مقابل Goldsky في التبني:

• أدوات النشر الذاتي مثل ponder تحظى بشعبية لدى المشاريع الصغيرة الباحثة عن المرونة والاستقلالية.
• أما المشاريع الكبرى ذات المطالب المرتفعة فتفضل خدمات مثل Goldsky لتوافرها العالي وتكرارها.

كل نموذج يحمل مخاطر. أبرزت حادثة Goldsky أهمية الاحتفاظ بأداة مفهرسة احتياطية لكل مطور، مثل ponder. عند استخدام ponder، يجب الانتباه لصحة بيانات RPC؛ فقد رُصدت مؤخرًا حادثة تسببت فيها بيانات RPC غير صحيحة بانهيار المفهرس. لا يوجد دليل قاطع أن Goldsky تأثر بذلك، لكنه احتمال وارد.

منهجية التطوير المحلية أولاً

شهدت منهجية "المحلية أولاً" مناقشات واسعة مؤخرًا، وتتمثل في:

• دعم إمكانية العمل دون اتصال
• تيسير التعاون عبر العملاء

غالبًا ما ترتبط المناقشات التقنية حول "المحلية أولاً" بهياكل البيانات المتكررة الخالية من التضارب - CRDT - التي تتيح حلًا تلقائيًا للصراعات في التحرير الموزع، أي بروتوكولات إجماع خفيفة تحافظ على اتساق البيانات عبر الأجهزة.

في تطوير البلوك تشين، يمكن تبسيط هذه المطالب؛ فالهدف هو لتوفير أدنى مستوى من الأداء للمستخدمين حتى عند غياب المفهرسين الخلفيين، بما أن البلوك تشين يوفر الاتساق عبر العملاء بالفطرة.

عمليًا، يمكن لتطبيقات "المحلية أولاً" أن:

• تخزن المعلومات الرئيسية محليًا مثل الأرصدة والمراكز، ليتمكن المستخدم من معاينة آخر حالة عند انقطاع المفهرسات.
• تتعامل بمرونة، عبر جلب البيانات الأساسية مباشرة من RPC عند تعطل المفهرس ليتمكن المستخدم من الاطلاع على جزء من البيانات الفورية على السلسلة.

يسهم هذا المنهج في تعزيز مرونة التطبيقات بشكل كبير. وفي الحالة المثالية، يتوجب على المستخدم تشغيل عقدة محلية واسترجاع البيانات عبر أدوات مثل TrueBlocks. للاطلاع أكثر على الفهرسة المحلية واللامركزية، انظر سلسلة النقاش لا أحد يهتم فعليًا بواجهات ومفهرسي البيانات اللامركزية.

IV. الخلاصة

شكل انقطاع Goldsky لمدة ست ساعات جرس إنذار لمنظومة Web3 بأكملها. فرغم أن البلوك تشين مصمم ليكون لامركزيًا ومرنًا، لا تزال غالبية المشاريع على مستوى التطبيقات تعتمد على بنية بيانات مركزية، ما يفتح الباب أمام مخاطر منهجية جديدة.

توضح المقالة أسباب تعثّر انتشار The Graph رغم سمعته التقنية القوية، بسبب تعقيدات GRT ورهانات المطورين. كما استعرضنا استراتيجيات تعزيز مرونة فهرسة البيانات، مع الدعوة لاستخدام أطر النشر الذاتي مثل ponder كحل احتياطي، بالإضافة إلى تسليط الضوء على نموذج ponder التجاري. وتناولنا كذلك منهجية المحلية أولاً، مؤكدين ضرورة ضمان قابلية الاستخدام حتى عند تعطل المفهرسين.

يتزايد إدراك مطوري Web3 لمخاطر النقاط الفردية للفشل في فهرسة البيانات باعتبارها ثغرة استراتيجية. ويدعو مركز GCC المجتمع للتركيز على هذا التحدي الأساسي في البنية التحتية، والتجريب باستخدام أدوات فهرسة بيانات لامركزية أو تطوير أطر تضمن استمرار تشغيل واجهات التطبيقات حتى عند توقف المفهرسين.

تنويه:

1. تمت إعادة نشر المقال من TechFlow. حقوق النشر محفوظة للمؤلف الأصلي shew. للملاحظات حول إعادة النشر، يرجى التواصل مع فريق Gate Learn.
2. تنويه: جميع الآراء الواردة في هذه المقالة تعبر عن وجهة نظر الكاتب فقط ولا تعتبر نصيحة استثمارية.
3. لا يجوز نسخ أو توزيع أو اقتباس الترجمات التي أعدها فريق Gate Learn إلا مع ذكر المصدر Gate.com.