كشف البيانات: تباطؤ تحويلات سولانا، هل هو بسبب "مؤكدين" يثيرون المشاكل؟

المؤلفون: Carlos و Luke Leasure

العنوان الأصلي: حروب بناء الكتل في سولانا

الترجمة والتنظيم: BitpushNews

في 5 يناير 2026، أطلقت JITO أداة عامة تسمى IBRL Explorer، بهدف قياس سلوك حاصري التحقق في حزم الكتل على سولانا وكشف “مراهنة التوقيت” غير المرئية سابقًا في بناء الكتل.

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

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

• وقت الـ Slot (35%) : إذا تم بناء الكتلة ضمن عتبة معينة، تحصل على درجة أعلى: إذا كانت عملية تسليم الـ slot من مدقق آخر أقل من 550 مللي ثانية، أو إذا كانت الـ slot متتالية (أي أن القائد في دورة التناوب بقيت له أي slot) أقل من 380 مللي ثانية.
• حزم المعاملات غير التصويتية (40%) : عندما تتوزع المعاملات بشكل متساوٍ عبر 64 نقطة زمنية (tick) في الـ slot، وليس بتكديس معظم المعاملات غير التصويتية في آخر عدة نقاط، يحصل المدقق على مكافأة. هذا هو المتغير الأكثر إثارة للجدل في درجة IBRL، وسيتم شرحه بالتفصيل لاحقًا.
• التصويت المبكر (25%) : عندما يتم معالجة 90% على الأقل من معاملات التصويت خلال أول 32 نقطة، يحصل المدقق على الدرجة الكاملة. وإذا تم تأجيل التصويت إلى جزء لاحق من الكتلة، تنقص الدرجة.

يوضح IBRL Explorer أن العديد من المدققين يعمدون إلى تأخير حزم المعاملات غير التصويتية، وفي بعض الحالات يطيلون وقت الـ slot. يؤدي التأخير في الحزم إلى تأخير نشر الحالة، وزيادة تباين النتائج، وتدمير تصميم التدفق في سولانا، مما يقلل من زمن استجابة الشبكة. النتيجة ليست تدفق بيانات مستمر، بل انفجارات مفاجئة من البيانات.

في كتلة مثالية، كما في المثال من مدقق Helius، يتم معالجة معظم معاملات التصويت في النصف الأول من الكتلة (“نشر الحالة مبكرًا”)، بينما تتوزع معاملات غير التصويت بشكل متساوٍ عبر 64 نقطة زمنية (“تدفق مستمر”).

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

وفقًا لـ Lucas Bruder، الشريك المؤسس والرئيس التنفيذي لـ Jito Labs، يتم تحفيز المدققين لانتظار اللحظة الأخيرة من الـ slot لمراقبة المزيد من المعاملات الواردة، واختيار المعاملات ذات أعلى رسوم، لتعظيم المكافآت.

لكن لماذا يهم المستخدمون؟ على الرغم من أن تعظيم الأرباح هو سلوك منطقي للمدقق الفردي، إلا أن هذا السلوك يسبب رقابة ضمنية، وتأخير في نشر الحالة، ويجبر القائد التالي على “الملاحقة”، مما يبطئ الشبكة بأكملها.

الأهم من ذلك، أن تأخير الحزم مرتبط مباشرةً بـ “تدفق الطلبات” (PFOF) الناشئ في سولانا، كما أوجزه Benedict Brady في هذا المقال. نظرًا لأن المحافظ والتطبيقات غالبًا ما تنتج معاملات موقعة مسبقًا (أي أوامر سوق مع حدود انزلاق سعر)، فإن الطلبات تتضمن خيارات “تشغيل لاحق” ذات قيمة. من مصلحة المستخدمين بيع حق التشغيل اللاحق لشركات التداول، بينما الممارسة الاستخراجية هي تنفيذ “هجوم ساندويتش”. أيًا كانت الطريقة، هناك دافع لتقليل سرعة تنفيذ المعاملات لزيادة قيمة التشغيل اللاحق، وهو ما يمكن تحقيقه عبر تأخير الحزم.

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

الجدل بين Temporal و Jito

قبل الخوض في كيفية حل سولانا لهذه المشكلة، من الضروري الاعتراف بوجود نقاش نشط حول مفهوم “بناء الكتل الجيد”. أحد المساهمين الرئيسيين في Harmonic، Temporal، أعرب عن اعتراضه على إطار عمل Jito وطريقة تقييم IBRL. انتقادهم هو أن هذا التقييم يتضمن مجموعة من التفضيلات التصميمية التي تصب في مصلحة طريقة بناء الكتل الخاصة بـ Jito، وتفترض بشكل ضمني أن Harmonic أدنى، وهو ما يظهر في أن المدققين الذين يشغلون Harmonic يحصلون على درجات أقل باستمرار.

