
أعلن الفريق الأساسي في TON عن ترقية آلية الإجماع، Catchain 2.0 (ترقية دون-ثانية)، والتي دخلت مرحلة نشرها على الشبكة الرئيسية. وتهدف إلى تقليص زمن التأكيد النهائي للبلوك من قرابة 10 ثوانٍ إلى قرابة 1 ثانية، وتقليص الفاصل الزمني بين البلوكات من قرابة 2.5 ثانية إلى 200-400 مللي ثانية. في 2 أبريل، قام المُحققون بالتصويت لتفعيل الإجماع الجديد على السلسلة الأساسية، وفي 7 أبريل تم تفعيل آلية الإجماع السريع بالكامل على السلسلة الأساسية والسلسلة الرئيسية.
Catchain 2.0 هو الترقية الأساسية في طبقة الإجماع الخاصة بـ TON. ويتمثل هدف التصميم في تحقيق نهائية دون ثانية (sub-second)، بحيث تقترب تجربة المستخدم على السلسلة من الخدمات التقليدية في Web2 من حيث سرعة الاستجابة. يوضح الجدول التالي مقارنة الأبعاد الثلاثة الرئيسية للأداء:
في الشبكة الرئيسية الحالية، يبلغ فاصل البلوكات قرابة 2.5 ثانية، أي قرابة 0.4 بلوك في الثانية، مع تأخر تأكيد نهائي يقارب 10 ثوانٍ. وفي شبكة الاختبار، يبلغ فاصل البلوكات حاليًا قرابة 450 مللي ثانية، ويبلغ التأكيد النهائي قرابة 1-2 ثانية. بعد الترقية، تستهدف الشبكة الرئيسية فاصل بلوكات قدره 200-400 مللي ثانية، أي قرابة 2.5-5 بلوكات في الثانية، مع تأخر تأكيد نهائي يقارب 1 ثانية.
وفي الوقت نفسه، أطلقت TON Center Streaming API v2، التي توفر تحديثات حالة المعاملات بنمط الدفع (push). يبلغ زمن التأخير من حدث على السلسلة إلى العميل 30-100 مللي ثانية. لقد اعتمدت MyTonWallet وtonscan.org واجهة API الجديدة هذه، وحتى قبل تفعيل تأكيد مستوى دون-ثانية على الشبكة الرئيسية، تم تقليص زمن استجابة المعاملات لهذه المنتجات إلى ما يقارب النصف.
يتم طرح نشر الترقية دون-ثانية على الشبكة الرئيسية وفق عقد زمنية صارمة:
31 مارس: اكملت جميع عقد التحقق تحديث النسخة، والترقية إلى أحدث إصدار يدعم Catchain 2.0
2 أبريل: تصويت المُحققين على تفعيل آلية الإجماع الجديدة على السلسلة الأساسية، وزيادة وتيرة إنتاج البلوكات، ومن ثم التشغيل الرسمي للإجماع السريع
7 أبريل: تزامن السلسلة الأساسية والسلسلة الرئيسية معًا لتفعيل آلية الإجماع السريع بالكامل، وإكمال تفعيل الترقية دون-ثانية على كامل شبكة TON الرئيسية
أبرزت TON رسميًا، في بيانها التقني، النقطة العمياء الأهم التي قد يتم تجاهلها بسهولة في هذه الترقية: حتى إذا كان البلوكشين الأساسي يولد البلوكات بسرعة 10 أضعاف، فإن مشروعًا يواصل استخدام الاستقصاء عبر HTTP polling بدلًا من Streaming API قد يتسبب في أن يظل تأخر تحديثات حالة المعاملة في واجهة المستخدم يتجاوز 10 ثوانٍ.
كمثال على HTTP polling: بعد أن ينقر المستخدم على “إرسال”، تُدرج المعاملة في بلوك شارد بعد حوالي 0.4 ثانية، ويجري تقديمها إلى السلسلة الرئيسية بعد 0.8 ثانية، لكن تحديث واجهة المستخدم سيتعين عليه انتظار طلب الاستقصاء التالي، ما قد يؤدي إلى تأخير يتجاوز 10 ثوانٍ. وبعد التحويل إلى Streaming API v2، يتم عرض حالة pending (قيد المعالجة) بعد 0.1 ثانية، وحالة confirmed (مؤكدة) بعد 0.4 ثانية، وحالة finalized (نهائية) بعد 0.8 ثانية، ويكتمل المسار كاملًا خلال ثانية واحدة.
حذّر فريق TON الأساسي بشكل واضح: «إذا لم تستطع التطبيقات إجراء التكيّف، فحتى لو كانت الأنظمة الأساسية تعمل بشكل طبيعي، ستبدو الترقية غير فعّالة. وستتمكن المشاريع التي تكون جاهزة قبل إطلاق السلسلة الرئيسية من إظهار السلوك المتوقع وتجربة المستخدم المتوقعة».
يُعد Catchain 2.0 ترقية كبيرة لطبقة الإجماع في TON. يتمثل التغيير الأساسي في تقليص فاصل إنتاج البلوكات بشكل كبير (من قرابة 2.5 ثانية إلى 200-400 مللي ثانية) وتقليص زمن التأكيد النهائي (من قرابة 10 ثوانٍ إلى قرابة 1 ثانية). كما ترتفع قابلية تحمل البلوكات في كل ثانية بنحو 2.5-5 مرات، ما يجعل سرعة الاستجابة للتفاعلات على السلسلة في TON—وفق التصميم—تقترب من معيار الخدمات التقليدية في Web2.
يركز التكيّف بشكل أساسي على ثلاثة مستويات: أولًا، التبديل إلى TON Center Streaming API v2 لاستلام تحديثات حالة المعاملات بنمط الدفع، بدلًا من HTTP polling؛ ثانيًا، معالجة جميع حالات المعاملة الأربع (pending وconfirmed وfinalized وtrace_invalidated) وتحديث تصميم واجهة المستخدم وفقًا لذلك؛ ثالثًا، إذا كانت هناك عقد تُدار ذاتيًا (self-hosted)، فيلزم تحديثها إلى أحدث إصدار يدعم Catchain 2.0 قبل 7 أبريل. لا يلزم اتخاذ أي إجراء إضافي بالنسبة للبورصات وخدمات الدفع التي تستخدم واجهات برمجة تطبيقات خارجية.
بالنسبة للمستخدمين العاديين، فإن التغيير الأكثر مباشرة هو أن سرعة تأكيد التحويل ستنخفض بشكل كبير من قرابة 10 ثوانٍ إلى أقل من 1 ثانية عند استخدام المحافظ وdApp وخدمات الدفع التي تم تكيّفها مع الترقية. لكن هذا التحسن يعتمد كليًا على ما إذا كانت الجهة المطورة (project owner) قد أنجزت تكيّف Streaming API—فال التطبيقات غير المكيّفة، حتى لو كانت تعمل على الشبكة الرئيسية بعد الترقية، فلن يكون هناك أي تحسن واضح في تجربة المستخدم.