عقد Solana RPC: الإعداد، ومقدمو الخدمة، وأفضل الممارسات

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

آخر تحديث: يوليو 2025

قد تكون نقاط النهاية العامة لـ Solana مفيدة للتطوير ولكنها ليست ضمان خدمة إنتاج شامل. إذا أعاد تطبيق لامركزي أخطاء 429، أو توقف عند استعلامات الحساب، أو واجه مشاكل في الإرسال تحت الحمل، فإن مسار RPC الخاص به هو أحد المكونات التي يجب التحقيق فيها إلى جانب بناء المعاملات، والرسوم، وتواريخ الانتهاء (expiry)، والشبكات، وظروف الكتلة.

يغطي هذا الدليل ما هي عقدة Solana RPC، وكيف تختلف عن عقدة المدقق، وكيف تتدفق الطلبات عبر النظام، وأين تحصل على عناوين نقاط النهاية العامة، وما هي طرق RPC الأكثر أهمية، وكيفية الاتصال عبر @solana/web3.js، وما هي مقدمي الخدمة المدارين لتقييمهم، وما يتطلبه الاستضافة الذاتية فعليًا، وكيفية إصلاح أخطاء حدود المعدل التي من المحتمل أن تراها بالفعل.

باختصار: للتطوير، استخدم نقاط النهاية العامة المجانية لمؤسسة Solana. للإنتاج، استخدم مزود خدمة مدارًا مثل Helius، QuickNode، Alchemy، أو Triton One. توفر الاستضافة الذاتية مزيدًا من التحكم التشغيلي ولكنها لا تزال تتطلب تخطيط السعة، وسياسات الوصول، والمراقبة، وإرشادات الأجهزة الحالية.

الانتقال إلى:

• ما هي عقد Solana RPC؟
• عقدة RPC مقابل عقدة المدقق (Validator Node)
• كيف تعمل عقد Solana RPC؟
• أنواع عقد Solana RPC
• لماذا جودة عقدة RPC مهمة: DeFi، وNFTs، وأداء التطبيقات اللامركزية (dApp)
• أفضل مقدمي خدمة عقد Solana RPC
• توصيل تطبيقك باستخدام @solana/web3.js
• طرق Solana RPC: ما يمكنك الاستعلام عنه
• كيفية تشغيل عقدة Solana RPC الخاصة بك
• أخطاء Solana RPC الشائعة وكيفية إصلاحها
• أسئلة متكررة
• اختيار استراتيجية Solana RPC المناسبة

ما هي عقد Solana RPC؟

عقدة Solana RPC هي خادم يطبق واجهة برمجة تطبيقات Solana JSON-RPC، يقبل الطلبات من تطبيقات العميل ويعيد بيانات حالة البلوكتشين استجابةً لذلك. تستخدم التطبيقات اللامركزية (dApps)، والمحافظ، ومستكشفات الكتل، والبرامج النصية الآلية هذه العقد لقراءة أرصدة الحسابات، وإرسال المعاملات، والاشتراك في الأحداث داخل الكتلة دون الاحتفاظ بنسخ محلية من دفتر الأستاذ.

تستشهد المواد التاريخية بقدرة معالجة نظرية لـ Solana بالقرب من 65,000 معاملة في الثانية (TPS) ومدّة شريحة مستهدفة بالقرب من 400 مللي ثانية. لا يعد أي منهما نتيجة مباشرة مضمونة: تعريفات المعاملات، والشرائح المتخطيّة، وحركة مرور التصويت، وحمل العمل، وظروف الكتلة، وإصدارات البرامج كلها تؤثر على الأداء المرصود. لا تزال وتيرة الهدف وحجم حالة الحساب تضع متطلبات كبيرة على البنية التحتية لـ RPC.

استدعاء الإجراء عن بعد (RPC) هو نمط اتصال يقوم فيه برنامج على جهاز واحد باستدعاء وظيفة على جهاز آخر كما لو كانت محلية، مع تجريد تعقيدات الشبكة. يمكن لتطبيقك اللامركزي الاستعلام عن حالة الحساب وإرسال المعاملات مقابل عقدة بعيدة بدلاً من الاحتفاظ بنسخة دفتر الأستاذ الخاصة به. تستخدم Solana بروتوكول JSON-RPC 2.0 كبروتوكول الاتصال الخاص بها: تنسيق خفيف الوزن يوجه المكالمات حسب اسم الطريقة عبر HTTP أو WebSocket، وليس عبر مسارات عناوين URL المستندة إلى الموارد مثل واجهات برمجة تطبيقات REST.

تقوم مؤسسة Solana بتشغيل نقاط نهاية عامة مجانية على https://api.mainnet-beta.solana.com وعناوين URL معادلة لشبكات devnet و testnet. تفرض هذه النقاط الحدود القصوى للمعدل لكل عنوان IP. عندما يتجاوز تطبيقك تلك الحدود، فإنه يتلقى أخطاء HTTP 429 Too Many Requests، مما يؤدي إلى فشل متقطع وتدهور في تجربة المستخدم تحت الحمل.

عقدة RPC مقابل عقدة المدقق (Validator Node): فهم الفرق

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

تشارك عقد المدقق في آلية إجماع Tower BFT، وهي آلية تصويت تستند إلى إثبات الحصة (Proof-of-Stake). يحدد إثبات التاريخ (PoH)، آلية التسلسل المشفرة في Solana (وليس بروتوكول الإجماع الخاص بها)، الترتيب قبل إلقاء الأصوات. Tower BFT هي طبقة الإجماع؛ PoH تتعامل مع توقيت الوقت.

