Skip to main content

ما هو RPC

ملاحظة: هذا المستند هو ترجمة آلية للنسخة الإنجليزية الأصلية.

ما هو RPC

RPC (Remote Procedure Call — استدعاء الإجراء عن بُعد) هو بروتوكول اتصال يتيح لتطبيق طلب خدمة من برنامج يعمل على حاسوب آخر دون الحاجة إلى فهم تفاصيل شبكة ذلك الحاسوب. في سياق سلسلة الكتل، RPC هو الطريقة التي تتواصل بها المحافظ والتطبيقات اللامركزية ومستكشفات الكتل وغيرها من البرمجيات مع عقد سلسلة الكتل — إرسال المعاملات، والاستعلام عن الأرصدة، وقراءة حالة العقود الذكية، واسترجاع بيانات الكتل.

باختصار: RPC هو الواجهة القياسية التي تتحدّث من خلالها التطبيقات إلى عقد سلسلة الكتل — إنه طبقة الاتصال التي تربط تطبيقات dApps والمحافظ والأدوات بشبكة سلسلة الكتل ذاتها.

كيف يعمل RPC في سلسلة الكتل

تكشف كل عقدة في سلسلة الكتل عن نقطة نهاية RPC (RPC endpoint) — عنوان URL يقبل طلبات منظَّمة ويعيد استجابات منظَّمة. وعندما يحتاج تطبيق إلى التفاعل مع سلسلة الكتل، يرسل طلب RPC إلى هذه النقطة.

نمط الطلب–الاستجابة

يتّبع التفاعل نمط عميل–خادم قياسيًا:

  1. الطلب. يرسل التطبيق (العميل) طلبًا إلى نقطة نهاية RPC للعقدة. ويحدّد الطلب أي طريقة (method) سيستدعيها ويوفّر أي معلمات لازمة. على سبيل المثال: «احصل على رصيد العنوان 0x742d...bD38» أو «أرسل هذه المعاملة الموقّعة إلى الشبكة».
  2. المعالجة. تستقبل العقدة الطلب، وتنفّذ العملية المطلوبة — القراءة من نسختها المحلية من سلسلة الكتل أو بثّ معاملة إلى الشبكة — وتجهّز استجابة.
  3. الاستجابة. تعيد العقدة النتيجة إلى التطبيق بصيغة منظَّمة (عادة JSON).

JSON-RPC

تستخدم معظم شبكات سلسلة الكتل JSON-RPC — بروتوكول خفيف تُنسَّق فيه الطلبات والاستجابات كائنات JSON. ويتضمّن طلب JSON-RPC النموذجي اسم طريقة (مثل eth_getBalance أو eth_sendRawTransaction أو eth_call) ومصفوفة من المعلمات. وتحتوي الاستجابة على النتيجة أو رسالة خطأ.

تعني هذه الصيغة المعيارية أن أي تطبيق يفهم JSON-RPC يمكنه التفاعل مع أي عقدة تنفّذ الطرق ذاتها، بغضّ النظر عن لغة البرمجة أو إطار العمل المستخدَم على أي من الطرفين.

عمليات RPC الشائعة

تدعم نقاط نهاية RPC لسلسلة الكتل عادة عمليات مثل:

  • قراءة الحالة — الاستعلام عن أرصدة الحسابات، وحيازات الرموز، وتخزين العقود الذكية، ورقم الكتلة الحالي.
  • إرسال المعاملات — بثّ معاملات موقّعة إلى الشبكة لإدراجها في كتلة.
  • استدعاء العقود الذكية — تنفيذ دوال عقد ذكي للقراءة فقط دون إنشاء معاملة (بلا تكلفة gas).
  • الاشتراك في الأحداث — الاستماع إلى أحداث محدّدة على السلسلة مثل تحويلات الرموز أو نشر العقود أو الكتل الجديدة.
  • استرجاع التاريخ — جلب المعاملات والسجلات وبيانات الكتل السابقة.

مزوّدو RPC

