لأداء تطبيقات Solana، إذا كنت تريد تقليص زمن الاستجابة ولو بمقدار 20ms، فنقاط نهاية RPC المخصصة + SWQoS هي المفتاح
في التداول عالي التردد وتطبيقات Solana الحرجة، يمكن حتى لـ 20ms أن تصنع فرقًا حاسمًا. تختلف نقاط نهاية RPC المخصصة عن نقاط نهاية RPC المشتركة في تصميمها الأساسي، ولا يمكن إغلاق فجوة الـ 20ms هذه أبدًا. تشرح هذه المقالة السبب، وكيف يحل ERPC المشكلة من البداية إلى النهاية.
خفض 20ms باستخدام http بدلًا من https
ربما لاحظت أن عناوين URL لنقاط نهاية RPC تبدأ عادةً بـ https. فحرف «s» يرمز إلى تشفير TLS/SSL الذي يؤمّن الاتصالات. غير أن هذا التشفير يتطلب مصافحة وتشفيرًا وفك تشفير مستمرين، مما يضيف نحو 20ms من زمن الاستجابة إلى كل طلب.
بعبارة أخرى، إذا أُجري اتصال RPC عبر http بدلًا من https، يمكن إزالة هذه الـ 20ms من جذورها. وفي Solana، حيث تُحسم مزادات الكتل في نحو 50ms، يكون هذا الفرق حاسمًا.
لماذا لا يمكن استخدام http على النقاط المشتركة
قد يسأل البعض: «إذن لماذا لا نسمح بـ http على نقاط النهاية المشتركة؟» الجواب بسيط: هذا مستحيل.
فالسماح بـ http في بيئة مشتركة يعني اتصالًا غير مشفر، مما يعرّض المعاملات لهجمات الوسيط واعتراض الحزم، بل وحتى سرقة المعاملات الموقَّعة. ويمكن لمهاجم يستخدم نقطة النهاية المشتركة نفسها أن يعبث بمعاملاتك أو يعيد إرسالها فعليًا.
لهذا السبب، يجب أن تفرض نقاط النهاية المشتركة TLS/SSL دائمًا. نقاط نهاية RPC المشتركة لدينا مهندَسة لتكون بأسرع ما يمكن ضمن هذا القيد، لكن لا يمكن إزالة عبء TLS البالغ 20ms بحكم التصميم.
كيف يلغي RPC المخصص الـ 20ms
تقيّد نقاط نهاية RPC المخصصة الوصولَ بعملاء محددين موثوقين. وهذا يسمح لنا بإزالة شرط TLS والسماح باتصال http مباشر.
ونتيجة لذلك، يُضمن خفض قدره 20ms. وبغض النظر عن حمل المستخدمين أو مخاطر الهجمات، يضمن هذا الاختلاف البنيوي أن فجوة الـ 20ms بين النقاط المشتركة والمخصصة لن تُردم أبدًا.
التحدي المتبقي: SWQoS
السرعة وحدها لا تكفي. فـ Solana تفرض الجودة المرجحة بالحصة (Stake-weighted QoS — SWQoS)، حيث تُقيَّد العقد التي لا تملك ثقة قائمة على الحصة بـ 20% فقط من مسارات المعاملات المتاحة.
فعلى سبيل المثال، قد تبدو تصميمات Lite-RPC التي ترسل المعاملات مباشرة إلى المدقق القائد الحالي سريعة، لكن من دون SWQoS تظل مقيدة بمسار الـ 20% ذلك. وهذا يعني أنه حتى لو وصلت الحزمة بسرعة، فستواجه معدلات إدراج أقل بكثير.
استخدام RPC المخصص لخفض 20ms أمر حاسم، لكن دمجه مع SWQoS ضروري لتحقيق السرعة ونجاح المعاملات معًا.
يوفر ERPC خيار تفعيل SWQoS على نقاط نهاية RPC المخصصة.
وهذا يعني أنه يمكنك الجمع بين RPC المخصص + SWQoS لتحقيق خفض زمن الاستجابة ومعدلات نجاح أعلى معًا.
المزيد عن SWQoS: https://solana.com/developers/guides/advanced/stake-weighted-qos
المشكلات التي يحلها Validators DAO وERPC
يحل ERPC المشكلات التالية:
- إخفاقات المعاملات وتقلبات زمن الاستجابة في بيئات RPC
- خنق الأداء من قبل العديد من مزودي البنية التحتية
- التأثير الكبير للمسافة الشبكية في جودة الاتصال
- محدودية وصول المشاريع الأصغر إلى بنية تحتية عالية الجودة
أثناء تطوير Epics DAO، مشروع المساهمة المفتوح المصدر في Solana، واجهنا صعوبة بناء بيئة تطوير Solana عالية الأداء ومنخفضة زمن الاستجابة حقًا. وقد قادنا هذا التحدي إلى تصميم منصتنا الخاصة، ومن هذا الأساس نقدم اليوم كلًّا من ERPC وSLV.
التطبيقات المالية وغيرها من التطبيقات الحرجة حساسة بشكل خاص لزمن الاستجابة والأخطاء، إذ تؤثر مباشرة في تجربة المستخدم. بيئات Solana معقدة للغاية، وعلى عكس التمويل التقليدي عبر الإنترنت، فالمدققون موزعون عالميًا. وإلى جانب تعقيد المعرفة الخاصة بـ Web3، يصعب على المطورين الإحاطة بالصورة الكاملة، مما أبطأ التقدم في التحسين.
من خلال تقديم بنية تحتية عالية الأداء لـ Solana، نهدف إلى إزالة هذه العقبات وتحسين تجربة المستخدم عبر المنظومة بأكملها. وكل من ERPC ومشروعنا المفتوح المصدر SLV جزء لا يتجزأ من هذه المهمة.
- الموقع الرسمي لـ ERPC: https://erpc.global/ar
- الموقع الرسمي لـ SLV: https://slv.dev/en
- الموقع الرسمي لـ Epics DAO: https://epics.dev/en
- Discord الرسمي لـ Validators DAO: https://discord.gg/C7ZQSrCkYR