بروتوكول Gulf Stream، الخاص بـ Solana لتمرير المعاملات، يرسل المعاملات مباشرة إلى عقد القادة الحالية والمستقبلية، متجاوزًا الميمبول (mempool) الذي تستخدمه البلوكتشينات الأخرى. تعالج العقد هذا الإجراء. لا تقوم عقد RPC بذلك.

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

كيف تعمل عقد Solana RPC: البنية وتدفق البيانات

تحتفظ عقدة Solana RPC بنسخة محلية من دفتر الأستاذ وحالة الحساب، وتخدم هذه البيانات لأي عميل يرسل طلب JSON-RPC صالح.

دورة حياة طلب JSON-RPC

1. يرسل تطبيق العميل (تطبيق لامركزي، محفظة، أو برنامج نصي) طلب HTTP POST أو رسالة WebSocket إلى عنوان URL لنقطة نهاية عقدة RPC.
2. يحتوي جسم الطلب على حمولة JSON-RPC 2.0 مع أربعة حقول: jsonrpc، id، method، params.
3. تستقبل عقدة RPC الطلب وتوجهه إلى المعالج الداخلي المناسب بناءً على حقل method.
4. تستعلم العقدة عن نسخة دفتر الأستاذ المحلية أو مخزن حالة الحساب عن البيانات المطلوبة.
5. تعيد العقدة استجابة مشفرة بتنسيق JSON تحتوي إما على البيانات المطلوبة أو كائن خطأ منظم.

مثال ملموس لـ getBalance:

