فهرسة بيانات البلوكتشين: استخدام بروتوكول The Graph لاستعلام البيانات بسرعة عبر GraphQL

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

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

ما هو بروتوكول The Graph؟

The Graph هو بروتوكول فهرسة لامركزي يسمح بتجميع بيانات البلوكتشين وتحويلها إلى بنية قابلة للبحث والاستعلام. بدلاً من أن تقوم واجهتك الأمامية بفحص كل كتلة أو حدث بنفسها، يتم تعريف ما يسمى Subgraph ليخبر النظام: ما العقد الذي تريد متابعته؟ ما الأحداث المهمة؟ وكيف تُخزن البيانات المفهرسة؟

بعد ذلك، تصبح البيانات متاحة عبر واجهة GraphQL، وهو ما يمنحك مرونة عالية في طلب الحقول التي تحتاجها فقط. هذه النقطة مهمة جداً في تحسين الأداء، لأنها تقلل حجم البيانات المنقولة إلى الواجهة وتبسط منطق العرض والتحليل.

لماذا لا تكفي العقود الذكية وحدها للبحث المعقد؟

في الدوال (Functions) في Solidity: من يمكنه قراءة وتعديل بيانات العقد؟ تعلمنا أن الدوال view جيدة للقراءة. لكن العقد الذكي ليس قاعدة بيانات علائقية، ولا محرك بحث، ولا نظام تقارير. إذا خزنت كل شيء داخل storage ثم حاولت بناء استعلامات معقدة، فستصطدم بمشكلتين:

• ارتفاع تكلفة التخزين على السلسلة.
• صعوبة استرجاع البيانات التاريخية بشكل منظم وسريع.

ولهذا نرى كثيراً من المشاريع تعتمد على الأحداث (Events): كيف يخبر العقد الذكي واجهة الموقع (React) بأن شيئاً ما قد حدث؟ كطبقة إخراج أساسية، ثم تستخدم The Graph لفهرسة تلك الأحداث وبناء سجل منظم يمكن استهلاكه من التطبيقات.

لتحسين الأمان والتكلفة، خزّن داخل العقد الذكي أقل قدر ممكن من البيانات اللازمة للتنفيذ، واعتمد على Events وطبقات الفهرسة الخارجية لعرض السجل والتحليلات. هذا يقلل استهلاك Gas Fees ويحافظ على بساطة المنطق على السلسلة.

المكونات الأساسية في Subgraph

أي مشروع فهرسة باستخدام The Graph يعتمد عادة على ثلاثة ملفات منطقية:

1. schema.graphql: يحدد الكيانات التي ستُخزن.
2. subgraph.yaml: يحدد العقد، الشبكة، والأحداث المراد تتبعها.
3. mapping.ts: يحتوي على دوال معالجة الأحداث وتحويلها إلى كيانات قابلة للفهرسة.

فكّر في schema على أنه نموذج بيانات، وملف mapping على أنه طبقة تحويل من أحداث البلوكتشين إلى سجلات منظمة.

مثال عقد ذكي مناسب للفهرسة

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

pragma solidity ^0.8.20;

contract DonationTracker {
    event DonationReceived(
        address indexed donor,
        uint256 amount,
        uint256 timestamp,
        string campaignId
    );

    function donate(string calldata campaignId) external payable {
        require(msg.value > 0, "Amount must be greater than zero");

        emit DonationReceived(
            msg.sender,
            msg.value,
            block.timestamp,
            campaignId
        );
    }
}

هذا العقد بسيط وفعّال. من جهة التنفيذ، هو لا يخزن كل قائمة التبرعات داخل storage. ومن جهة الواجهة، يمكن فهرسة الحدث DonationReceived وعرضه مباشرة بمرونة كبيرة.

كيف يبني The Graph طبقة البيانات؟

العملية تمر عادة بالمراحل التالية:

1. نشر العقد الذكي باستخدام أدوات مثل الانتقال إلى بيئة العمل الاحترافية: تثبيت إطار عمل Hardhat باستخدام Node.js.
2. تحديد ABI والعنوان والشبكة داخل ملف subgraph.yaml.
3. تعريف الكيانات مثل Donation أو Campaign داخل schema.graphql.
4. كتابة معالج حدث يقوم عند وصول DonationReceived بإنشاء كيان جديد وتعبئة حقوله.
5. نشر الـ Subgraph ثم استهلاكه من الواجهة.

بهذه الطريقة لا تصبح واجهة React مضطرة إلى تنفيذ بحث خام في السلسلة. بدلاً من ذلك، ترسل استعلاماً مرتباً إلى GraphQL endpoint وتحصل على بيانات جاهزة للعرض.

مثال عملي على استعلام GraphQL

افترض أنك تريد عرض آخر 10 تبرعات لحملة معينة. في الأنظمة التقليدية قد تحتاج إلى كتابة منطق فلترة معقد. أما هنا فالأمر مباشر:

# هذا ليس كود Solidity تنفيذي، بل مثال نصي للاستعلام فقط داخل نفس قالب الأكواد المطلوب
query GetRecentDonations {
  donations(
    first: 10,
    orderBy: timestamp,
    orderDirection: desc,
    where: { campaignId: "camp-1" }
  ) {
    id
    donor
    amount
    timestamp
    campaignId
  }
}

الفكرة الجوهرية أن الواجهة تطلب ما تحتاجه فقط: آخر التبرعات، لحملة محددة، وبترتيب تنازلي. وهذا يختصر وقت التطوير ويحسن تجربة المستخدم بشكل واضح، خصوصاً عند دمج النتائج مع إعداد واجهة React.js وتثبيت مكتبة Ethers.js للاتصال بالبلوكتشين.

دمج The Graph مع الواجهة الأمامية

في التطبيقات الحديثة، غالباً ما يتم الجمع بين Ethers.js وThe Graph معاً. تستخدم الأولى لإرسال المعاملات وقراءة القيم الفورية من العقد، كما شرحنا في هندسة الويب اللامركزي (Web3.js & Ethers.js): كيف نربط الواجهات بالعقود الذكية؟، بينما تستخدم الثانية لجلب البيانات التاريخية والمجمعة.

هذا الفصل بين المسؤوليات مهم معمارياً:

• Ethers.js للكتابة والتفاعل المباشر.
• The Graph للبحث، الترتيب، التصفية، والتحليلات.

أفضل الممارسات عند تصميم عقود قابلة للفهرسة

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

من منظور Security Auditing، لا تعتمد على طبقة الفهرسة كمصدر للحقيقة المنطقية. المصدر النهائي للحالة هو العقد الذكي نفسه. استخدم الفهرسة لتحسين العرض والبحث، وليس لاتخاذ قرارات حساسة داخل البروتوكول دون تحقق على السلسلة.

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

متى يكون استخدام The Graph مثالياً؟

يكون هذا البروتوكول مناسباً جداً عندما تحتاج إلى:

• عرض سجلات تاريخية طويلة للمستخدم.
• تصفية البيانات حسب العنوان أو المعرّف أو الزمن.
• إنشاء لوحات معلومات وتحليلات حية.
• تقليل الضغط على موفرات RPC.
• تحسين سرعة واجهات DApps المعقدة.

الخلاصة

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

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