وفقًا لمؤسس مشارك في Harmonic، فإن كتل Harmonic تُنفذ بشكل متصل بدون تأخير، لكن أجزاء البيانات لا تُطلق إلا بعد حوالي 300 مللي ثانية من انتهاء المزاد. هذا يمنح منشئي الكتل وقتًا كافيًا للمنافسة، ويتيح لبقية الشبكة إعادة تشغيل كتل Harmonic. يظهر الرسم التوضيحي أدناه نفس الـ slot (391,822,619)، حيث يُظهر كيف تنتشر الكتل من قبل مدقق Harmonic، Temporal Emerald.

من سياق انتشار الكتل (الصورة أعلاه)، يبدو أن تنفيذ Harmonic متساوي الفواصل الزمنية. بمعنى آخر، يستمر منشئو الكتل في بناء الكتل بشكل متوازي، بينما تتركز المعاملات في آخر نقطة (أسفل الصورة) لأنها لحظة قرار المزاد.

خلال الـ 30 يومًا الماضية، حققت Harmonic متوسط وأوساط دخل أعلى (رسوم أولوية + إكراميات) لكل كتلة مقارنة بـ Jito وFiredancer، مما يمنح المدققين والراهنين مكافآت أعلى. السؤال المعلق هو: هل هذا الأداء المتفوق تم تحقيقه عبر مراهنة التوقيت كما ذُكر سابقًا، على حساب مصلحة المستخدمين؟

المصدر: https://reports.firedancer.io/

المتقدمون المتزامنون (MCP) و BAM

بعد استعراض وجهات النظر، لا يزال هناك حقيقة مهمة: التدفق المستمر ضروري.

موقف Harmonic لا يعني أن التدفق غير مهم، بل يعتقد أن IBRL لم يلتقط كيف تنفذ Harmonic ذلك، وربما صنف آلية المزاد بشكل خاطئ على أنها “مراهنة التوقيت”. في المرحلة الحالية، لا أمتلك خلفية تقنية كافية أو بيانات لتكوين رأي واضح، لكن سولانا تعمل على تطوير حل بروتوكولي يهدف إلى معالجة الحوافز الأساسية.

الحل هو المتقدمون المتزامنون (MCP)، وهو هيكل طوره Anatoly Yakovenko و Max Resnick. الدافع بسيط: في نموذج القائد الواحد الحالي، يتحكم مقدم الاقتراح في ترتيب المعاملات، ويمكنه في الواقع أن يتصرف بشكل أبطأ من الآخرين، مما يحقق تأخير الحزم ويعزز ديناميكية PFOF المذكورة أعلاه. يزيل MCP احتكار القائد الواحد عبر السماح لعدة مقترحين بالبناء بشكل مستقل ومتوازي لكتل مرشحة، مما يمنع القائد الواحد من قمع المعاملات أو تأخير التنفيذ لتحقيق أرباح.

أي أن شرطًا أساسيًا لـ MCP هو إطلاق Alpenglow على الشبكة الرئيسية. من المتوقع أن يُطلق في 2026، لكن الجدول الزمني غير مؤكد. في الوقت نفسه، قد يدفع BAM من Jito التغيير عبر جعل منطق الترتيب قابلاً للمراجعة. يهدف BAM إلى توسيع مساحة تصميم الهيكل الدقيق في سولانا، مما يتيح للتطبيقات التي تتطلب تحكمًا أدق في الترتيب (مثل إلغاء الطلبات في بورصات العقود الآجلة المستدامة) أن تكون ممكنة، ويساعد على تقليل آثار MEV السلبية، مثل هجمات الساندويتش. يوضح الرسم أدناه خط أنابيب معاملات BAM.

أصبح BAM (Agave-BAM) الآن ثالث أكبر عميل على سولانا حسب حصة التوكنات المرهونة، بنسبة حوالي 12%، بعد Agave-Jito وFrankendancer-Jito. يوجد حوالي 205 مدققين يستخدمون BAM، مما يبرز سرعة اعتماده بين مجتمع مدققي سولانا. بالمقابل، لا تزال Harmonic صغيرة نسبيًا، بحصة رهن تزيد قليلاً عن 3%، وحوالي 20 مدققًا.

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