يتطلّب تشغيل عقدة كاملة لسلسلة الكتل تخزينًا ونطاقًا تردّديًا وصيانة كبيرة. ويستخدم كثير من المطوّرين والتطبيقات مزوّدي RPC — خدمات طرف ثالث تشغّل بنية تحتية للعقد وتكشف عن نقاط نهاية RPC للاستخدام العام أو المدفوع. ويقدّم هؤلاء المزوّدون وصولًا موثوقًا وعالي التوفّر إلى بيانات سلسلة الكتل دون إلزام كل تطبيق بتشغيل عقدته الخاصة.

يخدم مزوّدو RPC المشهورون مليارات الطلبات يوميًا عبر شبكات سلسلة كتل متعددة، عاملين كعمود فقري لمنظومة تطبيقات dApp.

لماذا يهمّ مشاريع كريبتو الذكاء الاصطناعي

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

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

استيعاب البيانات. أنظمة الذكاء الاصطناعي التي تحلّل النشاط على السلسلة — أنماط التداول، وسلوكيات المحافظ، ومقاييس البروتوكولات — تعتمد على استدعاءات RPC لاستيعاب بيانات سلسلة الكتل. وتؤثّر سرعة وموثوقية الوصول عبر RPC مباشرة في جودة وحُسن توقيت تحليلات الذكاء الاصطناعي.

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

أين يظهر في بطاقات مشاريع DecAIHub

RPC ليس مدرَجًا كحقل مستقل في بطاقات المشاريع، لكنه يدعم عدة جوانب من بنية المشروع:

  • Main chain — لكل سلسلة رئيسية مواصفات RPC الخاصة بها. ويحدّد اختيار السلسلة أي طرق RPC متاحة وكيف تتفاعل التطبيقات مع الشبكة.
  • Type — المشاريع التي توفّر بنية تحتية لـ RPC كخدمة (مزوّدو عقد، بوّابات API) قد تُصنَّف بناءً على دورها في البنية التحتية.
  • تفاعل dApp والعقود الذكية — أي مشروع يحتوي عقودًا ذكية على السلسلة يعتمد على RPC لجميع التفاعلات الخارجية مع تلك العقود.

ما الذي لا يثبته RPC وحده

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

لا تخلط بين

  • API — RPC هو نوع من API، لكن ليست كل واجهات API هي RPC. فواجهات REST ونقاط نهاية GraphQL وواجهات WebSocket هي أنماط اتصال بديلة. في سلسلة الكتل، يشير «RPC» تحديدًا إلى واجهة JSON-RPC التي تكشف عنها العقد.
  • العقدة — العقدة هي الحاسوب الفعلي الذي يشغّل برمجيات سلسلة الكتل. أما RPC فهو الواجهة التي تتواصل عبرها التطبيقات الخارجية مع تلك العقدة. العقدة تؤدّي العمل؛ وRPC هو الباب.
  • SDK / المكتبة — مكتبات مثل Web3.js أو Ethers.js أو Web3.py تبسّط تفاعلات RPC بتغليف استدعاءات JSON-RPC الخام في دوال ودودة للمطوّرين. المكتبة طبقة تيسير؛ وRPC هو البروتوكول الأساسي.
  • الأوراكل (Oracle) — يجلب الأوراكل بيانات من خارج السلسلة إلى سلسلة الكتل. أما RPC فهو الطريقة التي تقرأ بها التطبيقات وتكتب بيانات على السلسلة. وهما يؤدّيان أدوارًا مختلفة: تجسّر الأوراكل البيانات الخارجية إلى الداخل، بينما يوفّر RPC الوصول إلى بيانات موجودة أصلًا على السلسلة.

الأسئلة الشائعة

هل أحتاج إلى تشغيل عقدتي الخاصة لاستخدام RPC؟

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

ماذا يحدث إذا تعطّل مزوّد RPC؟

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

هل RPC هو نفسه الوصول إلى سلسلة الكتل؟

RPC هو الطريقة الأكثر شيوعًا للوصول إلى سلسلة الكتل، لكنه ليس الوحيد. فبعض التطبيقات تستخدم بروتوكولات بديلة مثل المفهرِسات القائمة على GraphQL أو الاتصالات المباشرة من نظير إلى نظير. غير أن JSON-RPC يظلّ الواجهة القياسية للتفاعل العام مع سلسلة الكتل، وتستخدمه عمليًا كل محفظة وتطبيق dApp وأداة سلسلة كتل خلف الكواليس.

مراجع خارجية

انظر أيضًا

No comments to display

Back to top