ERPC تحسّن بنية شبكة Solana التحتية تحسينًا كبيرًا — ترقية كاملة لمنصة الوسيط (Proxy) عالية الأداء المكتوبة بـ Rust في جميع مناطق RPC وgRPC وShredstream المشتركة، مع تحقيق تحديثات بلا أي توقف

أنجزت ERPC، التي تشغّلها ELSOUL LABO B.V. (المقر الرئيسي: أمستردام، هولندا؛ المدير التمثيلي والرئيس التنفيذي: فوميتاكي كاواساكي) وValidators DAO، ترقية كبيرة لبنية شبكة Solana التحتية لديها.

طُبّقت هذه الترقية بالفعل على جميع المناطق وجميع نقاط النهاية المشتركة التي توفرها ERPC (Solana RPC وGeyser gRPC وShredstream). وقد حدّثنا سلوكيات البنية التحتية التي تميل إلى التأثير مباشرة في النتائج الفعلية بوصفها منظومة متكاملة، بما في ذلك بدء الاتصال، ومعالجة TLS، والتحكم في التخزين المؤقت، والنقل عبر HTTP/1.1 وHTTP/2، وسلوك الاتصالات طويلة الأمد، ومقاييس قابلية المراقبة واستكشاف الأخطاء.

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

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

الخلفية

في عمليات Solana العملية، يُعَدّ متوسط زمن الاستجابة وزمن الاستجابة في الأوقات العادية متطلبين أساسيين حاسمين. وفي الوقت نفسه، توجد سيناريوهات يحدد فيها سلوك البنية التحتية للشبكة نفسه النتائج — مثل لحظات تركز الحمل، والاتصالات طويلة الأمد، والمراحل التي تقع فيها انقطاعات وإعادات اتصال.

فعلى نقاط النهاية المشتركة على وجه الخصوص أن تستوعب دفقات إرسال المعاملات في نوافذ زمنية قصيرة، والاتصالات الدائمة عبر WebSocket وgRPC معًا. وفي هذه الظروف، ينعكس سلوك مستوى البنية التحتية — بدء الاتصال، ومصافحات TLS، وسلوك النقل، والتعامل مع التخزين المؤقت، والتعافي من حالات الخمول — مباشرة في تجربة المستخدم ونتائج التنفيذ.

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

وقد صممت ERPC منصة وسيط (Proxy) عالية الأداء مكتوبة بـ Rust خاصة بها وشغّلتها أساسًا لاتصالات Solana، محافظةً على بنية تطبق النهج نفسه عبر جميع المناطق مع تطوير المنصة باستمرار. وتعيد هذه الترقية فحص المشكلات المرصودة تشغيليًا بوصفها منظومة موحدة — من بدء الاتصال إلى التشغيل طويل الأمد — وتعيد تنظيم أساس الشبكة بأكمله تبعًا لذلك.

ما الذي يتغير لعملاء ERPC

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

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

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

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

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

تفاصيل التحسينات

لا تُقدَّم هذه الترقية إصدارًا مدفوعًا بأسماء ميزات أو أرقام إصدارات محددة. وإنما تفكك السيناريوهات التي تميل إلى الهيمنة على نتائج Solana الفعلية إلى الطبقات التالية — بدء الاتصال، وTLS، وحد L4/HTTP، ونقل H1/H2، والتخزين المؤقت، وقابلية المراقبة، وسلوك الأعطال، والمتطلبات الأساسية للتشغيل طويل الأمد — وتحدّث المنصة بحيث تتصل هذه الطبقات من دون تناقض.

وفيما يلي، نشرح التحسينات المدرجة من حيث إسهامها في تجربة العملاء والنتائج التشغيلية.

تحسينات بدء الاتصال ومعالجة TLS

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

كما أعدنا تنظيم معالجة TLS — بما فيها التحقق من الشهادات والتحقق من اسم المضيف — بحيث يمكن استيفاء متطلبات الأمان مع تقليل الحالات التي تُحدث فيها إخفاقات المصافحة أو تناقضات المعالجة خسائر عند البدء تتسلسل إلى النتائج. وهذا ليس مجرد تعزيز أمني؛ بل يسهم في استقرار السلوك من بدء الاتصال إلى الدخول في المعالجة لأعباء عمل Solana.

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

الحفاظ على السعة الفائضة عبر التصفية المبكرة للاتصالات غير الضرورية

أدخلنا آلية لتصفية اتصالات TCP في مرحلة مبكرة، محدثين المنصة بحيث يقل احتمال ضغط الاتصالات غير المشروعة أو غير الضرورية على حركة المرور المشروعة. فعلى نقاط النهاية المشتركة، قد تقفز طلبات الاتصال بسبب عوامل خارجية أو انحرافات مؤقتة.

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

توضيح نموذج الاتصال بإعادة تنظيم حد L4/HTTP