// Request
{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "getBalance",
  "params": ["YourPublicKeyBase58Here", {"commitment": "confirmed"
}

// Response { "jsonrpc": "2.0", "result": { "context": {"slot": 285823400}, "value": 5000000000 }, "id": 1 } // Note: value is in lamports. Divide by 1,000,000,000 to convert to SOL.

على عكس واجهات برمجة تطبيقات REST التي تستخدم عناوين URL المستندة إلى الموارد، يوجه JSON-RPC كل مكالمة عبر نقطة نهاية واحدة باستخدام حقل `method`. سيتعرف المطورون ذوو الخبرة في Ethereum على بنية الطلب. تختلف Solana في ثلاث طرق رئيسية: لا يوجد ميمبول (mempool) (تذهب المعاملات مباشرة إلى القائد الحالي)، وتوجد الحالة في الحسابات بدلاً من تخزين عقود EVM، والشرائح البالغة 400 مللي ثانية أسرع بحوالي 30 مرة من أوقات كتل Ethereum البالغة 12 ثانية.

### مستويات الالتزام (Commitment Levels): processed، confirmed، finalized

كل مكالمة RPC تقرأ الحالة تقبل معلمة `commitment`:

- **`processed`**: أحدث شريحة شاهدتها العقدة. الأسرع، ولكن من الممكن نظريًا التراجع عن الشريحة.
- **`confirmed`**: تلقت الشريحة أغلبية ساحقة من أصوات المدققين. نهائية قوية لمعظم حالات استخدام التطبيقات اللامركزية.
- **`finalized`**: الشريحة جزء دائم من السلسلة. استخدمها للعمليات ذات المخاطر العالية.

### ما تخزنه عقدة Solana RPC

تحتوي العقدة على فئتين من البيانات. توجد حالة الحساب الحالية في ذاكرة الوصول العشوائي (RAM): لقطة لكل حساب نشط في أحدث فتحة (slot) مؤكدة، وهي مطلوبة لاستجابات الاستعلام السريعة. توجد بيانات دفتر الحسابات التاريخية على قرص NVMe SSD: جميع سجلات المعاملات منظمة حسب الفتحة. تراكم سولانا ما يقرب من 100 إلى 200 جيجابايت من بيانات دفتر الحسابات يومياً على المينيت التجريبي (mainnet-beta). هذا النمو في التخزين، إلى جانب الفتحات التي تبلغ مدتها 400 مللي ثانية، يفسر سبب تطلب عقد RPC ذاكرة وصول عشوائي (RAM) لا تقل عن 256 جيجابايت وعدة تيرابايت من التخزين السريع.

للحصول على مرجع Solana JSON-RPC API الكامل، راجع [docs.solana.com/api](https://docs.solana.com/api).

### HTTP مقابل WebSocket: اختيار وسيلة النقل المناسبة

| وسيلة النقل | النموذج | الاستخدام الشائع | أمثلة على الطرق |
|---|---|---|---|
| HTTP / HTTPS | طلب-استجابة (بدون حالة، سحب) | استعلامات لمرة واحدة، إرسال المعاملات | `getBalance` ، `getAccountInfo` ، `sendTransaction` |
| WebSocket / WSS | اتصال مستمر (بحالة، دفع) | اشتراكات الأحداث في الوقت الفعلي | `accountSubscribe` ، `logsSubscribe` ، `signatureSubscribe` |

---

## أنواع عقد Solana RPC: العامة، والخاصة، والمستضافة ذاتياً

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

| النوع | المشغل | التكلفة | حدود المعدل | هدف الخدمة | الاستخدام الشائع |
|---|---|---|---|---|---|
| نقطة نهاية عامة | مؤسسة سولانا | مجاني | نعم (يتم تطبيقها لكل عنوان IP) | لا يوجد | التطوير والاختبار |
| مزود مدار | Helius, QuickNode, Alchemy, Triton One | تتوفر باقات مدفوعة | حدود أعلى أو بدون حدود في الباقات المدفوعة | نعم (الباقات المدفوعة) | تطبيقات dApps للإنتاج |
| مستضافة ذاتياً | أنت | تكلفة الأجهزة + العمليات | لا يوجد (أنت تتحكم فيها) | أنت تحدده | البروتوكولات الكبيرة، البورصات |

### نقاط نهاية Solana RPC العامة (مجانية)

تدير مؤسسة سولانا أربع نقاط نهاية RPC عامة، واحدة لكل مجموعة شبكة (cluster). جميعها مجانية ولكنها تفرض قيوداً على معدل الطلبات لكل عنوان IP.

| المجموعة (Cluster) | عنوان URL لنقطة نهاية HTTP | عنوان URL لنقطة نهاية WebSocket | حالة الاستخدام |
|---|---|---|---|
| mainnet-beta | `https://api.mainnet-beta.solana.com` | `wss://api.mainnet-beta.solana.com` | شبكة الإنتاج (تسمية "beta" تاريخية؛ هذا هو المينيت المباشر لسولانا) |
| devnet | `https://api.devnet.solana.com` | `wss://api.devnet.solana.com` | التطوير والاختبار؛ تتوفر عمليات توزيع مجانية لعملة SOL (airdrops) |
| testnet | `https://api.testnet.solana.com` | `wss://api.testnet.solana.com` | اختبار الإجهاد قبل الإنتاج |
| localnet | `http://localhost:8899` | `ws://localhost:8900` | التطوير المحلي؛ يتم إنشاؤه بواسطة `solana-test-validator` (ليست مجموعة عامة رسمية) |

تفرض نقاط النهاية العامة حداً لمعدل الطلبات يبلغ حوالي 100 طلب لكل 10 ثوانٍ لكل عنوان IP. يؤدي تجاوز هذا الحد إلى إرجاع خطأ HTTP 429 (طلبات كثيرة جداً). تعمل نقاط النهاية هذه لأغراض التطوير والاختبار. لاستخدام الإنتاج، راجع مقارنة مزودي Solana RPC أدناه.

للحصول على وثائق المجموعة الكاملة، راجع [docs.solana.com/clusters](https://docs.solana.com/clusters).

### مزودو عقد RPC الخاصة والمدارة

قد يقدم مزود RPC المدار نقاط نهاية مخصصة، وحدوداً منشورة أعلى، ودعماً لـ WebSocket، وأهداف خدمة، ومناطق متعددة؛ تعتمد الميزات الدقيقة على الباقة الحالية. المزودون الأربعة الأساسيون لسولانا هم:

- **Helius**: مزود مخصص لسولانا مع واجهات برمجة تطبيقات RPC محسنة وإشعارات Webhook
- **QuickNode**: مزود متعدد السلاسل مع توزيع جغرافي وسوق للإضافات
- **Alchemy**: مزود متعدد السلاسل مع أدوات تطوير بمستوى المؤسسات
- **Triton One**: متخصص مخصص لسولانا يركز على أداء RPC الخام لأعباء عمل المؤسسات

توجد مقارنة كاملة مع الأسعار ودعم WebSocket والميزات التنافسية في قسم مقارنة المزودين.

### عقد Solana RPC المستضافة ذاتياً

تمنحك الاستضافة الذاتية تحكماً كاملاً في البنية التحتية لـ RPC الخاصة بك دون حدود لمعدل الطلبات، ولكن تكلفة الأجهزة تبدأ بآلاف الدولارات وصيانة DevOps المستمرة ليست بالأمر الهين. المتطلبات الكاملة ونظرة عامة على الإعداد موجودة في "كيفية تشغيل عقدة Solana RPC الخاصة بك".

---

## لماذا تهم جودة عقدة RPC: DeFi، وNFTs، وأداء التطبيقات اللامركزية (dApp)

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

### بوتات التداول و المراجحة في DeFi

تقوم بروتوكولات DeFi على سولانا بمعالجة المعاملات الحساسة للوقت حيث يحدد زمن الانتقال (latency) النتائج. إن بوت التداول الذي يستدعي `getLatestBlockhash` و `sendTransaction` من خلال نقطة نهاية عامة محدودة المعدل يخاطر بالحصول على blockhash قديم أو سقوط المعاملة أثناء مهلة الخطأ 429. على الجدول الزمني لفتحات سولانا البالغ 400 مللي ثانية، يمكن لفرق 50 مللي ثانية في وقت استجابة RPC أن يحدد ما إذا كانت المعاملة ستصل في الفتحة المستهدفة أم ستفقدها تماماً.

تعتمد كل من Jupiter (مجمّع)، وRaydium (صانع سوق آلي/ DEX)، وDrift (عقود دائمة)، وMarginfi (إقراض) على وصول RPC ذو زمن انتقال منخفض. على عكس إيثيريوم و DeFi، تتخطى معاملات سولانا الميمبول تماماً عبر Gulf Stream، وتذهب مباشرة إلى القائد الحالي. لا يوجد طابور ترتيب للاعتماد عليه إذا وصل استدعاء RPC الخاص بك متأخراً.

### صك الـ NFT ومراقبة السوق

تولد عمليات صك الـ NFT ذات الطلب العالي طفرات من مئات استدعاءات `sendTransaction` المتزامنة من المشترين الذين يتنافسون على عرض محدود. تعيد نقطة النهاية العامة المحددة بنحو 10 طلبات في الثانية أخطاء 429 لمعظم المشاركين أثناء ذروة عمليات التوزيع. تستخدم أسواق NFT مثل Magic Eden وTensor اشتراكات WebSocket `logsSubscribe` لاكتشاف أحداث الصك في الوقت الفعلي، الأمر الذي يتطلب مزوداً يتعامل مع اتصالات WebSocket المستقرة على نطاق واسع.

### محافظ واستوديوهات لوحات معلومات المحافظ

تستدعي تطبيقات المحافظ `getBalance` و `getTokenAccountBalance` لكل أصل يمتلكه المستخدم، بالإضافة إلى `getAccountInfo` لقراءة البيانات الوصفية داخل الكتلة. يمكن للمحفظة التي تخدم 10,000 مستخدم نشط إصدار عشرات الآلاف من استعلامات RPC في الدقيقة. يحافظ مزود RPC الخاص الذي يتمتع بسعة QPS كافية (استعلامات في الثانية) على حل هذه الاستعلامات دون التأثير سلباً على تجربة المستخدم. يشير مصطلح QPS هنا إلى إنتاجية طلبات RPC، وليس إنتاجية المعاملات على مستوى شبكة سولانا.

### التحليلات داخل الكتلة، والمفهرسات، وتكامل البورصات

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

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

---

## مقارنة مزودي عقد Solana RPC

بالنسبة لمعظم تطبيقات dApps للإنتاج، فإن السؤال ليس ما إذا كان يجب استخدام مزود RPC مدار، ولكن أي مزود يناسب عبء عملك. يغطي الجدول الخيارات الأربعة الأساسية مع نقطة النهاية العامة المجانية لمؤسسة سولانا كمعيار أساسي.

| المزود | خاص بـ Solana | المستوى المجاني | المستوى المدفوع (تقريبي) | عقدة مخصصة | WebSocket | المناطق | الميزة الرئيسية |
|---|---|---|---|---|---|---|---|
| [Helius](https://helius.dev) | نعم | نعم | ~$49-$499/شهر | نعم | نعم | الولايات المتحدة، الاتحاد الأوروبي | واجهات برمجة تطبيقات محسّنة: خطافات الويب، تحليل المعاملات، واجهات برمجة تطبيقات NFT |
| [QuickNode](https://www.quicknode.com) | لا (متعدد السلاسل) | نعم (تجريبي) | ~$49-$399/شهر | نعم | نعم | الولايات المتحدة، الاتحاد الأوروبي، آسيا + | سوق الإضافات؛ تغطية واسعة متعددة السلاسل |
| [Alchemy](https://www.alchemy.com) | لا (متعدد السلاسل) | نعم | ~$49-$399/شهر | نعم | نعم | الولايات المتحدة، الاتحاد الأوروبي | أدوات المطورين للمؤسسات؛ إشعارات خطافات الويب |
| [Triton One](https://triton.one) | نعم | لا | مخصص/للمؤسسات | نعم | نعم | الولايات المتحدة، الاتحاد الأوروبي، آسيا | أداء بمستوى المؤسسات؛ اتصل للتسعير |
| مؤسسة Solana (عام) | نعم | مجاني (محدود المعدل) | غير متاح | لا | نعم (محدود المعدل) | الولايات المتحدة | للتطوير والاختبار فقط |

*معلومات التسعير في هذا الجدول كانت دقيقة وقت النشر. تتغير خطط المزودين والتسعير والميزات بشكل متكرر. تحقق من التفاصيل الحالية مباشرة على موقع كل مزود قبل اتخاذ قرار.*

*آخر تحديث: يوليو 2025*

تعلن **Helius** عن توفير طرق RPC خاصة بـ Solana، وخطافات ويب، وميزات تحليل المعاملات. يجب التحقق من القدرات، الحصص، التسعير، المناطق، وشروط الخدمة مباشرة على [helius.dev](https://helius.dev) واختبارها بالحمل التشغيلي المقصود.

تعلن **QuickNode** عن توفير بنية تحتية لـ RPC متعددة السلاسل، نقاط نهاية إقليمية، وإضافات اختيارية. تحقق من تغطية Solana الحالية، الحصص، التسعير، وشروط الخدمة على [quicknode.com](https://www.quicknode.com)، ثم قم بقياس الأداء للطرق والمناطق المطلوبة.

تعلن **Alchemy** عن توفير بنية تحتية للمطورين متعددة السلاسل تشمل دعم Solana. قم بتأكيد تغطية الطرق الحالية، سلوك WebSocket، الحدود، المناطق، والتسعير على [alchemy.com](https://www.alchemy.com) قبل اعتبارها معادلة لمزود آخر.

تعلن **Triton One** عن توفير بنية تحتية لـ Solana لأحمال العمل ذات الإنتاجية الأعلى. تتطلب معدلات الاستجابة، التوفر، التغطية الجغرافية، الحدود، والشروط التجارية التحقق المباشر على [triton.one](https://triton.one) واختبار محدد للحمل التشغيلي.

كانت GenesysGo تدير سابقًا خدمة Solana RPC تحت علامة Shadow التجارية. تحقق من الحالة الحالية على genesysgo.com قبل التقييم.

> يقدم جميع المزودين الرئيسيين مستويات مجانية أو خطط تجريبية كافية للتطوير والاختبار. تصبح حدود المعدل مصدر قلق للإنتاج فقط عندما تخدم تطبيقاتك مستخدمين حقيقيين على نطاق واسع.

### كيفية تقييم مزود Solana RPC

يعتمد المزود المناسب على حمل العمل الخاص بك:

| وضعك | نقطة البداية للتقييم |
|---|---|
| مطور فردي أو فريق صغير، ميزانية محدودة | المستوى المجاني لـ Helius أو النسخة التجريبية المجانية لـ QuickNode؛ قم بالترقية عند الوصول إلى حدود المعدل |
| تطبيق لامركزي إنتاجي على Solana فقط | Helius (خاص بـ Solana، واجهات برمجة تطبيقات محسّنة) أو Triton One (إذا كانت استجابة p99 هي الشاغل الرئيسي) |
| فريق متعدد السلاسل (Solana بالإضافة إلى Ethereum أو غيرها) | QuickNode أو Alchemy (كلاهما يدعم سلاسل متعددة تحت حساب واحد) |
| مؤسسة ذات متطلبات SLA صارمة | QuickNode (مستوى المؤسسات) أو Alchemy (سمعة المؤسسات) |
| بروتوكول DeFi عالي التردد أو عملية MEV | Triton One (تركيز مؤسسي) أو عقدة RPC مستضافة ذاتيًا |
| أقصى قدر من التحكم، لا توجد حدود معدل، فريق DevOps كبير | عقدة RPC مستضافة ذاتيًا (راجع متطلبات الأجهزة ونظرة عامة على الإعداد) |

لا يمكن استبدال ادعاءات زمن الاستجابة الخاصة بالمزود. p50 هو متوسط ​​وقت الاستجابة، بينما يمثل p99 أبطأ 1% من الطلبات وقد يكون مهمًا للعمليات الحساسة للوقت. تعتمد النتائج الفعلية على مزيج الطرق، الحمل، القرب الجغرافي، التخزين المؤقت، وحدود الخطة، لذا قم بقياس نمط الطلب المقصود قبل اختيار خطة مدفوعة.

---

## ربط تطبيقك بعقدة Solana RPC باستخدام @solana/web3.js

يتطلب التبديل من نقطة النهاية العامة لمؤسسة Solana إلى مزود خاص تغيير سطر واحد في تطبيقك: سلسلة عنوان URL التي تم تمريرها إلى مُنشئ `Connection`.

> **ملاحظة الإصدار:** تستخدم أمثلة التعليمات البرمجية في هذا القسم @solana/web3.js v1.x، وهو المعيار الإنتاجي الحالي. تعمل Solana Labs على تطوير v2.0 بواجهة برمجة تطبيقات مختلفة بشكل كبير. إذا كنت تستخدم v2.0، فارجع إلى وثائق v2.0 الرسمية للطرق المعادلة.

### التثبيت والاتصال

**الخطوة 1: تثبيت الحزمة**

npm install @solana/web3.js

الخطوة 2: إنشاء اتصال والاستعلام عن الرصيد

import { Connection, PublicKey, LAMPORTS_PER_SOL } from "@solana/web3.js";

// اسحب نقطة النهاية من متغير بيئة - لا تقم أبدًا بتضمين عنوان URL خاص بشكل دائم في الكود
const RPC_ENDPOINT = process.env.RPC_URL ?? "https://api.devnet.solana.com";

const connection = new Connection(RPC_ENDPOINT, "confirmed");

async function getWalletBalance(address: string): Promise<void> {
  const publicKey = new PublicKey(address);

  // getBalance تُرجع lamports؛ قم بالقسمة على LAMPORTS_PER_SOL (10^9) للحصول على SOL
  const balanceLamports = await connection.getBalance(publicKey);
  const balanceSOL = balanceLamports / LAMPORTS_PER_SOL;

  console.log(`الرصيد: ${balanceSOL} SOL`);
}

الخطوة 3: قراءة بيانات الحساب

async function getAccountData(address: string): Promise<void> {
  const publicKey = new PublicKey(address);

  // getAccountInfo تُرجع null إذا لم يكن الحساب موجودًا
  const accountInfo = await connection.getAccountInfo(publicKey);

  if (!accountInfo) {
    console.log("الحساب غير موجود");
    return;
  }

  console.log("برنامج المالك:", accountInfo.owner.toBase58());
  console.log("طول البيانات (بايت):"، accountInfo.data.length);
  console.log("لامبورتس:", accountInfo.lamports);
}

الخطوة 4: إرسال معاملة

import {
  Transaction,
  SystemProgram,
  Keypair,
  sendAndConfirmTransaction,
} from "@solana/web3.js";

async function transferSOL(
  sender: Keypair,
  recipientAddress: string,
  amountSOL: number
): Promise<string> {
  const recipient = new PublicKey(recipientAddress);
  const lamports = amountSOL * LAMPORTS_PER_SOL;

  const transaction = new Transaction().add(
    SystemProgram.transfer({
      fromPubkey: sender.publicKey,
      toPubkey: recipient,
      lamports,
    })
  );

  // sendAndConfirmTransaction تنتظر التزام "confirmed" قبل حلها
  const signature = await sendAndConfirmTransaction(connection, transaction, [sender]);
  return signature;
}

الخطوة 5: تكوين التبديل بين نقاط النهاية بناءً على البيئة

قم بإعداد وحدة تكوين لتبديل الشبكات عبر متغير بيئة بدلاً من تعديل كود التطبيق:

// config/rpc.ts
const RPC_ENDPOINTS: Record<string, string> = {
  "mainnet-beta": "https://api.mainnet-beta.solana.com",
  "devnet":       "https://api.devnet.solana.com",
  "private":      process.env.PRIVATE_RPC_URL ?? "",
};

const NETWORK = process.env.SOLANA_NETWORK ?? "devnet";
export const connection = new Connection(RPC_ENDPOINTS[NETWORK], "confirmed");

ملاحظة أمنية: لا تقم أبدًا بتضمين عنوان URL الخاص بنقطة النهاية RPC الخاصة بك بشكل دائم في JavaScript من جانب العميل. عنوان URL المكشوف في المتصفح يسرب مفتاح واجهة برمجة التطبيقات الخاص بك لأي شخص يقوم بفحص حركة مرور الشبكة. قم بتوجيهه عبر وكيل من جانب الخادم أو مسار واجهة برمجة تطبيقات خلفي.

للحصول على مرجع واجهة برمجة التطبيقات الكامل لـ @solana/web3.js، راجع solana-labs.github.io/solana-web3.js.

اتصالات RPC عبر HTTP مقابل WebSocket: متى تستخدم كل منهما

تستخدم اتصالات WebSocket wss:// بدلاً من https://. يوفر معظم المزودين المدارين نقطتي نهاية تحت نفس الخطة.

// اشتراك WebSocket: مراقبة تغييرات الحساب في الوقت الفعلي
const publicKey = new PublicKey("YourAccountPublicKeyHere");

const connectionWithWS = new Connection(
  process.env.RPC_URL ?? "https://api.devnet.solana.com",
  {
    commitment: "confirmed",
    wsEndpoint: process.env.WSS_URL ?? "wss://api.devnet.solana.com",
  }
);

// ترجع onAccountChange معرف اشتراك يُستخدم للتنظيف لاحقاً
const subscriptionId = connectionWithWS.onAccountChange(
  publicKey,
  (accountInfo, context) => {
    console.log("تغير الحساب عند الفتحة (slot):", context.slot);
    console.log("رصيد لامبورت الجديد:", accountInfo.lamports);
  },
  "confirmed"
);

// قم بإزالة الاشتراك عندما لا تعود هناك حاجة إليه:
// connectionWithWS.removeAccountChangeListener(subscriptionId);

التعامل مع قيود المعدل وأخطاء 429

يعني خطأ 429 (Too Many Requests) من نقطة نهاية Solana عامة أن تطبيقك قد تجاوز حد المعدل لكل عنوان IP. هناك ثلاث استراتيجيات لمعالجة ذلك:

1. التبديل إلى مزود خاص مُدار. تقدم شركات Helius وQuickNode وAlchemy وTriton One خططاً مصممة لحركة مرور الإنتاج. انظر مقارنة مزودي Solana RPC الخاصين.
2. تنفيذ التراجع الأسي (Exponential backoff). عند حدوث استجابة 429، أعد المحاولة مع تأخير يتضاعف في كل محاولة (انظر الكود أدناه).
3. تجميع قراءات الحسابات باستخدام getMultipleAccounts. جلب 20 حساباً في مكالمة واحدة يستهلك طلباً واحداً بدلاً من 20.

// غلاف التراجع الأسي لأي استدعاء RPC
async function withRetry<T>(
  fn: () => Promise<T>,
  maxRetries: number = 5
): Promise<T> {
  let attempt = 0;
  while (attempt < maxRetries) {
    try {
      return await fn();
    } catch (error: any) {
      const is429 = error?.message?.includes("429");
      if (is429 && attempt < maxRetries - 1) {
        // الانتظار 500 مل ثانية، ثم ثانية، ثم ثانيتين، ثم 4 ثوانٍ، ثم 8 ثوانٍ
        const waitMs = 500 * Math.pow(2, attempt);
        await new Promise((resolve) => setTimeout(resolve, waitMs));
        attempt++;
      } else {
        throw error;
      }
    }
  }
  throw new Error("تجاوز الحد الأقصى لمحاولات إعادة المحاولة");
}

طرق Solana RPC: ما يمكنك الاستعلام عنه

توفر واجهة برمجة تطبيقات JSON-RPC الخاصة بـ Solana أكثر من 80 طريقة. يغطي الجدول أدناه الطرق التي يستخدمها معظم مطوري التطبيقات اللامركزية (dApp) بانتظام.

طرق HTTP RPC

تم إهمال getRecentBlockhash. استخدم getLatestBlockhash بدلاً منها. ترجع البديلة أيضاً lastValidBlockHeight الذي يتيح معالجة موثوقة للمعاملات ذات تواريخ انتهاء الصلاحية.

طرق اشتراك WebSocket

تناسب اشتراكات WebSocket أي تطبيق لامركزي (dApp) يحتاج إلى التفاعل مع الأحداث داخل الكتلة دون الحاجة للاستعلام المتكرر. تعمل accountSubscribe عند تغير بيانات حساب معين، وهي مفيدة لتتبع محفظة المستخدم أو حساب الحالة لبرنامج Solana (ما يعادل عقد ذكي على Ethereum). وتبث logsSubscribe سجلات المعاملات التي تطابق فلتر معرف البرنامج، وتستخدمها بروتوكولات DeFi مثل Jupiter وRaydium لاكتشاف أحداث التبادل فور حدوثها.

يقوم Anchor، وهو إطار تطوير برامج Solana الأكثر استخداماً، بإنشاء عملاء TypeScript يستدعون هذه الطرق عبر @solana/web3.js داخلياً. ينطبق تكوين RPC بشكل متطابق على التطبيقات اللامركزية القائمة على Anchor.

للحصول على المرجع الكامل للطرق بما في ذلك المعلمات وأنواع الإرجاع ورموز الخطأ، راجع توثيق واجهة برمجة التطبيقات لـ Solana RPC.)

كيفية تشغيل عقدة Solana RPC الخاصة بك: المتطلبات ونظرة عامة على الإعداد

تمنحك الاستضافة الذاتية لعقدة Solana RPC تحكماً كاملاً، وعدم وجود قيود على المعدل، وأقصى قدر من خصوصية البيانات. يصل الاستثمار في الأجهزة إلى آلاف الدولارات، ويتطلب الحفاظ على صحة العقدة قدرة مخصصة لعمليات التطوير (DevOps). البروتوكولات الكبيرة والمنصات والفرق التي لديها قدرات بنية تحتية حالية هي الجمهور المستهدف لهذا المسار.

متطلبات الأجهزة

تتطور متطلبات الأجهزة مع نمو الشبكة. تحقق من المواصفات الحالية مقابل وثائق Solana الرسمية على docs.solana.com/running-validator) قبل توفير الأجهزة.

يخزن نموذج Solana القائم على الحسابات حالة جميع البرامج في حسابات فردية. يجب أن تحتفظ عقدة RPC الكاملة بحالة الحساب الحالية لكل حساب نشط في ذاكرة الوصول العشوائي (RAM) لاستجابات الاستعلام السريعة، بالإضافة إلى بيانات السجل التاريخية على قرص NVMe SSD. يعني نمو التخزين بمعدل 100 إلى 200 جيجابايت يومياً على المينيت بيتا (mainnet-beta) أنه يجب على المشغلين التخطيط لتدوير السجل بشكل مستمر.

نظرة عامة على عملية الإعداد

مطلوب سبع مراحل. يرتبط كل ملف بالوثائق الرسمية لـ Solana للحصول على تفاصيل التكوين الكاملة.

1. توفير الأجهزة التي تلبي أو تتجاوز المواصفات المذكورة أعلاه.
2. تثبيت نظام التشغيل وتكوين معلمات نواة Linux: ارفع حدود واصف ملف ulimit واضبط إعدادات شبكة sysctl لتناسب حجم حركة مرور UDP المرتفع في Solana.
3. تثبيت Solana CLI وملف agave الثنائي للمدقق (المعروف سابقاً باسم solana-validator) من قناة إصدار Solana Labs الرسمية.
4. تكوين العقدة لوضع RPC عن طريق تمرير علامة --no-voting لتعطيل المشاركة في الإجماع، وضبط --rpc-port 8899 (HTTP) و--rpc-pubsub-port 8900 (WebSocket).
5. تنزيل لقطة (Snapshot) من مستودع اللقطات التابع لمؤسسة Solana لبدء المزامنة من حالة حديثة بدلاً من الإعادة من البداية (genesis).
6. بدء العقدة ومراقبة تقدم المزامنة باستخدام solana catchup لتتبع مدى تأخر العقدة عن قمة الكتلة (cluster tip).
7. تكوين قواعد جدار الحماية لكشف المنفذين 8899 و8900 فقط لعناوين IP المصرح لها. لا تعرض منفذ RPC الخاص بك علناً بدون مصادقة.

وقت المزامنة والصيانة المستمرة

تستغرق مزامنة اللقطة من يوم إلى 3 أيام على الأجهزة الموصى بها. تستغرق المزامنة من البداية (genesis) وقتاً أطول بكثير ولا يوصى بها.

تتراوح تكلفة الأجهزة الفعلية (Bare metal) عادةً بين 500 و1,500 دولار شهرياً حسب المواصفات وموقع مركز البيانات. وتكلف البدائل السحابية أكثر بسبب نفقات المحاكاة الافتراضية على أعباء العمل كثيفة التخزين. يجبر نمو التخزين بمعدل 100 إلى 200 جيجابايت يومياً على الاختيار بين التخصيص المسبق لمجلدات ضخمة أو أتمتة تقليم السجل.

بالنسبة للفرق التي تقيم قرار البناء مقابل الشراء، قارن تكاليف المزودين المدارين في قسم مقارنة المزودين قبل الالتزام بشراء الأجهزة.

أخطاء Solana RPC الشائعة وكيفية إصلاحها

429 طلبات كثيرة جداً (Too Many Requests)

لقد تجاوز تطبيقك حد المعدل لكل عنوان IP على نقطة النهاية العامة لـ Solana. لإصلاح ذلك:

1. التبديل إلى مزود خاص مُدار. تقدم Helius و QuickNode و Alchemy و Triton One خططًا مصممة لحركة المرور الإنتاجية. انظر مقارنة مزودي Solana RPC الخاصين.
2. تطبيق التراجع الأسي. عند تلقي استجابة 429، حاول مرة أخرى بفاصل زمني يتضاعف مع كل محاولة. مثال رمزي موجود في قسم معالجة حدود المعدل.
3. تجميع قراءات الحسابات باستخدام getMultipleAccounts. جلب 20 حسابًا في مكالمة واحدة يستهلك طلبًا واحدًا بدلاً من 20.

مهلات تأكيد المعاملات

لم يتم إرسال معاملة تم تقديمها عبر sendTransaction بنجاح. قد يكون تجزئة الكتلة (blockhash) قد انتهت صلاحيتها، أو قد تكون الشبكة مزدحمة. لإصلاح ذلك:

1. استدعِ getLatestBlockhash فورًا قبل بناء معاملة. لا تستخدم getRecentBlockhash (مهمل).
2. تحقق من lastValidBlockHeight من الاستجابة وحاول مرة أخرى قبل الوصول إلى هذا الارتفاع.
3. استخدم sendAndConfirmTransaction بدلاً من sendTransaction الخام لإعادة المحاولة التلقائية عند حدوث فشل مؤقت.

فشل حدود المعدل لـ getProgramAccounts

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

أسئلة شائعة: عقد Solana RPC

ما هو عقد Solana RPC؟

عقد Solana RPC هو خادم ينفذ واجهة برمجة تطبيقات Solana JSON-RPC، ويقبل الطلبات من تطبيقات العميل ويعيد بيانات حالة البلوكتشين. تستخدم التطبيقات اللامركزية (dApps) والمحافظ ومستكشفات الكتل هذه العقد لقراءة أرصدة الحسابات، وجلب سجل المعاملات، وتقديم المعاملات الموقعة إلى الشبكة دون تشغيل نسخة محلية من دفتر الأستاذ.

يخدم الاثنان أدوارًا مختلفة. يخدم عقد RPC البيانات للعملاء الخارجيين عبر واجهة برمجة تطبيقات JSON-RPC، ولا يشارك في الإجماع، ولا يحصل على أي مكافآت تخزين. يصوت عقد المُصادقة على صحة الكتل في كل فترة (slot)، ويتطلب SOL مخزنًا، ويكسب مكافآت SOL للأصوات الصحيحة. يقوم بعض المشغلين بتشغيل كليهما على نفس الجهاز، لكن الأدوار تظل منفصلة منطقيًا.

نعم. نقاط النهاية العامة لمؤسسة Solana على api.mainnet-beta.solana.com و api.devnet.solana.com و api.testnet.solana.com مجانية. إنها تفرض حدًا للمعدل يبلغ حوالي 100 طلب لكل نافذة 10 ثوانٍ لكل عنوان IP. هذه النقاط النهائية كافية للتطوير والاختبار ولكنها غير مناسبة للتطبيقات اللامركزية الإنتاجية التي تخدم مستخدمين حقيقيين.

ثلاثة أساليب تعمل معًا: التبديل إلى مزود RPC خاص مُدار لحركة المرور الإنتاجية؛ تطبيق التراجع الأسي لإعادة محاولة الطلبات الفاشلة مع فترات انتظار متزايدة؛ وتجميع قراءات الحسابات المتعددة في مكالمات getMultipleAccounts واحدة بدلاً من إصدار getAccountInfo لكل حساب.

كحد أدنى: وحدة معالجة مركزية بـ 12 نواة، و 256 جيجابايت من ذاكرة الوصول العشوائي DDR4، و 2 تيرابايت NVMe SSD، واتصال شبكة مخصص بسرعة 1 جيجابت في الثانية. موصى به للإنتاج: وحدة معالجة مركزية بـ 24 نواة، و 512 جيجابايت من ذاكرة الوصول العشوائي، و 2x 2 تيرابايت NVMe SSD، وشبكة بسرعة 10 جيجابت في الثانية. تحقق من المواصفات الحالية مقابل وثائق مُصادق Solana,) حيث تزداد المتطلبات مع نمو الشبكة.

خطط لمدة 1 إلى 3 أيام باستخدام لقطة حديثة على الأجهزة الموصى بها. يستغرق المزامنة من البداية وقتًا أطول بكثير. توفر مؤسسة Solana لقطات رسمية لتسريع العملية.

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

يُعد Helius و QuickNode خيارين تتم مناقشتهما بشكل متكرر، لكن الظهور المجتمعي ليس دليلاً على الملاءمة أو الأداء. يناسب Helius الفرق التي تبني حصريًا على Solana وتحتاج إلى واجهات برمجة تطبيقات محسّنة خاصة بـ Solana. يناسب QuickNode الفرق التي تدعم بلوكتشين متعددة تحت حساب واحد. Triton One هو الخيار لأعباء العمل المؤسسية حيث يكون زمن استجابة p99 هو القيد الأساسي. يعتمد الاختيار الصحيح على عبء العمل الخاص بك وما إذا كانت الميزات الخاصة بـ Solana أو دعم البلوكتشين المتعدد أكثر أهمية.

أدلة Solana ذات الصلة

• نشر كتل Solana Turbine
• فترات Solana ووقت الكتلة

استكشف SOL على Bybit

يمكن للقراء مراجعة معلومات سوق SOL الحالية) أو سوق التداول الفوري SOL/USDT.). توفر هذه الروابط معلومات السوق والوصول؛ لا تتحقق من صحة ادعاء تقني أو تشير إلى أن SOL مناسب لكل قارئ.

توجد ثلاثة مسارات، وستتعرف معظم الفرق على أي منها يناسب مرحلتهم الحالية على الفور.

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

الخطوات التالية:

• سجل للحصول على مستوى تطوير مجاني: helius.dev أو quicknode.com
• راجع مرجع طرق Solana JSON-RPC الكامل: docs.solana.com/api
• راجع مواصفات الأجهزة قبل توفيرها للاستضافة الذاتية: كيفية تشغيل عقد Solana RPC الخاص بك.