عندما يتعلق الأمر بتسريع سلاسل الكتل العامة، غالبًا ما تواجه الجميع العقبة نفسها: ما إن تمس معاملتان الرصيد نفسه أو مجمع السيولة نفسه، حتى تضطرا إلى الانتظار في طابور. وحتى لو أضفت مزيدًا من الأجهزة، فستظل تعمل إحداها بينما تنتظر الأخرى.
في 28 أكتوبر، كشفت مؤسسة Stellar للتنمية عن Project Thruput في مؤتمر Meridian 2026 بلشبونة، سعيًا إلى معالجة هذه المشكلة مباشرة. لكن انتبه إلى توصيفه: إنه «معاينة تقنية» تعمل على شبكة الاختبار FutureNet، وليس ترقية للشبكة الرئيسية.
بعض المعلومات المؤكدة من المدونة الرسمية:
1）تُنفَّذ المعاملات في الكتلة نفسها بالتوازي انطلاقًا من اللقطة نفسها لدفتر الأستاذ، حتى لو غيّرت الحالة نفسها. فمثلًا، يُسجَّل تغيّر الرصيد على أنه «ناقص 5» بدلًا من «الرصيد الآن 95»، ثم تُدمج التغييرات عند الإرسال؛ لكن لا يمكن لمعاملتين إنفاق المبلغ نفسه في الوقت ذاته.
2）يمكن للمدقّق الواحد توزيع التنفيذ على عدة أجهزة. معيار مبكر: نحو 1.18 مليون عملية دفع في الثانية على جهاز واحد، ونحو 7.02 ملايين على 8 أجهزة، أي ما يقارب 6 أضعاف.
3）وُضّحت طريقة الاختبار أيضًا: تحويلات ERC-20 عالية التنافس بين 100 حساب، أُجريت ثلاث مرات على مثيلات AWS، ثم احتُسبت القيمة الوسيطة. وأكد الفريق الرسمي بنفسه أن هذا يقيس سعة محرك التنفيذ، لا معدل نقل الشبكة من البداية إلى النهاية.
4）لا توجد رسوم تُفرض على كل معاملة. لا يزال الغاز يُستخدم لقياس التنفيذ، مع وضع حد أقصى لكل معاملة؛ وعندما يتجاوز الطلب السعة، تُوزّع حصص الجدولة بحسب رصيد التوكن الأصلي غير المحجوز في الحساب، من دون إنفاق التوكنات. أما تخزين البيانات فيحجز جزءًا من الرصيد، ويُحرَّر هذا الجزء عند حذف البيانات.
الكود والورقة البيضاء والمعايير القابلة لإعادة الإنتاج كلها مفتوحة المصدر.
رأيي: خذوا رقم «7.02 ملايين TPS» بحذر؛ فمعيار المختبر شيء، والشبكة الحقيقية شيء آخر. الأجدر بالمتابعة أمران: هل سيقبل المطورون نموذج «الحالة القابلة للدمج» هذا؟ وهل سيدخل نهج «بلا رسوم، والأولوية في الطابور بحسب رصيد التوكنات» إلى الشبكة الرئيسية، وبأي صيغة؟ لم يعلن الفريق الرسمي حتى الآن عن جدول زمني.
هذا ليس نصيحة استثمارية.