لا تنتهي البنية التحتية للشبكة عند HTTP. فإنشاء الاتصال واستمراريته يعتمدان على ظروف L4، والتقلب في تلك الطبقة ينتشر إلى تجربة البروتوكولات الأعلى.

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

كما أُعيد تنظيم سلوك إعادة المحاولة لتقليل الأنماط التي يتسلسل فيها التقلب قصير الأمد إلى تجربة المستخدم. فالاستقرار العملي يعتمد على منع تسلسل الأعطال أكثر من اعتماده على القضاء على الأعطال المعزولة.

تحسينات نقل HTTP/1.1 وHTTP/2 وسلوك التشغيل الطويل

أضفنا قياسات تتيح تتبع حجم البيانات المنقولة باتساق عبر HTTP/1.1 وHTTP/2. وهذا يسهّل تحديد أين تحدث التعثرات أو الاختناقات في خط أنابيب النقل، محسنًا استكشاف الأخطاء وسرعة تطبيق الإصلاحات معًا.

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

كما رُوجع سلوك مهلة الخمول والتعامل مع مجمعات الاتصال، مع إزالة عوامل عدم الاستقرار التي تميل إلى التراكم في أثناء التشغيل المتواصل. وعلى جانب HTTP/1.1، أعدنا تنظيم سلوك الإغلاق الآمن للاتصالات التي تحمل طلبات غير مكتملة، مخفضين مصادر التقلب في استخدام الموارد والسلوك معًا.

تحسينات التحكم في التخزين المؤقت وجودة التشغيل

حسّنا القدرة على تتبع سبب عدم تخزين أصل ما مؤقتًا، مما زاد قابلية تفسير سلوك التخزين المؤقت. ففي الممارسة العملية، المهيمن ليس وجود التخزين المؤقت من عدمه، بل الشروط التي يُطبَّق في ظلها والشروط التي يخرج فيها عن العمل.

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

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

تحسينات سلوك الأعطال والتسجيل وقابلية المراقبة

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

ولا يقصد من تحسينات قابلية المراقبة واستكشاف الأخطاء الادعاء بـ«صفر حوادث»، بل تقصير زمن التعافي عند وقوع الحوادث. وهذا يقلل المخاطر في سيناريوهات ذروة الحمل والتشغيل المتواصل.

تحديثات التبعيات والإصلاحات الأمنية بوصفها متطلبات أساسية للتشغيل طويل الأمد

أدرجنا تحديثات التبعيات والإصلاحات الأمنية للحفاظ على المتطلبات الأساسية لتشغيل المنصة طويل الأمد. ويشمل ذلك التحديثات المتعلقة بالحد الأدنى المدعوم من إصدار Rust (MSRV) ومواءمة CI، بما يعزز الأساس المطلوب لتطوير المنصة باستمرار.

فالقدرة على مواصلة التحديث بأمان هي بحد ذاتها متطلب للجودة طويلة الأمد.

الانتقال إلى عمليات بلا أي توقف

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

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

وفي الوقت نفسه، أصبحت لدى ERPC ظروف تشغيلية تتيح عكس المشكلات المرصودة في تحسينات بسرعة. فوتيرة التكرار الأعلى تمكّننا من القضاء المستمر على التقلب وسلوك الحالات الحدّية داخل العمليات الإنتاجية.

الأثر حسب الخدمة

Solana RPC (HTTP / WebSocket)

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

Geyser gRPC

تحسنت استمرارية الاتصال للاستخدام التدفقي طويل الأمد. ويعمل نقل HTTP/2، واتساق المهلات، وسلامة مجمعات الاتصال، وقياسات النقل الموسعة معًا على تقليل احتمال انتشار كلف إعادة الاتصال وإعادة المزامنة إلى النتائج.

Shredstream (Direct Shreds)

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

ربط البحث والتطوير بالعمليات الإنتاجية

الأساس الموزع للأنظمة الذي يشمل ERPC معترف به مشروعَ بحث وتطوير ضمن برنامج WBSO التابع للحكومة الهولندية. وتترسخ بنية يمكن فيها إدراج المشكلات المرصودة تشغيليًا موضوعاتِ بحث وتحسينها عبر التحقق والتكرار.

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

وداخل ERPC، تُدرج أنماط الاستخدام الفعلية وتقلب الحمل وسلوك أنماط الفشل في دورات متكررة من التحقق والتحسين ترفع تدريجيًا جودة أساس الشبكة. وقد نُفّذ هذا التحديث ضمن ذلك الإطار المتكامل للبحث والتطوير والعمليات الإنتاجية.

معلومات للعملاء

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

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

وللأسئلة حول البنية، أو التحسين الخاص بأعباء عمل معينة، أو الملاحظات التشغيلية، يرجى التواصل عبر Discord الرسمي لـ Validators DAO.

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

Discord الرسمي لـ Validators DAO: https://discord.gg/C7ZQSrCkYR
الموقع الرسمي لـ ERPC: https://erpc.global/ar