FAQ - Direct Shreds
Q. مخرجات Shreds / getBlock لديّ أصبحت فجأة تبدو معطوبة أو تُعيد -32015 — ما الذي تغيّر؟
دخل Solana Transaction v1 (SIMD-0385) حيّز التنفيذ على شبكة Solana الرئيسية في 15 سبتمبر 2026، عند الإيبوك 1035. تبدأ بنية البايتات المتسلسلة لمعاملة v1 (wire layout) ببايت بادئة الإصدار
0x81، وتأتي التوقيعات بعد الرسالة، ولا توجد بادئة الطول القديمة (legacy).إذا كنت تفكّ ترميز إدخالات ShredStream أو Direct Shreds أو UDP Forwarding بنفسك، فإن مفكّك ترميز
bincode أو solana-entry بإصدار أقل من 4.2 يقرأ بايت 0x81 هذا خطأً على أنه عدد التوقيعات، وهو ما يظهر كخطأ EOF أو تجاوز compact-length أو خطأ «invalid message version». يواجه مستخدمو Geyser gRPC الذين يفكّون تسلسل المعاملات الخام باستخدام crates أقدم من 4.2 المشكلة نفسها. تُعيد استدعاءات RPC لـ getBlock وgetTransaction مع maxSupportedTransactionVersion: 0 الخطأ -32015 Transaction version (1) is not supported by the requesting client؛ أما getTransactionsForAddress في وضع full فيُبلغ عن الخطأ نفسه في كل صف متأثر. لن تتأثر إذا كنت تقرأ بالفعل استجابات JSON المُحلَّلة من ERPC مع ضبط الإصدار 1.اضبط
maxSupportedTransactionVersion على 1 في كائن الخيارات — وهو المعامل الثاني لـ getBlock وgetTransaction، وكذلك في خيارات getTransactionsForAddress:json
{
"maxSupportedTransactionVersion": 1
}{
"maxSupportedTransactionVersion": 1
}قم بترقية Solana Stream SDK إلى
2.0.0: حزمة Rust solana-stream-sdk على crates.io، أو حزمتا npm @validators-dao/solana-stream-sdk و@validators-dao/solana-shreds-client. قم بترقية @validators-dao/solana-entry-decoder بشكل منفصل إلى 2.5.0. الإصدار 1.4.0 وentry-decoder 2.4.0 لا يدعمان v1. ينبغي لمفكّكات ترميز Rust الخاصة بك الانتقال إلى solana-entry 4.2.x.- دليل الترحيل
- ملاحظات إصدار SDK 2.0.0
- مستودع Solana Stream SDK
- SIMD-0385: مقترح Transaction v1
- ترقية Solana: Larger Transaction Sizes
- وثائق Solana RPC: getBlock
- وثائق Solana RPC: getTransaction
- وثائق ERPC: البدء السريع لـ ShredStream
- وثائق ERPC: البدء السريع لـ Geyser gRPC
- وثائق ERPC: RPC
Q. في أي المناطق تقع عقدكم؟
نعمل حاليًا على تشغيل عقد في المناطق التالية:
- Frankfurt (FRA)
- Amsterdam (AMS)
- London (LON)
- Dublin (DUB)
- New York (NY)
- Chicago (CHI)
- Salt Lake City (SLC)
- Tokyo (TY)
- Singapore (SGP)
- Sydney (SYD)
يقيس ERPC زمن استجابة الشبكة الفعلي بناءً على مسارات التوجيه الحقيقية، ويختار تلقائيًا المنطقة ذات زمن الاستجابة الأدنى بدلًا من الاعتماد على المسافة المستقيمة. ولا يحسّن هذا النهج زمن الاستجابة للمستخدمين الأفراد فحسب، بل يعزز أيضًا الكفاءة العامة للشبكة ويقوّي مرونة ERPC العالمية ضد الهجمات المحتملة.
إذا لم تختر بيئتك المنطقة المثلى تلقائيًا، فيُرجى التواصل معنا عبر ERPC Web Dashboard.
ERPC Web Dashboard: https://dashboard.erpc.global/ar
Q. يظهر زمن الاستجابة 9999ms وتُختار منطقة غير مثلى. ماذا أفعل؟
لاختيار منطقة Shreds، يرسل ERPC مسابير زمن استجابة عبر ICMP إلى عنوان IP المسجَّل لديك من مضيفي البروكسي المدرجين أدناه. اسمح بطلبات ICMP echo الواردة من كل عنوان IP مصدر مدرَج. إذا حظرها جدار حماية (ufw أو جدار حماية سحابي أو مجموعة أمان وما إلى ذلك)، فقد تصبح القراءة
9999ms وقد يتم اختيار منطقة غير مثالية. عناوين IP المتعددة في المنطقة الواحدة تمثل مضيفي مسابير منفصلين؛ وجميعها مطلوبة.| المنطقة | عناوين IP المصدر لـ ICMP |
|---|---|
| 🇳🇱 Amsterdam | 82.21.43.35 |
| 🇺🇸 New York | 151.243.244.162 |
| 🇩🇪 Frankfurt | 151.241.178.73 |
| 🇯🇵 Tokyo | 143.20.238.88 |
| 🇸🇬 Singapore | 151.245.186.3 |
| 🇬🇧 London | 151.241.65.10 |
تم تحديد Far Point
يمثل Far Point في Shared Shreds خيارًا احتياطيًا محدود السعة. تدعم كل نقطة نهاية ما يصل إلى 32 تدفقًا متزامنًا عبر الوكيل إجمالًا لجميع العملاء، وليس 32 حصة لكل عميل. يكون البث أكثر فاعلية عندما يعمل المشترك بالقرب من نقطة نهاية Shreds المحددة؛ إذ تحتفظ التدفقات بعيدة المسافة بالاتصالات المشتركة ونوافذ التحكم في التدفق وسعة الخروج لمدة أطول. للمساعدة في الحفاظ على استجابة البيئة المشتركة، اسمح بجميع عناوين IP المصدر المدرجة لمجسات ICMP الإقليمية، ثم أعد تشغيل اختيار المنطقة. للاستخدام المستمر، فكّر في ERPC VPS بالقرب من نقطة النهاية المحددة. بالنسبة إلى UDP Forwarding Standard، اختر منطقة متاحة أثناء الإعداد الأولي واضبط عنوان IPv4 عامًا صالحًا وغير فارغ مع المنفذ كوجهة. يمكن تغيير المنطقة والوجهة لاحقًا من لوحة التحكم. يؤدي تغيير المنطقة إلى تغيير عنوان IP المصدر لإعادة التوجيه، لذلك يجب أن يسمح جدار الحماية في جهة الاستقبال بعنوان IP المصدر الجديد لإعادة التوجيه.
استخدام ERPC VPS بالقرب من نقطة النهاية هذه · تهيئة UDP Forwarding Standard
قراءة دليل البدء السريع لـ Direct Shreds
Q. أضفت عنوان IP الخاص بي إلى قائمة السماح، لكنني ما زلت غير قادر على الاتصال. ما الذي يجب أن أفحصه؟
استخدم نقطة نهاية HTTPS المشفّرة المحددة في لوحة التحكم. يستخدم HTTPS المنفذ 443، بينما يبقى HTTP على المنفذ 80 الخيار غير المشفّر ذا زمن الاستجابة المنخفض.
يستخدم كلا البروتوكولين قائمة السماح نفسها لعناوين IP المسجّلة. استخدم نقطة النهاية المحددة في لوحة التحكم: HTTPS على 443 وHTTP على 80.
- نقطة نهاية HTTPS: استخدم نقطة النهاية المحددة في لوحة التحكم على المنفذ 443.
- نقطة نهاية HTTP: استخدم نقطة النهاية المحددة في لوحة التحكم على المنفذ 80.
- استخدم عنوان URL الظاهر في لوحة التحكم بصيغة
https://أوhttp://.
تعتمد المصادقة على عنوان IP المسجّل لديك. لا تُضف ترويسات
x-token أو token أو Authorization ما لم تنص صفحة منتج معيّن على ذلك صراحةً.Q. لم أستخدم سابقًا سوى WebSocket أو Geyser gRPC (YellowStone). هل لديكم أمثلة؟
نعم. يمكنك البدء سريعًا في اختبار اتصالات Shreds وتطوير التطبيقات باستخدام SLV.
يُرجى الرجوع إلى الدليل التالي للحصول على التفاصيل:
Q. هل يمكنني تسجيل عنوانَي IP اثنين؟
يمكنك استخدام نقطة نهاية واحدة لكل اشتراك. إذا رغبت في استخدام عنوانَي IP، فيجب عليك الاشتراك في اشتراكين منفصلين.
Q. أي منطقة تنصحون بها؟
لا توجد منطقة واحدة مثلى دائمًا. Solana شبكة عالمية، ويتناوب دور القائد بين المدققين سلوتًا بعد سلوت. المناطق التي تضم عددًا أكبر من المدققين وحصة أعلى تشهد سلوتات قيادة بوتيرة أكبر، مما قد يساعد المعاملات على الوصول بشكل أسرع. لكن في المقابل، تتمركز حركة المرور المنافسة هناك أيضًا، لذا قد تحقق منطقة أقل ازدحامًا نتائج أفضل أحيانًا بحسب استراتيجيتك.
كنقطة بداية عملية، اختر منطقة كثيفة المدققين مثل فرانكفورت أو الساحل الشرقي للولايات المتحدة عندما يكون توفر سلوتات القيادة بثبات هو الأهم، أو ضع نفسك بالقرب من مدقق مستهدف محدد عندما يكون التنفيذ بأقصر مسار هو الأولوية. استخدم Validators Solutions لفهم التوزيع العام لشبكة Solana، ثم استخدم ERPC Leader Slot API والقياسات الفعلية لتقرير ما إذا كان النشر في منطقة واحدة أو منطقتين أو عالميًا هو الأنسب.
Q. أحتاج إلى زمن استجابة قدره ~400ms كحد أقصى أو أفضل من ذلك.
لتحقيق زمن استجابة في حدود 400ms تقريبًا، ضع هذه النقاط الأساسية في الحسبان:
-
فهم واقعي لقيم البينغ: تشير قيم البينغ إلى ظروف مثالية ولا تعكس زمن الاستجابة الفعلي في اتصالات البث، التي تبلغ عادة نحو 5 أضعاف زمن البينغ. على سبيل المثال، بينغ بقيمة 100ms عبر القارات ينتج عنه واقعيًا زمن استجابة يقارب 500ms. لذا يجب إنشاء البنية التحتية داخل المنطقة نفسها لتحقيق زمن استجابة ~400ms.
- مرجع نموذجي لقيم البينغ:
- الشبكة نفسها: ~0.1ms
- الربط البيني للشبكات الخاصة (PNI): ~0.2ms
- مركز البيانات نفسه: ~0.3ms
- المدينة نفسها: ~1ms
- بلد مجاور: ~5–10ms
- بين القارات: ~100–300ms
- مرجع نموذجي لقيم البينغ:
-
تجنب فخ متوسط زمن الاستجابة: مدققو Solana موزعون جغرافيًا حول العالم، ويتغير جدول القائد عشوائيًا مع كل إيبوك. الاعتماد على متوسط زمن الاستجابة لتحقيق ~400ms أمر غير عملي. بدلًا من ذلك، يجب أن تتتبع بدقة جداول المدققين في منطقتك المحددة لتحديد السلوتات ذات زمن الاستجابة الأدنى. ولتحقيق الحد الأدنى من زمن الاستجابة باستمرار، يلزم وجود بنية تحتية في جميع المناطق ذات الصلة. فداخل المنطقة نفسها، يمكن أن يتم الحصول على البيانات خلال عشرات المللي ثانية، مع إمكانية الإرسال في بضع مللي ثانية فقط.
-
تتبع جدول القائد: راقب جدول المدقق القائد لمنطقتك باستخدام ERPC Leader Slot API (
getLeaderSlots). تُعيد جدول القادة القادم ووزن الحصة للإيبوك الحالي والمواقع الجغرافية التقديرية للمدققين وقيم البينغ المرجعية، مما يتيح لك تحديد السلوتات ذات أدنى زمن استجابة التي ينبغي استهدافها قبل حلولها. بيانات الخرائط العامة وواجهات RPC الأصلية مفيدة لرؤية واسعة للشبكة، لكنها ليست دقيقة بما يكفي لتوقيت التنفيذ. تسد Leader Slot API هذه الفجوة بالتفصيل اللازم لقرارات التوجيه والتداول.
بيانات شبكة Solana: Validators Solutions
Q. كيف يمكنني تحقيق تداول الكتلة الصفرية (السلوت الصفري)؟
يتطلب تحقيق تداول الكتلة الصفرية (السلوت الصفري) بنجاح استراتيجيات أكثر تطورًا، كما يلي:
-
تحديد مناطق الفرص: مدققو Solana موزعون حول العالم، ومن المستحيل فيزيائيًا تحقيق زمن استجابة مثالي لكل سلوت. لذلك، راقب جداول قيادة المدققين في المنطقة التي توجد فيها بنيتك التحتية وحدد مناطق الفرص الأكثر ملاءمة. وقد يكون نشر البنية التحتية عبر مناطق متعددة مفيدًا أيضًا. فعلى سبيل المثال، تُعد فرانكفورت منطقة رئيسية بفضل كثافة المدققين العالية فيها، مما يؤدي إلى اختيار القائد بوتيرة أكبر وفرص تداول أكثر.استخدم ERPC Leader Slot API (
getLeaderSlots) للاطلاع على جدول القادة القادم ووزن الحصة للإيبوك الحالي وبيانات الموقع الجغرافي التقديرية للمدققين وقيم البينغ المرجعية بدقة أعلى بكثير من مصادر بيانات الخرائط العامة أو واجهات RPC الأصلية. يتيح لك ذلك تحديد مناطق الفرص قبل حلول السلوتات وتنفيذ صفقات بزمن استجابة شبه معدوم. -
تطبيق العقد المخصصة: إذا كنت تجد صعوبة في المنافسة، ففكر في نشر عقد مخصصة. تعاني العقد المشتركة من زمن استجابة بسبب حركة المستخدمين الآخرين، وبالتالي لا يُنصح بها. علاوة على ذلك، فإن وضع عقدتك المخصصة داخل الشبكة نفسها مع تطبيقك يقلل زمن استجابة الشبكة بشكل كبير ويحسّن الأداء.
Q. هل يمكنني استخدام نقطة نهاية محددة؟
للحفاظ على بيئة منخفضة زمن الاستجابة، يختار نظامنا تلقائيًا أقرب عقدة متاحة. إذا رغبت في استخدام نقطة نهاية محددة، فنوصي باستئجار خادم يقع في أقرب موقع من نقطة النهاية تلك.
Q. لماذا نقاط النهاية المخصصة أسرع؟
تُستخدم نقاط النهاية المشتركة من قبل عدة عملاء يتشاركون الموارد نفسها. ومع ازدياد حركة المرور، يميل زمن الاستجابة إلى الارتفاع. موارد الخادم لها حدود فيزيائية، وحجم العمل الذي يمكنها معالجته محدود. وعندما تصل طلبات كثيرة جدًا في الوقت نفسه، يجب معالجتها تسلسليًا، مما يؤدي إلى أوقات استجابة أبطأ.
وعلى الرغم من أننا نتخذ تدابير مختلفة لتحسين الأداء حتى على نقاط النهاية المشتركة، فإنك مع نقاط النهاية المخصصة تكون المستخدم الوحيد للمورد. هذا يعني أنك غير متأثر إطلاقًا بالمستخدمين الآخرين، مما يضمن استجابات مستقرة وسريعة باستمرار.
بالإضافة إلى ذلك، توفر نقاط النهاية المخصصة خيارات اتصال بدون TLS، مثل HTTP. وبتخطي مصافحة TLS (حوالي 20ms)، يصبح الاتصال أسرع مقارنةً بـ HTTPS.
Q. هل سيرتفع سعر العرض بعد اشتراكي؟
طالما ظل اشتراكك نشطًا، يظل سعر العرض الذي ثبّتَّه عند التسجيل ساريًا. البيئات القادرة على الصمود تحت عبء عمل Solana اللحظي نادرة عالميًا، ونعتزم رفع الأسعار المعلنة تدريجيًا بما يتماشى مع الطلب المتنامي على العتاد والشبكة. التكوينات الأعلى مواصفات والمناطق الأكثر طلبًا تنفد أسرع، لذا فإن تثبيت السعر الترويجي الحالي هو الخيار الأكثر كفاءة من حيث التكلفة على المدى الطويل.
Q. أريد الدفع بالعملات المشفرة
تتوفر المدفوعات بالعملات المشفرة من ERPC Web Dashboard عندما تكون دولة عنوان الفوترة المسجل لديك إحدى دول الاتحاد الأوروبي الأعضاء. إذا كانت جميع بطاقات الدفع المسجلة في حسابك صادرة خارج الاتحاد الأوروبي، فلا تتوفر المدفوعات بالعملات المشفرة. يمكنك استخدام SOL أو USDC أو EURC لشراء أرصدة ERPC.
استخدم أرصدة ERPC تلك لتفعيل خطط ERPC أو مواصلتها. افتح لوحة التحكم، واختر الدفع بالعملات المشفرة، وأرسل التحويل من محفظتك، وستتحقق لوحة التحكم من المعاملة وتضيف الأرصدة إلى حسابك.
الدول المدعومة: النمسا، بلجيكا، بلغاريا، كرواتيا، قبرص، تشيكيا، الدنمارك، إستونيا، فنلندا، فرنسا، ألمانيا، اليونان، المجر، أيرلندا، إيطاليا، لاتفيا، ليتوانيا، لوكسمبورغ، مالطا، هولندا، بولندا، البرتغال، رومانيا، سلوفاكيا، سلوفينيا، إسبانيا، السويد.
للدول غير المدرجة في القائمة، يرجى الدفع ببطاقة ائتمان.
Q. لماذا لا يتضمن ShredStream جميع المعاملات؟
بالتصميم، لا تتضمن Shreds كل معاملة على بلوكتشين Solana. فمراقبة جميع المعاملات تتطلب نشر عدد كبير من البروكسيات عالميًا واستقبال Shreds من كل مدقّق، وهو أمر غير عملي.
عادةً ما يعمل المستخدمون مع مجموعة فرعية من البيانات المتاحة، إذ يكفي هذا النهج لمعظم التطبيقات الواقعية. وإذا كانت حالة استخدامك تتطلب تغطية كاملة للبيانات دون أي فقدان، فقد لا تكون Shreds مناسبة.
للسيناريوهات التي تتطلب مراقبة أكثر شمولًا، يوفر Geyser gRPC موثوقية أعلى مقارنةً بـ Shreds. ومع ذلك، فإن تحقيق تغطية بيانات بنسبة 100% على بلوكتشين Solana لا يزال يتطلب نشر عدد كبير من خوادم الحافة، وهو ما قد لا يكون واقعيًا عمليًا.
يوفر Geyser gRPC موثوقية تتجاوز 99%، وهي أعلى بوضوح من Shreds، وهي حقيقة أكدها العديد من المستخدمين بمن فيهم نحن. أما Shreds فتوفر عادةً موثوقية تتجاوز 90%.
وعلى الرغم من أنها لا تلتقط كل معاملة، فإن ميزتها الرئيسية هي القدرة على استرجاع معظم المعاملات بسرعة أكبر من Geyser gRPC.
لفهم أعمق، نوصي باستكشاف بروتوكولي Turbine وGulf Stream من Solana:
- Gulf Stream: Solana’s Mempool-less Transaction Forwarding Protocol
- Turbine — Solana’s Block Propagation Protocol Solves the Scalability Trilemma
Q. أريد أفضل بيئة ممكنة.
بالنسبة إلى UDP Forwarding Standard، اختر منطقة متاحة أثناء الإعداد الأولي واضبط عنوان IPv4 عامًا صالحًا وغير فارغ مع المنفذ كوجهة. يمكن تغيير المنطقة والوجهة لاحقًا من لوحة التحكم. يؤدي تغيير المنطقة إلى تغيير عنوان IP المصدر لإعادة التوجيه، لذلك يجب أن يسمح جدار الحماية في جهة الاستقبال بعنوان IP المصدر الجديد لإعادة التوجيه.
يُرجى التواصل معنا عبر ERPC Web Dashboard لمزيد من التفاصيل.
Q. كيف هو زمن الاستجابة؟
يختلف زمن الاستجابة بحسب طريقة القياس وبيئة الاستخدام الخاصة بك. وبدلًا من التركيز على القيم الرقمية الدقيقة، من الأهم التأكد من أن زمن الاستجابة يلبي متطلباتك التشغيلية الفعلية.
نوفر أدوات سهلة الاستخدام بلغتي TypeScript وRust لقياس زمن الاستجابة.
Q. هل خدمة RPC (gRPC, Shreds) هذه أسرع من غيرها؟
نحن نصمّم كل فئة سعرية من أجل السرعة، ويسعدنا أن يُقاس ذلك جنبًا إلى جنب مع أي مزوّد آخر. وقد تختلف النتائج بحسب المنطقة، وبحسب ما إذا كنت تستخدم نقطة نهاية مشتركة أو مخصّصة، والبروتوكول المستخدم (WebSockets أو gRPC أو Shreds)، ولغة البرمجة التي يعمل بها عميلك.
إذا وجدت خدمتنا أبطأ، فيرجى إخبارنا بالظروف المحددة والمنافسين الذين قارنتها بهم عبر ERPC Web Dashboard. سنحدد السبب ونحسّن السرعة أكثر.
Q. أي خطة تقدم أسرع أداء؟
بشكل عام، توفر خطتنا الأعلى فئة أسرع أداء بفضل وحدات معالجة مركزية متفوقة وسعات ذاكرة أعلى وتكوينات عتاد قوية.
كما نقدم حلولًا مخصصة إذا كنت تحتاج إلى خوادم أقوى، لكن خططنا القياسية مصممة لتقديم أفضل نسبة سعر إلى أداء.
نحن واثقون من تقديم أداء عالمي المستوى عند كل مستوى سعري. إذا وجدت مزودًا أسرع ضمن النطاق السعري نفسه، فيرجى إخبارنا لنحقق في الأمر ونجري التحسينات.
Q. أواجه زمن استجابة مرتفعًا. لماذا؟
يزداد زمن الاستجابة بشكل كبير مع البعد عن نقطة النهاية. ونوصي بالوصول من خادم يقع في موقع أقرب إلى نقطة النهاية الموفَّرة. وتتوفر أسرع البيئات عبر خوادم Bare Metal وخدمات VPS لدينا.
Q. ما الأسرع: WebSockets أم gRPC أم Shreds؟
بناءً على ملاحظات العملاء، فإن ترتيب الأداء هو:
Shreds > gRPC > WebSockets
إذا كانت تجربتك مختلفة، يُرجى إبلاغنا.
Q. زمن الاستجابة ليس كما توقعت.
يختلف الأداء بشكل كبير بحسب لغة البرمجة المستخدمة. وبشكل عام، فإن ترتيب الأداء هو:
Rust > Go > TypeScript (JavaScript) > Python
للمقارنات التفصيلية، يُرجى الاطلاع على:
نوصي بشدة بـ Rust لتحقيق أعلى أداء.